Кто, чем и как обрабатывает XML-файлы большого объема ?

← →
Игорь Шевченко © (2012-11-01 13:15) [0]

По моему понимаю, польшой объем начинается от 100 мегабайт. Интересуют технологии и средства формирования, чтения, валидации по схеме.
Все это интересует применительно к Delphi, разумеется, XML-файлы нужно формировать, читать и валидировать программно.
msxml с использованием DOM на такого объема файлах потребляет негуманное количество ресурсов

← →
имя (2012-11-01 13:41) [1]

Удалено модератором

← →
jack128_ (2012-11-01 13:42) [2]

может чем поможет: http://forum.sources.ru/index.php?showtopic=81572

← →
Rouse_ © (2012-11-01 13:54) [3]

Точнее лучше вот так смотреть, чтоб не искать: http://forum.sources.ru/index.php?showtopic=81572&view=findpost&p=600614

← →
Игорь Шевченко © (2012-11-01 13:56) [4]

Rouse_ © (01.11.12 13:54) [3]

> http://forum.sources.ru/index.php?showtopic=81572&view=findpost&p=600614

"Тест 2. Файл размером 1,75 МБ."

> объем начинается от 100 мегабайт

← →
AV © (2012-11-01 14:18) [5]

а если просто?
oq1: TOraQuery;

S := DateTimeToStr(now);
oq1.Open;
oq1.SaveToXML("c:\11.xml");
S := S + " "+ DateTimeToStr(now);
mmo1.Lines.Add(s);

01.11.2012 14:15:44 - 01.11.2012 14:17:13
файл - 210 МБ

← →
DVM © (2012-11-01 14:22) [6]

> msxml с использованием DOM на такого объема файлах потребляет
> негуманное количество ресурсов

У MS есть и SAX парсер вроде бы.
http://support.microsoft.com/kb/311423/ru

← →
Игорь Шевченко © (2012-11-01 14:31) [7]

DVM © (01.11.12 14:22) [6]

Благодарю. Хотелось бы еще примеров :)

← →
DVM © (2012-11-01 15:05) [8]

> Игорь Шевченко © (01.11.12 14:31) [7]

> Хотелось бы еще примеров :)

У меня нету. Я не использовал его ни разу, только собирался. А примеров на MSDN есть, только они все VB и VC++
Вот например.
http://msdn.microsoft.com/en-us/library/ms994335.aspx

← →
Sergey Masloff (2012-11-01 15:15) [9]

DVM © (01.11.12 14:22) [6]
А SAX парсер (кстати это тот же msxml просто другой режим работы) как поможет в валидации и формировании? Это же просто обходчик выдающий сигналы при встрече с нодами.

По сабжу - к сожалению не помогу. С файлами 20-30 Мб msxml справлялся.
Сейчас все в оракле делаю, он тоже ресурсов жрет поэтому через isntr-substr режу на однотипные куски (а файл 200 Мб это скорее всего список чего-то более мелкого) а их уже валидирую и так далее. Получакется достаточно быстро

← →
Игорь Шевченко © (2012-11-01 15:19) [10]

Sergey Masloff (01.11.12 15:15) [9]

В формировании он вряд ли поможет, а вот в валидации вполне может помочь, загружая только необходимые части XML (это еще будет тестироваться, разумеется).

← →
Sergey Masloff (2012-11-01 15:23) [11]

