Войти
ФлеймФорумПрограммирование

XML - язык, невероятно богатый возможностями. Чтоб его. (5 стр)

Страницы: 1 2 3 4 5
#60
13:46, 6 авг. 2019

gudleifr
> Что классические задачи уже обычно имеют классические решения. Их не надо
> решать.
Ага, и классическое решение тут XML :)

gudleifr
> Подходящие! (Нет, конечно,  сначала я выкину класс, т.к. ООП оставил в далеком
> детстве). Вы хотите получить что-то из большого текстового файла? Пишете тупой
> конечный автомат, который пропускает все до нужного места (в большинстве
> форматов и языков он тривиален). Пишите второй конечный автомат - для чтения
> нужного (он еще тривиальнее). Читаете.
Тут ещё одно маленькое дополнение, трудоёмкость у задачи 2ч. Можно конечно сходу сочинить свой формат (8ч техпроект + 4ч согласования), написать свой парсер (8ч разработка + 10ч отладка + 30ч тестирование), потом сделать для всего этого документацию (10ч т.к. документацию программисты пишут оооочень медленно). Но твой напарник сделал эту задачу за 2ч использовав классические идеально подходящее под требования задачи решение на XML. И то написал он его за 15 минут, остальное время читал хабру. Я бы не взял вас к себе работать, честно.


#61
13:47, 6 авг. 2019

gudleifr
> Это хорошо и правильно. Формат придуманный для одного проекта и не должен его
> пережить. Тем более, формат, придуманный впрок (этот вообще не имеет права на
> жизнь).
Поинт в том, что не надо придумывать свои форматы, если по другому вообще никак.

#62
13:53, 6 авг. 2019

Мизраэль
> Я бы не взял вас к себе работать, честно.
Тут, скорее обратная проблема.
И проблема даже не в том, что "парсер" - это две строчки кода. А в том, что в Вашей постановке задачи, при которой эти "2 часа" через полгода обойдутся месяцем на переписывание.

Мизраэль
> не надо придумывать свои форматы
Это точно. Там нечего придумывать. Что коду надо, то он и берет. 

#63
14:16, 6 авг. 2019

gudleifr
> классические задачи уже обычно имеют классические решения. Их не надо решать.
  Если бы это было так, то до сих пор бы все использовали сортировку пузырьком и не пытались изобрести что-то лучше.

> сначала я выкину класс, т.к. ООП оставил в далеком детстве
  Вместе с последними мозгами? :)

> Пишете тупой конечный автомат, который пропускает все до нужного места (в
> большинстве форматов и языков он тривиален). Пишите второй конечный автомат -
> для чтения нужного (он еще тривиальнее). Читаете.
  Ты уж определись давай либо классическое решение задачи, либо велосипед каждый раз. А то что-то переобуваешься на ходу.

#64
16:06, 6 авг. 2019

Zefick
> либо классическое решение задачи, либо велосипед каждый раз.
Делать велосипед каждый раз это как раз классика. Всё остальное модерн.

#65
16:15, 6 авг. 2019