А так он умеет по схеме проверять... Я и не знал :(
DVM © спасибо

← →
cobalt © (2012-11-01 15:43) [12]

Насчет валидации по схеме не скажу, а вот чтение 300 Мб файл TXMLDocument справляется, хотя и забирает под это от гига памяти.

← →
Медвежонок Пятачок © (2012-11-01 15:47) [13]

а я по схеме никогда не валидирую.
как-то не надобилось никогда.

PS юзать TXMLDocument для чтения - все равно что юзать TTable вместо TQuery

← →
cobalt © (2012-11-01 15:57) [14]

> Медвежонок Пятачок © (01.11.12 15:47) [13]
> PS юзать TXMLDocument для чтения - все равно что юзать TTable вместо TQuery
А что предлагаешь использовать взамен?

← →
Медвежонок Пятачок © (2012-11-01 16:43) [15]

IXMLDOMDocument(2)

То есть выбор узлов запросами, а не сугубо навигационный метод

← →
Пит (2012-11-01 18:13) [16]

мы пришли к выводу, что невозможно использовать готовые XML движки для обработки больших xml-файлов.

Если следовать идеологии XML, то на самом деле ты вынужден распарсивать XML-код в такие структуры, что они обязаны жрать дикое количество памяти. То есть, 100 mb исходного xml будет жрать мегабайт 500-600 памяти, никак не меньше. А не повезет - так еще больше.

Особенно - если хочется формирования и валидации.

Поэтому хочется работать с таким - пиши своё узкоспециализированное решение. В реальности, обычно от всей возможности xml нужно пару процентов.

← →
Inovet © (2012-11-01 21:43) [17]

> [16] Пит (01.11.12 18:13)
> мы пришли к выводу, что невозможно использовать готовые XML движки для обработки больших xml-файлов.

Вот оно и есть. Возможность редактирования человеком в некоем простом текстовом редакторе отпадает, а для нетекстовойй работы фотмат не годится.

Сформировать любого размера - проблем нет, а вот читать эту лабуду при больших объёмах - есть проблемы.

← →
Inovet © (2012-11-01 21:45) [18]

> [17] Inovet © (01.11.12 21:43)

Да, по теме не подскажу.

← →
Dennis I. Komarov © (2012-11-01 21:48) [19]

> а вот читать эту лабуду при больших объёмах - есть проблемы.

Ну читать, проблем то нету, как ex(imp)ort вполне себе...

← →
Rouse_ © (2012-11-01 21:52) [20]

Проблема в том что XML в 200 метров может быть с одним узлом с бинарным блоком, или из миллиарда маленьких, коие хранить в памяти (ну допустим даж в двунаправленом списке) по 12 байт на узел + данные самого узла, что выльется в те-же гигабайты памяти. В прошлой моей задаче я с примерно такой-же задачей столкнулся (хранение и работа с деревьями) правда блобы были на несколько порядков больше, текущее дерево индексов в районе 9 гектаров...
Воть, лично я бы порекомендовал, если не требуется поддержка всех наворотов стандарта, реализовать собственный быстрый парсер

← →
имя (2012-11-01 22:20) [21]

Удалено модератором

← →
Dennis I. Komarov © (2012-11-01 22:30) [22]

Удалено модератором

← →
Rouse_ © (2012-11-01 22:52) [23]

> по 12 байт на узел + данные самого узла, что выльется в
> те-же гигабайты памяти.

Дабы было более понятно, я приведу годичную цитату с нашего внутреннего форума где мы запнулись как раз на больших обьемах мелких данных:

В новой версии ГСИ мы ввели поисковые индексы на базе токенов. Токен - это скажем так некое уникальное слово. Например если у нас есть миллион документов состоящих из трех слов "мама мыла раму" то в итоге у нас на руках будет всего три токена (по одному на каждое слово) и куча индексов, указывающих в каком документе тот или иной токен встречается. В результате (если исключить поиск по параграфам или по дистанции) список документов отбирается меньше чем за 10 миллисекунд. А засада вылезла как раз в количестве этих самих токенов. Мы для себя сделали 10 самых больших баз от 3 гигабайт до 300 мегабайт (т.е. 10 самых больших) и тестировали на них. И скорость и память - все нас устраивало. Пока не пришло время тестировать на полном комплекте баз (sik). А это как раз произошло за день как мы решили отдавать тот вариант финальной беты. Немного математики: мы тестировали на обьеме 5 с половиной гигобайта (реальный общий размер баз), остальные копеешные базы занимают примерно еще гигобайт все вместе. Мы и не предполагали, что в более меньших по объему базах, количество памяти, необходимое под хранение токенов практически идентично большим базам. И тут представьте наше удивление когда приложение просто банально перестает запускаться из-за того что закончилась память на компьютере! WTF!!! Все это из-за того, что большинство слов встречаются повсеместно и будут присутствовать практически в каждом документе, из-за чего количество токенов даже в маленькой базе будет практически идентично размеру большой (около 3 миллионов). А этот нюанс мы полностью пропустили!!! А теперь опять банальная математика. Если в каждой базе будет в среднем по 3 миллионов токенов (а это сейчас так и есть) и допустим что нам нужно хотя бы 4 байта для хранения каждого (в действительности требуется гораздо больше) то получается что для 200 баз нам нужно памяти 2 гигобайта и 288 мегобайт. Т.к. у современного приложения всего доступно для чтения от двух до трех гигобайт (наше умеет работать с тремя) то сами видите с какой проблемой мы столкнулись. Собственно, последнее время перебираем движок, пытаясь впихнуть невпихуемое...

← →
TUser © (2012-11-02 06:51) [24]

Я парсил самописным кодом (без классов, только указатели на record и New) 143 Мб. Это был узел, у которого 100 с чем-то тысяч детей. Работало, но тормозило. Мне не нужна была валидация.

← →
Sergey Masloff (2012-11-02 09:16) [25]

> Inovet © (01.11.12 21:43) [17]
> Сформировать любого размера - проблем нет, а вот читать
> эту лабуду при больших объёмах - есть проблемы.

Вот читать через SAX интерфейс вообще не проблема. Гигабайтные файлы.
Надо проверить как он валидацию для них делает

← →
jack128_ (2012-11-02 10:26) [26]

> Насчет валидации по схеме не скажу, а вот чтение 300 Мб
> файл TXMLDocument справляется, хотя и забирает под это от
> гига памяти.

сильно зависит от структуры файла. Для одного нашего формата он не смог и 60метровый файлик загрузить. сжирал 1.5гига и падал. Так что тут как повезет.

← →
Медвежонок Пятачок © (2012-11-02 13:09) [27]

В реальности, обычно от всей возможности xml нужно пару процентов.

Это как сказать.
Пример:
Пришел я в коллектив, где юзается система отчетов, встроенная в программу.
Там скриптовый язык, доступ к данным, работа с офисом и т.д.
В общем круто все.

Начал дизайнить отчеты и передизайнивать чужие.
Встретил кучу подпорочного нечитаемого слабоподдерживаемого кода, который там был в силу неразвитых структурных типов и однонаправленности датасетов.

Но тут вдруг оказалось, что в отчетах доступно OLE.
Я стал использовать Msxml2.DOMDocument, собирая в него нужные данные, с легкостью их доставал, мог фильтровать и т.д.
И уже по xml данным формировал сложные отчеты.

результат:
Объем необходимого кода упал от двух до трех раз.
Исчезли геморрои с индексными переменными строк в конструкциях типа
Зафигачь_Данные_На_Лист_Excel(1,1,"мапа");
Зафигачь_Данные_На_Лист_Excel(1,2,"мапа");
.....
Зафигачь_Данные_На_Лист_Excel(1,666,"любовь");
Исчезли дебильные циклы поиска-перебора закешированных ранее данных.
Исчезли повторные запросы-перезапросы к базе

Вот так-то так.

← →
Аббат Пиккола (2012-11-02 13:55) [28]

Я для быстрой разборки написал свой собственный примитивный парсер. Который создает FileStream, проходит его один раз, запихивая все в древовидную структуру, которую организовал на основе нескольких своих простых классов. Мне просто было лень изучать имеющиеся парсеры, поэтому я пошел таким путем. Так как круг задач был ограничен разбором "чисто текстовых" файлов и типы данных были заранее известны. Хранил все атрибуты как строки , а обращался за данными, в зависмости от типа (который знал заранее), методами AsInteger, AsString, AsDateTime, которыми снабдил свой класс TXMLNode, передавая в качестве параметра имя нужного атрибута. Разумеется, это кустарный подход. Но если бы у меня стояла задача быстро разбирать большие файлы заранее известных форматов, наверно, я бы опять пошел путем чего-нибудь самописного. По крайней мере в самописном парсере можно добиться максимума производительности, так как ради конкретной задачи можно чем-то ненужным пожертвовать.
Наверно для очень больших файлов хорош подход TUser © (02.11.12 06:51) [24], то есть вместо классов использовать тип record.

← →
Медвежонок Пятачок © (2012-11-02 13:58) [29]

Все верно.
Когда голове работать лень, тогда работают пальцы по набивке индус-кода.

← →
Inovet © (2012-11-02 15:23) [30]

> [28] Аббат Пиккола (02.11.12 13:55)
> Но если бы у меня стояла задача быстро разбирать большие
> файлы заранее известных форматов, наверно, я бы опять пошел
> путем чего-нибудь самописного

Я тоже так думаю. Именно для заранее известных, в которых использутся эти самые 2% от всех возможностей формата.

← →
Игорь Шевченко © (2012-11-02 15:35) [31]

Всем спасибо.
Вариант самописного чтения не рассматривается, буду тестировать SAX для чтения и валидации, при формировании, возможно, будет какой-то самописный набор классов.

← →
Пит (2012-11-02 16:26) [32]

> В реальности, обычно от всей возможности xml нужно пару
> процентов.
>
> Это как сказать.
> Пример:

> В реальности, обычно

← →
Медвежонок Пятачок © (2012-11-02 16:29) [33]

Я показал, что бывает когда решаешь задачу как обычно
и что получается когда решаешь ее необычно.

или ты, пит, думаешь, что я хотел сказать, что я весь такой необычный и задачи мои сверх необычны?

← →
Пит (2012-11-02 21:38) [34]

нет, просто у тебя отсутствует логика.

Я говорил, что обычно вот так-то.

Ты пишешь - "это как сказать, ведь бывает и так-то".

Непонятно к чему ты это сказал, если я изначально показал, что бывает по разному, но обычно так-то.

А как на самом деле - знает топикстартер.

← →
Медвежонок Пятачок © (2012-11-03 15:18) [35]

логика отсутствует у тебя.

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

я привел пример самой обычнейшей задачи, которую решали много лет колхозно.
и привел пример ее же решения с применением xml.

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

но можно решать не колхозно, упрощая код, и повышая его читаемость и сопровождаемость и снижая его индусность.

Это если не зацикливаться на том, сколько процентов лично тебе положено использовать.

← →
Пит (2012-11-05 15:22) [36]

ты сейчас что-то предполагаешь. Типа люди используют XML на 2%, а надо бы больше. Я в отличии от тебя никого жизни учить не собираюсь, просто констатирую факты. Обычно возможности XML используют на пару процентов, я это вижу - я это озвучит. Это моя такая вот статистика. И я знаю, что бывает по-другому, но в целом я вижу, что xml как формат данных используют вот так. У тебя своя статистика ты хочешь сказать? По-моему, ты это не хочешь сказать.
Вот и собственно всё.

Ты начал разговор из серии, что "если бы..". Если бы люди были умнее, если бы они лучше знали, если бы, если бы. Может быть и если бы, то и xml бы на 90% использовался бы. А обычно это передать данные между двумя системами, чтобы тупо свои делимитеры не изобретать, вот и все. Даже валидация по XSD это уже редко где встречается, обычно там где это стало большим промышленным решением. А так "Ну давай короче я тебе в теге FIO буду фамилию имя отчество передавать, а в теге Job - должность". - "Оке".

Поэтому если задача не особо универсальная, то часто хорошее решение написать узкоспециализированный недо XML парсер (а точнее более актуально обычно - creator), который четко быстро сделает то, что от него нужно, дав фору по скорости и ресурсам всем промышленным решениям. Хотя и оказываясь бессильным, если нужно шаг влево, шаг вправо.

← →
Игорь Шевченко © (2012-11-05 16:52) [37]

> Даже валидация по XSD это уже редко где встречается

prove it

← →
Медвежонок Пятачок © (2012-11-05 17:28) [38]

Пит, все что ты хочешь сказать - это то, что есть куча народу, которая на каждый чих ищет или создает собственные реализации того, что уже сто лет как есть.

недальше как на прошлой неделе встретил еще одного такого пита.
Ему нужно было посчитать хеш по sha-512.
Первое что он сделал - стал искать велосипедные реализации этого на паскале.
В то время как готовая реализация в винде сто лет лежит у него под носом

← →
DVM © (2012-11-05 17:43) [39]

> Медвежонок Пятачок © (05.11.12 17:28) [38]

> Ему нужно было посчитать хеш по sha-512.
> Первое что он сделал - стал искать велосипедные реализации
> этого на паскале.
> В то время как готовая реализация в винде сто лет лежит
> у него под носом

Некоторые API от MS настолько замуденые, что зачастую проще написать свое, чем продираться сквозь десятки функций для выполнения простой вещи.
И кроссплатформенно будет.

← →
Медвежонок Пятачок © (2012-11-05 17:49) [40]

Ага.
Но дело в том, что хеш на capicom это ровно четыре строки кода.
Создать объект,
Выставить нужный алгоритм
Вызвать метод Hash
Прочитать результат.

← →
Пит (2012-11-05 18:18) [41]

> prove it

докажите обратное? )
Надо понимать, что такое редко. Валидация по XSD редка по сравнению с количеством случаев использования самого XML. Еще лет 5 назад многие не использовали XML, изобретая собственные форматики. Сейчас уже почти стандартом стало обмениваться XML (думаю, тут спасибо вебу и тому что все привыкли к html, тегам), но вот XSD пока не густо.

Ну и у XSD есть всякие неоднозначности. Например, нам приходили файлы выгрузок. Если производить валидацию вручную, то можно было бы осуществить частичный влив данных, в нашей ситуации это было предпочтительнее. Но поскольку была строгая идеология на валидацию по XSD, то весь XML файл отбраковывался.
Конечно, тут начинается дикая философия - а можно ли доверять одним данным из XML-файла, если другие данные явно бракованные. И дальше - а можно ли вообще доверять источнику, если от него хоть раз пришли бракованные данные. Можно сломать много копий, да и сломали )

Но в целом моя мысль мне кажется и сейчас абсолютно верной. Число использования XML просто на порядки выше использования валидации по XSD.

← →
Пит (2012-11-05 18:21) [42]

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

может быть. И что? Это называется - РЕАЛЬНОЕ ПОЛОЖЕНИЕ ДЕЛО. А если ты хочешь поговорить про сферические кони в вакууме - ты так и говори. Чего ты блин каждый раз пытаешься демонстрировать отсутствие банальной логики? Знаешь, общение с тобой начинает доставлять, посмотри со стороны.

Я тебе говорю: Самые покупаемые в России машины - АвтоВАЗ
Ты мне отвечаешь: - Не говори фигню, потому что те кто покупает ВАЗ - олени!