Мизраэль
> Твоя задача сделать инициализацию полей класса
> данными из конфига.
А позиция в контексте разрешает уволить всю фирму или хотя бы подать на развод с task`ой из-за загона в "пространство_решений\лабиринт" слишком свободный от "толковых\обобщенных" путей наружу? Просто есть ли смысл решать один указаный начальством экземпляр шаблонной задачи, когда в нормальных конторах просто стоит один автоматический агрегат с рундуком и одной кнопкой для таких сложных и достойных инженерных задачь? Если да, то там наверно должны хорошо платить начальству, т.к задачи-то для кого-то  поставлены фудаментальные в далёкой перспективе и создают высоколиквидный со временем опыт :)

#66
17:55, 6 авг. 2019

Мизраэль
> Это ты сам придумал. Шаблоны например без запросов же не будут работать. Или
> шаблоны тоже не нужны?
Какие шаблоны? Гуйно-DOM-ные? За гуйно-домные шаблоны, связанную с ними модель и запросы отвечает гуйно-домная библиотека. Шаблоны данных, которые нужно откуда-то там достать, отфильтровать и как-то представить? Так это не самостоятельная задача - за неё отвечает или БД, или какая-то узкоспециализированная модель, и это опять-таки сфера ответственности БД или модели, а не формата.

> Ну например конфиги, логи, данные с метаданными
Вот уж где хмл нужен меньше всего, так это для конфигов и логов. А метаданные почти всегда проще велосипедить по ситуации - тем более что специфика задачи, для которой нужны какие-то метаданные, часто не укладывается в некие сферические рамки.

> Как по простому мне сделать конфиг на JSON? Если изначально я не могу его
> целиком десерилизовать в какой-то объект.
Если конфиг не поддаётся тривиальной десериализации, тот тут уже попахивает не конфигом, а полноценной БД, со всеми вытекающими.

> У тебя на доске висит таска - сделать конфиг, и есть к таске требования: он
> должен быть человекочитаем и допускать возможность правки, в модулях есть
> классы настроек, которые заполдняются данными из конфига. В конфиге могут быть
> любые настройки, в том числе бинарные данные. Ни один модуль очевидно не знаком
> со всей структурой конфига.
В таких случаях пилится специальный модуль, отвечающий строго за работу с конфигом, и все модули-юзеры, заинтересованные чего-нибудь конфигурировать, общаются с конфигурацией строго через его интерфейс. Реализация всех поисков-запросов, представления конфига и проч. - на нём. Какой формат будет подпирать с человекочитаемой стороны - дело уже глубоко десятое, т. к. модули-юзеры читать из него сами ничего не будут, это не их собачье дело.
А с человекочитаемой стороны чаще всего оказывается удобнее подпереть жсоном или чем попроще - потому что, как только начинаешь думать в терминах нужд юзеров, а не возможностей формата, оказывается, что много-то не нужно.

> Но твой напарник сделал эту задачу за 2ч использовав классические идеально подходящее под требования задачи решение на XML.
В таких случаях к задаче бывает полезно уточнять один момент: "...и заполнять этот конфиг будешь ТЫ!" Этого уточнения обычно хватает, чтобы 2ч магическим образом превратились и в 8ч на постановку задачи, и прочие "такие вещи с кондачка не решаются, надо сначала подумать как следует".

#67
20:59, 6 авг. 2019

Sbtrn. Devil
> В таких случаях к задаче бывает полезно уточнять один момент: "...и заполнять этот конфиг будешь ТЫ!"
Вот, кстати, да, все эти доморощенные "текстовые форматы просто парсить!" и "я просто возьму библиотеку X!" плохо понимают, что такое человеко-читаемый формат. На практике это означает, что если человек где-то допустил ошибку, то он ожидает, что парсер выдаст ему человеко-читаемое сообщение (причем специализированное под решаемую задачу) с конкретным указанием места ошибки. И сразу самописная процедура парсинга распухает в несколько раз, а библиотеки оказываются неспособными выдать координаты конкретного атрибута в файле.

#68
21:04, 6 авг. 2019

}:+()___ [Smile]
> И сразу самописная процедура парсинга распухает в несколько раз, а библиотеки
> оказываются неспособными выдать координаты конкретного атрибута в файле.
А несамописные, разумеется, сами "специализируются под задачу"...

#69
21:16, 6 авг. 2019

}:+()___ [Smile]
> На практике это означает, что если человек где-то допустил ошибку, то он
> ожидает, что парсер выдаст ему человеко-читаемое сообщение
  Не делай ошибок и не нужны будут сообщения. Чё неужели так сложно?

#70
23:34, 6 авг. 2019

gudleifr
> А несамописные, разумеется, сами "специализируются под задачу"...
А несамописные из коробки в десять тысяч раз распухли.

#71
16:03, 7 авг. 2019

gudleifr
> И проблема даже не в том, что "парсер" - это две строчки кода. А в том, что в
> Вашей постановке задачи, при которой эти "2 часа" через полгода обойдутся
> месяцем на переписывание.
За 10 лет ни разу не переписывались. Это твой велосипед придётся каждый раз допиливать, когда что-то ещё надо будет поддерживать.

Sbtrn. Devil
> Какие шаблоны? Гуйно-DOM-ные? За гуйно-домные шаблоны, связанную с ними модель
> и запросы отвечает гуйно-домная библиотека. Шаблоны данных, которые нужно
> откуда-то там достать, отфильтровать и как-то представить? Так это не
> самостоятельная задача - за неё отвечает или БД, или какая-то
> узкоспециализированная модель, и это опять-таки сфера ответственности БД или
> модели, а не формата.
Ни хрена не понял, я про XSLT говорил. И БД тут совсем не в кассу, мало того, что движок БД надо с собой таскать, так ещё и кода навернуть вокруг на порядок больше.

Sbtrn. Devil
> Вот уж где хмл нужен меньше всего, так это для конфигов и логов.
Да конечно. Я вроде уже пояснил, что для конфигов нужен нормальный стандартизированный формат, который а) поддерживает схемы, б) позволяет делать запросы. Я конечно хз, может тебе и ini-файл за конфиг сойдёт, но я такое последний раз 10 лет назад использовал.
Что касается логов - есть одно традиционное простое и неправильное решение - plain text файл, где строки отделены через \n или \r\n (уже попадаем в проблемы), а поля разделены табуляцией (не забываем при этом из входных данных убрать неподходящие символы). А потом для разбора терабайт логов корячим свои скрипты для ES и чтобы оно нормально парсилось. А потом кто-то что-то меняет в выхлопе логгера и терабайты косячно разобранных логов улетают в БД. А пробовал когда-нибудь читать логи длинною в сотни Мб? Когда там сплошная портянка текста?

Sbtrn. Devil
> В таких случаях пилится специальный модуль, отвечающий строго за работу с
> конфигом, и все модули-юзеры, заинтересованные чего-нибудь конфигурировать,
> общаются с конфигурацией строго через его интерфейс. Реализация всех
> поисков-запросов, представления конфига и проч. - на нём. Какой формат будет
> подпирать с человекочитаемой стороны - дело уже глубоко десятое, т. к.
> модули-юзеры читать из него сами ничего не будут, это не их собачье дело.
да, это будет дерево объектов конфигурации, к ней мы напишем свой язык для запросов и придумаем свой формат для хранения. Всё это будет в 1000 раз хуже, чем стандартный XML, работать всё будет в 100 раз медленнее, зато мы потратим на это 200-300ч. Ну т.е. это работодатель потратит, мы-то за это денюжку получим, ага? ;)

Sbtrn. Devil
> В таких случаях к задаче бывает полезно уточнять один момент: "...и заполнять
> этот конфиг будешь ТЫ!" Этого уточнения обычно хватает, чтобы 2ч магическим
> образом превратились и в 8ч на постановку задачи, и прочие "такие вещи с
> кондачка не решаются, надо сначала подумать как следует".
нет таких проблем, не придумывай. Весь софт написанный на .NET (включая веб-решения) имеет конфиги в виде XML.

#72
16:08, 7 авг. 2019

Мизраэль
> За 10 лет ни разу не переписывались.
И Вы до сих пор помните, что 15 минут ушло на писание и 2 часа на хабр? Круто Вас тогда цепануло...

#73
13:00, 8 авг. 2019

Мизраэль
> Ни хрена не понял, я про XSLT говорил.
Вот это точно не нужно. Человекочитаемый формат должен заканчиваться в том месте, где он проходит через парсер. Все дальнейшие трансформации - в терминах внутреннего представления, и никаких извращений не нужно. А если вдруг нужно много-много данных, которые не влезают в тривиальное внутреннее представление, и всяко-различно комбинировать их выборку - БД очень даже в кассу. Там по вопросам выборки данных за десятилетия съедены тонны собак, и Xpath сотоварищи - убогий эрзац супротив SQL.

> А пробовал когда-нибудь читать логи длинною в сотни Мб? Когда там сплошная
> портянка текста?
Как раз для чтения сотен мб портянка текста - идеальный формат. По ней может работать даже примитивный греп.

Мизраэль
> да, это будет дерево объектов конфигурации, к ней мы напишем свой язык для
> запросов и придумаем свой формат для хранения. Всё это будет в 1000 раз хуже,
> чем стандартный XML, работать всё будет в 100 раз медленнее, зато мы потратим
> на это 200-300ч. Ну т.е. это работодатель потратит, мы-то за это денюжку
> получим, ага? ;)
Я тут прямо сейчас работаю именно с таким решением. Внизу у него, сюрприз, самый что ни на есть стандартный XML (в нём конфиг хранится на диске). Очевидно, что на заре его сочинители думали примерно так же, как ты. С тех пор прошли годы. Система обладает следующими фичами:
- интерфейс для выдачи конфига другим компонентам. Очевидно, что это было сделано в первую же очередь, т. к. голая модель данных хмл оказалась неудобным говном. И по ряду корявых решений в этой модели видно, как её сначала прибивали гвоздями именно к хмл (ну а чо там, запросы и всё такое), а потом долго и мучительно отдирали. Естественно, парсер хмл во внутреннее представление компонента, отвечающего за конфиг, имеет место быть. И, естественно, компоненты потребляют конфиг именно во внутренней форме, и ни про какой хмл знать не знают.
- интерфейс для выдачи конфига компонентам по сети. Т. к. конфижный сервак один, а заинтересованные в конфиге компоненты чаще всего распределены по другим хостам. Предусмотрено проксевание и балансировка нагрузки.
- скопинг частей конфига для отдельных компонентов и отдельных хостов. Т. е., обычный вариант конфига может быть один, но для такого-то компонента на таком-то хосте вместо него может действовать другой.
- метадата. Никаких XSD, потому что метадата в терминах предметной задачи оказалась сильно не такой, как казалось афторам XML. Её пришлось пилить в отдельных файлах, причём разделение файлов регламентировано строго определеным образом: у каждого компонента своя метадата, и она может обновится при апдейте/патче.
- веб-гуй для человекоредактирования и человекопросмотра конфига. Потому что в хмл-виде размер конфига исчисляется семизначными цифрами, плюс соображения разграничения доступа, и ни о каком просмотре и редактировании блокнотом речь даже не идёт.
- инструмент командной строки для редактирования и извлечения частей конфига. По тем же соображениям, что и выше. Имеет место самописный язык запросов. Да, в терминах модели данных конфига, а не нижележащего хмл. Да, его пришлось велосипедить, потому что xpath не умел работать в этой модели. Да, изменения конфига в патчах поставляются именно на этом самописном языке. Некоторое время назад было принято решение о переводе на него же дефолтных конфигов, применяемых при инсталляции компонентов (ранее они описывались в т. н. canned data - кусках хмл, которые при инсталляции впатчиваются в соотв. место главного документа). О причинах решения догадаться нетрудно.
- поддержка кустомизируемых валидаторов. Да, они тоже должны вести валидировать в терминах модели данных конфига, более того - в логике конкретного компонента. И да, их поддержку тоже пришлось велосипедить, потому что модель данных конфига и возможных ограничений выходила за пределы возможностей не только хмл-схем, но даже самописной метадаты.
- это только те фичи, о которых я на сегодня знаю...

Т. е. по итогам велосипедить всё равно пришлось в полный рост, и стандартный хмл со всем его богатством технологий помог чуть менее, чем ни хрена. На отдельных этапах - даже очевидно навредил, создав ненужные иллюзии. И его, в принципе, можно было бы уже сейчас заменять БД или жсоном, если бы не ряд решений на низовом уровне, которые в своё время недостаточно абстрагировали от хмл, и которые из-за этого остались прибитыми к нему гвоздями по широкому периметру. Благодаря этому также имеет место ряд забавных костылей.

> нет таких проблем, не придумывай. Весь софт написанный на .NET (включая
> веб-решения) имеет конфиги в виде XML.
У вас там, может, и нет проблем, а у нас внедрение нового куска конфига в процессе разработки новых фич в компонентах перестало быть танцами с бубном и блокнотом только после разработки ряда велосипедов.
Ну а .нет - известное говнистче. К счастью, у нас не он.

#74
13:23, 9 сен. 2019


https://www.joelonsoftware.com/2001/12/11/back-to-basics/

Страницы: 1 2 3 4 5
ФлеймФорумПрограммирование

Тема в архиве.