Ну я не обсуждаю кто олень, а то нет. Я тебе просто говорю, что вот блин вот так вот. Ты какой-то идеалист - отличное наверное качество, но ты пойми о чем идет речь то блин.

← →
Игорь Шевченко © (2012-11-05 19:12) [43]

> докажите обратное? )

Бремя доказательства лежит на утверждающем.

И вообще, завязывай троллить, надоело

← →
Пит (2012-11-05 21:00) [44]

вы избрали слишком удобную тактику. Вы сами ничего не говорите, только критикуете и цепляетесь к словам. Игорь, а вы выскажите свое мнение.

Вы сами как считаете - количество использования XML и валидации по XSD - как соотносятся? Никто и не требует точного ответа, это невозможно подсчитать, просто ваше мнение? Я вот свое мнение высказал.
А то реально удобно, своего мнения не говорить - а чужое критиковать. Если человек пытается свои мысли обосновать - ну значит тролль. Как просто и легко.

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

← →
Пит (2012-11-05 21:08) [45]

ну вот не знаю, можно гугл приплести.

По запросу xml где-то миллиард результатов.
По запросу xsd где-то 17 миллионов.
Разница значительная. Хотя и выводы опосредственные.

Можно по-другому. Учитывая движок msxml

чтобы создать xml парсер, "Msxml2.DOMDocument" - 149 тысяч результатов.
чтобы сделать валидацию - "Msxml2.XMLSchemaCache" - 13 тысяч результатов.

Тут уже разница на порядок, что ближе к истине, имхо.

Хотя я прекрасно понимаю, что дискутировать серьезно никому не нужно. Лучше выплеснуть эмоции "Да он тролль! Бей его" )))

> Пит

Да плюнь ты, конечно же ты прав, XML используется без проверки на соответствие схемам конечно же значительно чаще, чем с оными. Все зависит от области применения его. В ряде случаев полноценный парсер просто технически невозможно реализовать из-за недостаточной производительности оборудования и ограниченных ресурсов устройства в котором так или иначе используется XML. Некоторые просто полагают, что на Win/msxml свет клином сошелся. Альтернативам всегда будет место.

← →
Пит (2012-11-05 21:33) [47]

DVM, спасибо )
Я в принципе почти уверен, что я прав. Но жизнь научила всегда допускать вероятность, что могу ошибаться. Точно также как то, что большинство людей имеют не другое мнение, а говорят иное просто из принципа / неприязни и так далее. Но тем не менее. ИШ из людей с интеллектом выше среднего, так что мало ли есть что сказать )

> Пит (05.11.12 21:33) [47]

Насчет частоты использования XML без проверки на соответствие схемам. Очень, очень часто многие сайты используют не HTML а XHTML страницы (например почти все на движке Drupal такие). XHTML является подмножеством SGML, но по факту он является подмножеством и XML. И хотя в DOCTYPE указано что это XHTML, сервер, отдавая контент клиенту, чаще всего указывает ContentType: text/html, а не application/xhtml+xml. Такие страницы браузер не проверяет вообще на соответствие тому, что это xml, не говоря уж о каких либо схемах. А сайтов таких тьма. Миллионы.

← →
Аббат Пиккола (2012-11-05 22:26) [49]

Спор имеет не техническое и даже не философское, а чисто экономическое решение. Если за грамотное решение задачи Медвежонок Пятачок © получает адекватное блестящее вознаграждение в своей конторе, то он, черт возьми, прав! Если же он делает это из гнилого стахановского энтузиазизма, чтобы доказать всему миру свою кутизну, то он по-своему, черт возьми прав, если только нет профсоюзов. Если же есть профсоюзы, то его следует отдубасить, если он так блестяще работает за копейки, когда мир за те же зарплаты пишет индус-код (не факт, что индус код пишется исключительно от невежества или бездарности, иногда это устраивает прежде всего заказчика, причем в данном случае это заказчика как раз устраивало, что сразу говорит о том, что человек оказался не на своем месте, что ИМХО есть очень нехорошо, если только он не декадентствующий курящий опиум вечером под Агату Кристи программист, служащий искусству ради самого искусства - тогда он крут, и руки прочь от Медвежонка!, и тогда это уже философский разговор, то есть деньги и профсоюзы - идут лесом)...

На мой же взгляд есть много подходов и все они имеют свои плюсы и минусы. Вообще программирование никому не нужно. Программируют (все прикладные задачи) только оттого, что:

1. Либо просто лень искать то, что уже напрограммировали другие
2. Либо искать это дольше и дороже, чем запрограммировать самому.

> Аббат Пиккола (05.11.12 22:26) [49]

> 1. Либо просто лень искать то, что уже напрограммировали
> другие
> 2. Либо искать это дольше и дороже, чем запрограммировать
> самому.

3. Либо то, что напрограммировали другие не устраивает.

← →
Аббат Пиккола (2012-11-05 22:37) [51]

А вообще в той манере, в какой Медвежонок доказывает единственную верность своего подхода, есть один маленький изъян. Используя те же методы можно доказать, что передвижение по городу на чем-либо кроме общественного транспорта есть идиотизм и "индус-код".

Помещение всех пассажиров в общественный транспорт экономит в десятки раз:

1. Количество резины (колес в 30 раз меньше в расчете на рылоо)
2. Бензин (бензина раз в 5 меньше на рыло)
3. Здоровье (меньше кошмарных ДТП)
4. Общее время (не будет вообще пробок)

Осталось лишь всех неразумных горожан в этом убедить. В том, что садясь за баранку своего ауди, он оказывается в состоянии индус-кода, а оказавшись в прекрасном общественном автобусе он оказывается в ином состоянии, так как ему не нужно уже:
1. Тратиться на Audi A8
2. Тратиться на бензин для Audi A8
3. Выглядеть идиотом в своей Audi A8 в пробке.
4. Тратиться затем на утилизацию своей Audi A8, когда та станет металлоломом

и так далее.

Очевидно, что этот чел в той тачке - полный олух.
Но ему нравится быть этим олухом.
Я не вижу в этом никакого зла, если честно.

> Аббат Пиккола (05.11.12 22:37) [51]

> Очевидно, что этот чел в той тачке - полный олух.
> Но ему нравится быть этим олухом.

Он волен распоряжаться своим транспортным средством так как он хочет сам. Это плюс.

← →
Аббат Пиккола (2012-11-05 22:40) [53]

DVM © (05.11.12 22:34) [50]
3. Либо то, что напрограммировали другие не устраивает.

Убедиться в том, что никто не написал то, что нужно, требует такой чудвовищной скорости исследования "всего написаннного другими", перед которым парадокс об Ахиллесе и черепахе меркнет.

← →
Пит (2012-11-05 22:42) [54]

это не говоря о том, что Медвеженок ярый противник общественного транспорта и любит как раз ездить на авто )

> Аббат Пиккола (05.11.12 22:40) [53]

> Убедиться в том, что никто не написал то, что нужно, требует
> такой чудвовищной скорости исследования

странно, у нас с гуглом это максимум 15 минут занимает, в запущенных случаях день-два.

← →
Аббат Пиккола (2012-11-05 22:44) [56]

Я полагаю, что человек, который способен либо найти чужие оптимальные программы, либо найти людей, которые решат какую-то проблему за него, прежде, чем кидаться решить ее самостоятельно пусть даже простым и дешевым способом, не столько хороший программист, сколько отличный будущий руководитель. Это - черта руководителя. Уметь выстроить такого рода архитектуру. К программированию и выбору средств для XML это все не имеет никакого отошения. Я бы такого человека на месте начальства поставил ответственным за очень серьезные и рискованные новые проекты. А не держал бы на обслуживании всякой ерунды.

← →
Аббат Пиккола (2012-11-05 22:50) [57]

DVM © (05.11.12 22:42) [55]
Вы за 15 минут можете оценить все стоимости и экономические риски по использованию чужих программных решений? Когда большинство издателей даже не озвучивают цены? Возможно, Вы работаете в какой-то специфической области, где такое удается.

> Аббат Пиккола (05.11.12 22:50) [57]

> Вы за 15 минут можете оценить все стоимости и экономические
> риски по использованию чужих программных решений?

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

← →
Пит (2012-11-05 22:58) [59]

> не столько хороший программист, сколько отличный будущий
> руководитель

гы гы гы.
Руководитель - это человек, который умеет хорошо руководить людьми. Это - отдельный талант.

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

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

← →
Аббат Пиккола (2012-11-05 23:00) [60]

Я думаю, что фаст-фуд не должен заменять людям домашний обед. Хотя это и глупо - тратить столько времени на приготовление собственной котлеты.

Когда существует полуфабрикатная котлета.

Просто замечал уже много раз. Хорошая полуфабрикатная котлета стоит ДОРОЖЕ "индус-котлеты", изготовленной "на коленках" в домашних условиях. А дешевая полуфабрикатная котлета даже после настройки согласно инструкции вызывает изжогу и мысли о том, как хорошо раньше люди жили, когда не былоор вообще никаких полуфабрикатных котлет, а телята идиллически паслись на лужайке за окном.

Аббат Пиккола (05.11.12 23:00) [60]

Казалось бы, причем тут XML ?

← →
Пит (2012-11-05 23:49) [62]

а разве тема xml не исчерпала себя в этой ветке? Думаю, всё сказано, а котлетки - это вечное )

Кто, чем и как обрабатывает XML-файлы большого объема ? Найти похожие ветки