Артём Н. -> debian-russian@lists.debian.org @ Thu, 05 Jul 2012 19:38:56 +0400:
>> >> На практике же основная проблема тестов заключается в том, что они сами >> >> содержат ошибки и часто тестируют не то, что надо >> АН> Тесты для тестов... >< Тесты, в принципе, должны быть просты и >> АН> малы, как мне кажется. >> Тогда они не покроют код. АН> Но это лучше, чем ничего? Теоретически да. Практически - это сильно зависит от успешности создания у программиста иллюзии "код тестируется". >> И каждый из них >> имеет примерно тот же размер, что тестируемый код. Вот тебе уже тесты >> втрое толще тестируемого кода. >> И иначе не получается, а асимптотику я, исходя из своих знаний теории, >> оцениваю как экспоненциальную. Т.е. объем тестов - некая константа в >> степени объема кода. Время их выполнения - другая константа, >> побольше... АН> И на практике? АН> Но это не говорит о том, что нужно от них отказываться... И на практике. Нет, от них не отказываются. Но если появляется возможность заменить тест доказательством, замененный тест с радостью выкидывают. >> >> Так вот, я не поручусь, что агда тебя заставит доказать программу. >> >> Скорее всего, не заставит. Но то, что она согласится скомпилировать, >> >> будет надежнее, чем то, что ты сможешь автоматически оттестировать за >> >> разумное время. Ключевое слово тут "автоматически" - ручное >> >> тестированние может открыть много нового. >> >> >> >> >> >> >> >> Любой статически типизированный функциональный язык с >> нормальной >> >> >> >> >> >> системой типов, начиная с того же Haskell или Ocaml. >> >> >> >> >> АН> Ocaml? Любопытно. Пожалуй, посмотрю подробнее. >> >> >> >> >> АН> Для него есть какая-то IDE? И как с библиотеками? >> >> >> >> >> Я знаю одну IDE на все случаи жизни. Emacs. >> >> >> >> АН> И для всяких там GUI? ;-) В общем, я им не пользуюсь. >> >> >> >> Ну да. Поскольку мои дизайнерские способности ниже средних, в >> отличие >> >> >> >> от способностей в разработке поведения, я предпочитаю GUI, >> которые >> >> >> >> пишут, а не рисуют. Внешний вид - дефолтный, а поведение >> описывается >> >> >> >> словами. >> >> >> АН> Дык, "внешний вид" - это не картинка кнопки, а компоновка. Всё >> же >> >> >> АН> словами не опишешь. Видеть надо. >> >> >> Компоновка как раз очень неплохо описывается словами. Заодно потом >> не >> >> >> возникает типичных для мышконавозенного гуя ситуаций, когда при >> переводе >> >> >> на русский половина надписей получается обрезанной, и в лучшем >> случае - >> >> >> поперек, а то я у фотошопа видал, что видно нижнюю половину одной >> строки >> >> >> и верхнюю - другой... >> >> АН> Я понимаю, что практически любой интерфейс описывается словами. :-) >> >> АН> Такой же язык. Но создавать его, описывая словами, мне кажется не >> >> АН> самой лучшей и перспективной идеей. >> >> >> >> А зря. Если описывать его поведение словами, предварительно подуманными >> >> головой, а визуал оставить на простенькую автоматику, то... выглядеть он >> >> будет не шедеврально. >> АН> Выглядеть - в плане? >> >> Ну вот тебе не нравится интерфейс, сделанный на Tk. Внешне. Типа, >> gtk'шный круче. С виду. АН> Терпеть его не могу. Стараюсь программы с gtk интерфейсом АН> использовать только когда нет альтернативы. Предпочитаю QT. Ну, не важно. Пусть qt. По мне ни то, ни другое с виду не лучше Tk, а наблюдаю я сейчас перед собой интерфейсы, сделанные вообще на lucid (emacs) и на голом xt (xterm), со старательно оторванными менюшками и скроллбарами, но на вкус и цвет все фломастеры разные. Суть в том, что чтобы создать шедевральный внешний вид, нужен художник. Ну, в крайнем случае гениальный дизайнер. Нет, просто хорошего не хватит, у него не получится шедевр. >> >> Зато им будет удобно пользоваться. А от >> >> интерфейса, о чем современные мышевозильцы под давлением маркетологов >> >> обычно забывают, требуется именно удобно себя вести, а не красиво >> >> выглядеть. Иначе непонятно, зачем он вообще нужен - если ты хочешь >> >> красивого, выведи себе xsetroot'ом на весь экран картину Рериха, и сиди, >> >> наслаждайся... >> АН> Построение интерфейса не сводится к его описанию. >> АН> То, как он выглядит, нельзя отделять от того, как он себя ведёт. >> АН> "Красота" должна тоже быть. >> Красота должна сводиться к удобству. Если шрифт корявый, его неудобно >> читать (привет вашей gtk, которая работает через fontconfig, который >> подставляет шрифты взамен отсуствующих так, что хочется приговорить его >> автора весь остаток жизни смотреть на эти подстановки). АН> Ну, я о таком не знаю. :-) >> Если его удобно читать, то он красивый. АН> o.O ЩИТО? Шрифт Mistral, Vladimir Script или Brush Script читать неудобно АН> (причём, не только рукописные, но и большую часть декоративных шрифтов). АН> Тем не менее, он красивый. Я не согласен с этим утверждением. АН> Но, тем не менее, они используются (и многие стоят денег). И очень АН> полезны, если используются к месту. Их место - _выделение_ АН> логотипов, заголовков, мест акцентирования внимания. Возбуждение хватательного рефлекса их место. И да, они на нем смотрятся хорошо. Подавляющее большинство декоративных шрифтов (ну, тех, что я видел) сделаны так, что прочесть, что именно этим шрифтом написано - довольно сложная задача даже для носителя языка. Только при их _правильном_ применении никто не рассчитывает, что тебе удастся прочесть надпись. Рассчитывают на запоминание/узнавание картинки в голове и на провокацию хватательного рефлекса. >> >> Вот C++ получился еще и непрактичным. Хотя лемминги пользуются. >> АН> Да и не только они. Но C++ - это что-то монструозное. Кстати, ведь >> АН> он ещё и функциональную парадигму включает сейчас? >> Если я правильно ошибаюсь, то еще хуже, чем включал ее C. То есть на C >> это солнце приходилось закатывать вручную, но это хотя бы можно было >> написать так, чтобы код был обозрим, а сообщения об ошибках понятны... АН> Я о том, что новый "стандарт" включает какие-то средства для поддержки АН> функциональной парадигмы (сейчас уже не помню что). Боюсь, что авторы этого стандарта малость не в курсе того, что такое функциональная парадигма. Потому что для полноценной поддержки функциональной парадигмы нужно полностью менять парадигму С++. А неполноценная и в K&R C есть. >> >> >> Для задач, которые можно решать на sh, этого достаточно. Ну, >> может, еще >> >> >> IPC::Open2 и IPC::Open3, когда надо и на вход подавать поток, и на >> >> >> выходе его забирать, да еще (в случае Open3) stderr анализировать. >> >> АН> Не знаю, может Perl и хорош. Но Camel Book, о котором тут писали >> на 1000 с >> >> АН> копейками страниц? И тогда уж сравните с книгой K&R... >> >> Зато между объемом кода и временем для решения одной и той же задачи >> >> разница будет в противоположную сторону, и куда больше. Книгу ты >> >> читаешь один раз (потом можешь обращаться как к справочнику, но тут уже >> >> объем мало влияет). Код пишешь (предположительно) многократно. Дальше >> >> думай сам. >> АН> Дело не столько в количестве часов, потраченном на книгу, сколько в >> АН> том, что оба языка позволяют сделать одно и тоже. >> Да. То же, что ассемблер, машина Тьюринга и Haskell. Они все >> Тьюринг-полны. Вопрос в том, сколько времени у тебя уйдет на одну и ту >> же задачу на этих инструментах. АН> Вы утрируете. :-) Да. С целью указать тебе, в чем именно ты ошибаешься. АН> И, опять же, какой ассемблер? У него недостатком (в данном АН> контексте) является привязка к архитектуре, а отнюдь не бедность АН> выразительных средств (MASM и fasm вспомните) или отсутствие АН> библиотек. Любой. У самого прекрасного ассемблера выразительные средства на порядок ниже, чем у Lisp, и на два - чем у Haskell. Но теоретически и то, и другое, и третье позволяют решать те же задачи. Вопрос в затраченных на их решение усилиях программиста. >> Ну, сам я гуй не особо писал, особенно на C. Код к базам данных тоже, >> но видел, как он выглядит. На перле писал, и много. Куда больше, чем >> успел бы на C за всю свою жизнь. С сетевыми протоколами разница >> поменьше, раза в три, не больше, но там и библиотеки попроще. С сетью >> можно tcl с C сравнить, вот тут разница будет разительна. АН> Да, я понял почему мне Perl как-то не очень "по нутру". Мне он АН> кажется очень перегруженным, по ощущениям. Как и C++, но C++ - это, АН> всё-таки C+объекты (ну ещё шаблоны), a Perl - это и sh, и awk, и АН> sed - куча всего... Ты почти попал. Ларри Уолл взялся за создание Perl, а я берусь за его использование ровно тогда, когда задача такова, что комбинация из sh, awk и sed становится для ее решения слишком тяжеловесной и плохо управляемой. Чем он лучше C++ - так это тем, что в нем можно пользоваться ровно тем подмножеством, которое нужно для задачи. В случае с C++ у тебя есть три уровня - либо чистый C, либо довольно жесткая объектная система С++ в полном объеме, либо к ней еще и темплейты, опять же в полном объеме. Попытки использовать только часть объектной системы в C++ чреваты боком. В Perl - нет. Вплоть до того, что если ты начал решать задачу на встроенных средствах, а потом понял, что она поставлена слишком плохо, и надо вводить интерфейсы, очень легко прямо на ходу и постепенно преобразовать средства к объектным. >> >> >> Пока я не стал большим любителем ОС Emacs, я пользовался tkabber в >> >> >> качестве jabber-клиента. >> >> АН> Этот тот, у которого суровый серый интерфейс? o.O >> >> Да. Но можно раскрасить в несколько строчек конфига. Мне было не надо, >> >> он мне для разговоров словами был нужен, а не для любования. А в >> >> разговоре чаще важно, чтобы ничего, в том числе попугайская раскраска, >> >> не отвлекало от темы. >> АН> И ещё он всегда выглядит в стиле tk, где бы не запускался: великое >> АН> единообразие. :-) >> Есть мнение, что это преимущество, а не недостаток. Тут, правда, многое >> зависит от того, с чем ты работаешь - с приложением или с системой. И >> если с системой, то что ты под нею понимаешь. Возможно, для tkabber это >> скорее недостаток, но если я сяду за винду и запущу в ней tkabber, мне >> удобнее будет видеть его таким же, как в линуксе, и чтобы вел себя так >> же. АН> Возможно. Но, думаю, если это не специфическое приложение, которое АН> работает на системе монопольно (большой АРМ, например), оно должно АН> выглядеть так же, как и все остальные приложения. Думаю, каша из АН> Motif/Qt/Tk/GTK и "чего-то своего" вам знакома? Меня не шибко смущает даже каша из vim и emacs. По сравнению с этим разница между Motif и Qt, гм, несущественна. Проблема подхода имени Раскина заключается в том, что разные приложения решают разные задачи, и потому единый интерфейс для них, увы, не годится. >> АН> Я хотел (и хочу) надёжного и быстрого ПО, которое может быть >> АН> написано сравнительно просто, быстро, без акцента на языке и >> АН> сильного напряжения. :-) >> Так чего ж ты тогда от перла отмахиваешься? У лиспов и tcl порог >> вхождения выше, хорошо бы иметь высшее образование в Computer Science >> (не обязательно, но хорошо бы). Для быстрого вхождения в Haskell хорошо >> бы иметь в Computer Science уже степень, причем защищенную не на >> реферате, а на самостоятельной работе - иначе вхождение в него занимает >> годы. А вот перлом до запрошенного тобой уровня можно овладеть довольно >> быстро. АН> А какое будет качество кода? :-\ А это сильно от головы зависит. Если с умом входить и прислушиваться к тому, какие практики рекомендуются в большинстве случаев, а какие нет (это в Camel Book, в общем, изложено), то будет вполне неплохое, я наблюдал. >> АН> Scheme - это почти Lisp или нет? >> Это один из диалектов лиспа. Довольно сильно отличающийся о классики >> (что от исходного, что от Common). Сознательно урезанный в синтаксисе и >> семантике для того, чтобы можно было быстрее осваивать. Макросы там >> появились не сразу, и их там недолюбливают (и прямо скажем, есть за >> что), зато там давно есть call/cc, которой в явном виде нет в остальных >> лиспах. >> Собственно, для человека с бэкграундом в C и sh call/cc окажется в >> scheme единственным серьезно незнакомым оборотом, функция как >> first-class object осваивается быстро. Зато ОЧЕНЬ СЕРЬЕЗНО незнакомым. АН> Это преодолимо. :-) Вероятно, да. Но вот мне пока не удалось. >> Чисто технически - да. Но опять же напомню про машину Тьюринга. Все >> языки программирования, кроме машинных кодов - они не про объяснение >> компьютеру. Они про объяснение человеку, про процесс разработки. То же >> и тут. Если огурца интерпретировать как TDD с человеческим языком, это >> будет один процесс разработки. Если как BDD - другой. АН> Ну, плюс более полный охват. Нет? Да нет, охват-то как раз менее полный. Существенно то, что заказчик, разработчик и компьютер могут говорить о разрабатываемом софте на одном языке. Я, правда, пока не понял, получилось ли у них, но если получилось... >> Комментарий имеет смысл писать о том, почему тут такое значение, а не о >> том, где еще оно будет меняться. АН> man (о чём вы и упомянули), как главный комментарий. Большая проблема манов в том, что это отдельные от кода тексты. Поэтому поддерживать их синхронизированными с кодом непросто, а тестов на это нет, кажется, ни у кого. Да, есть некоторые средства создания манов прямо из комментариев при коде. Угадай с трех раз, у какого языка это _на практике_ получается лучше всего, и кто на втором месте? >> >> >> Нет, у тех, кто делает такие системы конфигурации. Начиная с >> виндового >> >> >> реестра, и заканчивая гномовским, и еще кем-то у нас в дистрибутиве >> же, >> >> >> кто ради не помню чего, чуть ли не тоже конфигурации, тянет за собой >> >> >> персональный экземпляр mysqld для каждого юзера. Узнать о >> существовании >> >> >> sqlite он, видимо, ниасилил... >> >> АН> Дык, реестр - это БД. И sqllite - БД. И mysql - БД. >> >> АН> Всё одно. Принципиальной разницы (на этом уровне) между ними нет: к >> >> АН> одному они все и пришли. >> >> >> >> Э, нет. /etc/passwd и /etc/network/interfaces - это тоже БД. Дьявол в >> >> деталях. А в деталях... >> АН> Нет, это другое: в них нет главного - отношений. :-D Мда. :-( >> Ошибаешься. Отношения в них есть. Не было бы в /etc/passwd отношения >> между именем и uid - ты б залогиниться не смог. АН> В INI файле тоже есть такие отношения. Но БД его назвать нельзя. Можно и нужно. АН> В passwd есть записи, а не отношения (если вы хотите сказать, что я АН> не прав, то отношения какого типа?). Я правильно понял, что ты Дейта еще не прочитал? Отношение в реляционной модели - это по определению множество однотипных записей. /etc/passwd - это ровно одно отношение, связывающее uid, gid, login, home dir, shell и GECOS. В понятиях реляционной модели. Буквально идеальный пример отношения. АН> UID является ключом для выборки одного из независимых АН> кортежей. Т.о., это просто плоская таблица. Вот passwd и group - АН> уже представляют из себя БД. Так что, passwd и БД - это совершенно АН> разные вещи. БД из одного отношения - несколько вырожденная, но все же БД. >> АН> БД - это именно структура связей. Реестр - иерархическая БД, всякие >> АН> *sql - реляционные, но везде есть отношения. >> >> >> - реестр - единая БД для множества никак не связанных между собой >> >> программ, которая в результате оказывается труднообозримой и крайне >> >> слабо пригодной для чтения или изменения человеком (а какая же она >> >> после этого конфигурация, если чтобы в нее залезть, требуется >> >> отдельная программа со специфическим интерфейсом, а чтобы разобраться >> >> в том, что там содержится - отдел аналитики?) >> АН> Кстати, реестр - это отдельный сложный вопрос. Ведь он похож на >> АН> ФС. С некоторой точки зрения - иерархия в /etc тоже похожа на >> АН> реестр... Основная разница в том, что ключи реестра нечитаемы для >> АН> человека (в том смысле, что там используются UID, глубокая >> АН> вложенность и низкая ортогональность (к примеру, информация о >> АН> расширениях, как правило, записывается в двух местах, а для чего?) >> АН> и т.п.). И, вдобавок, реестр - лишняя сущность. Его функцию может >> АН> выполнять ФС. Скорее всего, они создали его ради оптимизации: >> АН> ускорения доступа к большому числу настроек системы. Но я не >> АН> интересовался. Если это так, то проблема не в реестре. А в >> АН> системе: "архитектура" реестра - прямое следствие из архитектуры >> АН> системы. >> >> Много чего похоже на ФС. dbm можно сделать похожей на ФС. На >> реляционной базе эмулятор ФС делается с легкостью. АН> Так есть и ФС, являющиеся БД. Тот же ZFS. Это уровень хранения АН> данных, а не уровень модели. Модель - дерево. АН> Я не про это. Просто не совсем корректно выразился. АН> Реестр буквально похож на ФС. На NTFS. АН> У него нет, наверное, ссылок (в чём я не уверен), а всё остальное есть. Ну, все же не все остальное. И у него по крайней мере типизированные значения. В отличие от файлов. И еще кое-что несколько иначе. В общем, я бы сказал, что у реестра с NTFS не сильно больше общего, чем с любым другим деревом. АН> С точки зрения пользователя - это ФС, которая содержит всё тоже АН> самое (в т.ч. установку прав доступа на ветви). Отсюда АН> напрашивается вывод: его стоило делать не на ФС только ради АН> оптимизации. Должен заметить, что в то время, когда был придуман реестр, в виндах еще не было прав доступа как таковых. Так что в доказательстве ошибка :-) >> dbm можно сделать похожей на ФС. АН> whatis dbm? o.O База данных типа "ключ-значение", заточенная под быстрое выполнение одной операции - поиска по ключу. По точному совпадению. >> Проблема с реестром >> как хранилищем конфигурации в том, что _человеку_ трудно с такой >> конфигурацией работать. А конфигурация - она, в общем, для человека >> отделена от кода и данных в отдельную сущность. АН> То, что с ним трудно работать и так ясно. Важно полно ответить на АН> вопрос - почему? Потому что те, кто придумал реестр, решали НЕ ТУ задачу. Нет, можно высказать конспирологическое предположение, что именно ту, что это был далеко идущий план по созданию империи Зла, но я склонен считать, что просто не ту. Увы, на практике отказ от неудачных, но _как-то уже работающих_ решений - слишком высокий психологический барьер. А _как-то_ в нем хранить конфигурацию можно, как и еще тысячей других неподходящих способов. >> >> - mysql же отличается от этих двоих тем, что это не БД, а СУБД. >> АН> Как и Sqlite. :-) >> Ну, можно и так интерпретировать. В зависимости от того, на чем >> акцентировать внимание. Если на том, что sqlite предоставляет >> транзакционность - то да, а если на том, что СУБД - это отдельная >> сущность, с протоколами доступа, желательно отдельным DBA, который умеет >> ее настраивать и т.д., то нет. Я акцентировал на втором. АН> Почему СУБД должна быть обязательно неким сложным комплексом с АН> кучей систем? По-моему, это особенности реализации. Потому что СУБД - это Система Управления Базами Данных. Более простую сущность проще и назовут. >> >> Он, опять же, хорош на своих задачах, >> >> но если я вижу _персональный_ mysqld, я понимаю, что программами этого >> >> разработчика пользоваться не следует даже начинать, лучше сразу >> >> поискать, а то и написать альтернативу. А то себе дороже выйдет. >> АН> Почему? Ну, например, программа тащит его в дистрибьютиве или >> АН> требует для установки (snort-mysql, например). Это же не значит, >> АН> что она обязательно плохо написана..? >> Да потому что использование mysql там, где достаточно как максимум >> sqlite, а чаще - простого текстового файла, говорит о квалификации >> разработчика, и хорошего оно о ней говорит очень мало. И позволяет >> предположить, что если автоматика этой системы хоть чем-то тебя не >> устраивает, ты можешь застрелиться - это будет более легкая смерть, чем >> муки попыток сконфигурировать ее под себя. АН> Ага. Но есть и другой вариант - персональный "*bd*d", там где АН> вполне подошёл бы mysqld. Ещё хуже. :-( >> Ну, я уж молчу про то, что о понятии "ноутбук работает от аккумулятора" >> автор этой программы, вероятно, не слышал. АН> Хм... Mysql так сильно жрёт CPU? При использовании - да, конечно. Ты прикинь, какую хмурую тучу всего ему надо потрогать на каждый чих. Я надеюсь, что он не жрет процессор хотя бы при неиспользовании, но и на подъем его из свопа или дозагрузку страниц с диска при использовании раз в несколько минут тоже требуется немало энергии. Добавить оперативной памяти не предлагать - ее поддержание - это второй по прожорливости потребитель аккумулятора. >> >> >> АН> Ну а какие варианты, когда требуется такая сложная система? >> >> >> АН> Изобретать свой велосипед, в итоге сводящийся с СУБД? >> >> >> Если такая сложная система конфигурации действительно требуется, то >> >> >> уровень сложности самой задачи там запредельный. Настолько >> >> >> запредельный, что я, со всем своим опытом, сто раз подумаю, прежде >> чем >> >> >> начать ее решать. >> >> АН> Обязательно? А если это расширяемая задача. А разработчики >> проектируют >> >> АН> "сверху-вниз", действуя на далёкую перспективу? >> >> >> >> _Так_ проектируемая система не доживет до этой далекой перспективы. А >> >> если доживет, то обнаружит, что на самом деле все совсем не так, как >> >> казалось много лет назад, на стадии проектирования. >> АН> Мда. Возможно. Тоже нужен баланс. >> Да не возможно, а точно. Предъяви мне хоть одну систему, которая так >> проектировалась и до этой перспективы дожила. АН> Ээээ... Multics? OS/360 (хотя, не уверен)? Multics, если я правильно ошибаюсь, не дожила даже до начала ее использования. С OS/360 было получше, но тоже есть большие сомнения. >> Некоторый баланс нужен, конечно, KISS в чистом виде приводит к >> растягиванию итераций со второй по примерно десятую раза в три каждой. >> Но баланс должен быть довольно сильно смещен в сторону KISS. АН> Да, только тоже надо понять где simple, а где - нет. На этот вопрос дают ответ все agile-методики. simple - это когда ты можешь оценить время выполнения подзадачи единицами часов, в крайнем случае дней, и не ошибаешься в прогнозе. >> >> СУБД, как правило, пытаются хранить свои настройки в себе же. >> >> Получается плохо :-) >> АН> Ну, в случае падения (но для этого есть другие решения). А так - >> АН> что плохого? >> Ну, для начала, пока что ни одной не удалось. Чтобы упасть, надо сперва >> взлететь. А если у нее вся конфигурация внутри базы данных, то откуда >> она узнает, где базу-то взять? АН> Так, в смысле, в БД хранится схема данных и права АН> пользователей. Что в этом плохого? Так это, мягко говоря, не конфигурация БД. Ну, в крайнем случае НЕ ВСЯ конфигурация, но я бы сказал, что с точки зрения БД это вообще не конфигурация, а часть данных. >> Короче, сходи на сайты MySQL и PostgreSQL и почитай, насколько там >> развесистые конфиги, хранящиеся вне БД. По крайней мере постгресовцы >> точно пытались по максимуму втянуть конфигурацию в БД. И всё, что >> осталось снаружи - это то, что втянуть не удалось. АН> Про Postgres не знаю. Про mysql - знаю. Помнится, ничего такого уж АН> очень сильно развесистого там нет. Плохо помнится. Количество настраиваемых через текстовый конфиг и только через него параметров там измеряется десятками. Это не значит, что их надо задавать непременно все, как и в случае с клиентом - некоторые умолчания почти для всех параметров вкомпилированы при сборке, и если они тебя устраивают, в конфиг их можно не писать. Но их НЕВОЗМОЖНО хранить в базе. >> >> Нет, я понял мысль. Если у тебя вся логика в БД, то да, имеет смысл по >> >> крайней мере пытаться хранить там настройки приложения. И то - >> >> настройки клиента тебе таки придется, скорее всего, вынести еще куда-то, >> >> а то он не сумеет подключиться. >> АН> Минимум, необходимый для подключения и плюс немного "сахара" >> АН> (достаточно общего). >> Ну, опять-таки, хочешь узнать, каковы практические требования - сходи на >> те же два сайта и почитай про конфиги клиентских библиотек. АН> И с библиотекой их работал. Там не так много. Если, конечно, не АН> требуется нечто совсем уж нестандартное. Я думаю, у них в конфиге нет ни одного параметра, который никогда никому не требовался. И параметров этих там десятки. >> >> Но практика показывает, что хранимые >> >> процедуры - это далеко не самое удобное место для хранения логики. У >> >> них обычно язык сильно ограничен, и реализация на них этой логики >> >> получается куда более геморройной, чем вне базы. >> АН> Но куда от них деться? >> АН> Они дают: >> АН> 1. Безопасность; >> АН> 2. Дополнительную надёжность; >> АН> 3. Часто - скорость; >> АН> 4. Унификацию интерфейса (что не на последнем месте, просто не всегда >> требуется). >> >> АН> И что, есть альтернатива (выделенный сервер приложений - не в счёт)? >> >> Именно выделенный сервер приложений. АН> Но это вариант для слишком масштабного проекта. А если масштаб не АН> позволяет? Сервер приложений может быть процессом на той же машине. Тебя сильно напрягает в смысле масштаба, скажем, cron? Типичный сервер приложения. С нетипичным протоколом взаимодействия, правда. >> И только если ты упираешья в >> скорость и хранимая процедура действительно позволяет ускорить работу (а >> не наоборот, что тоже бывает) - то хранимая процедура. Всё остальное >> выделенный сервер приложений (вернее, сервер приложения - на каждое >> приложение имеет смысл держать свой) обеспечивает лучше. Даже >> унификацию интерфейса к банальному выполнению SQL-запросов обеспечивает >> никак не сама СУБД, а библиотека DBD :-) АН> И ещё сервер приложений тоже должен на чём-то работать... А база данных типа на мировом эфире работает? АН> Сервер приложений должен представлять собой известный движок (чтобы АН> обеспечить независимость от платформы). Либо сервер приложений, как АН> таковой, к примеру Java серверы приложений, либо легковесный АН> известный скриптовый движок, который встроен в минимальную АН> обвязку. Это позволит весь комплекс СУБД/СП/клиент запустить на АН> одной машине. А, при необходимости, развернуть на любой ОС. АН> Вариант? Ну, типа да. Я бы еще предостерег от Java. Намучаешься и потеряешь время. И еще. Если задача совсем легковесная, часто лучше изобрести свой велосипед, а не настраивать готовый движок. Фигня, собственно, в чем - никакой стандартный движок не решает ТВОЮ задачу. Он решает задачу, к которой твою еще надо свести, и это тоже не бесплатно. >> АН> Ещё хочется что-то делать, но очень хочется такого >> АН> избежать. Надоело. И вопрос - как? >> Вот если хочешь избежать - выдели логику в отдельное место. БД есть БД, >> и не стоит сливать на нее несвойственные ей задачи. А свойственны ей >> хранение и быстрая выдача данных, если смотреть независимо от >> архитектуры, а апдейт их от архитектуры уже зависит. Апдейт записей по >> одной, наприме, не свойствен реляционной БД, и реляционки к таким >> задачам прикручивают не от хорошей жизни, а от недостатка готовых к >> использованию в production альтернатив. Типа готовых реляционных СУБД >> много, а нереляционных мало, и положить это на реляционную модель >> неудобно, но можно. >> Чего у нас там не совсем сырого и нормально доступного из нереляционных, >> помимо BerkeleyDB? MongoDB только? АН> О нереляционных я знаю только по теории. На практике не сталкивался. А посмотри. Полезно для снятия шор. >> А идея пихать в базу данных бизнес-логику на практике показала себя >> неудачной. Или отдельный сервер приложения, через который клиенты ходят >> в БД (более управляемая конструкция), или, если задача попроще, встроить >> в клиента. АН> Причём, сервер приложений не обязательно должен быть сетевым. :-) АН> В случае со скриптовым движком. Есть ядро (ну, например, взять MVC шаблон): АН> обвязка+движок - контроллер. V и C - подключаемый интерфейс ввода-вывода (ИВВ) АН> (думаю, здесь инверсия зависимостей к месту). ИВВ может быть любой. АН> Как варианты: сеть, вызовы функций, IPC. АН> Первый вариант позволит построить на ядре сетевой сервер для крупных приложений. АН> Второй вариант позволит построить тонкий клиент, включающий в код сервер АН> приложений и обращающийся к ядру напрямую. АН> Третий вариант позволит построить взаимодействие на локальной машине нескольких АН> клиентов (это мои фантазии, ы, эротические - терминальный сервер (не обязательно АН> для CLI клиентов o.O), например, хотя реально - это нафиг не нужно), не АН> используя между ними сеть. АН> И ещё куча вариантов. А логика сервера может быть программируемой на люом АН> понятном языке (даже больше - наверняка есть движки с бэкэндами и фронтэндами АН> под желаемый язык, как и движки с настраиваемым синтаксисом, о которых я просто АН> не знаю), к примеру PascalScript или JavaScript или диалект Pascal для 1С. АН> Причём, есть вариант JITC... АН> Хм... Реально ли? Не слишком сложно? Что-то у тебя действительно эротические какие-то фантазии. Реально, но слишком сложно. Ты возьми конкретную задачу и попытайся решить ее самым простым способом. Начиная с собственного велосипеда. Чтобы когда ты соберешься применить что-то готовое и развесистое, ты уже понимал, что именно, почему именно его, и как именно ты собираешься заставлять эту хреновину решать именно твою задачу. >> Большинство >> языков для прототипирования и мейнстримных к добавлению абстракций >> приспособлены не очень хорошо, но если на мейнстримных это еще окупается >> (я бы сказал, что не окупается сам мейнстримный язык), то на скриптовых >> чаще нет. Ну и ORM - это довольно слабая абстракция (собственно, потому >> ее добавление так просто и потому оно так редко окупается - добавить-то >> просто, да пользы мало). АН> Вопрос - какой ОРП. Всё зависит от уровня представления. Я добавил АН> именно ради абстракции. Грубо говоря, клиент - это клиент, а АН> договор - это договор. Следовательно, я могу оперировать в АН> терминах предметной области (реально - так красиво не получилось). Во-во. "Реально так красиво не получилось". Так оно обычно и (не) получается. Именно на эту тему и надо думать, решая, нужен ли ORM. >> Вот в частноти, если к задаче хорошо >> прикручивается ORM - значит, задача по-хорошему не под реляционку. То >> есть, может, ее и надо сделать на реляционке, потому что больше не на >> чем, но по крайней мере подумать об альтернативах стоит. АН> О каких? О MongoDB с ее "документоориентированной" моделью. О BerkeleyDB, если у тебя доступ в основном по primary ключу и нету статистической обработки данных. Может быть, стоит глянуть еще в сторону какой-нибудь DB2, но я вообще не знаю, про что она. >> Если говорить о скриптах бэкапа, с которых мы начинали, то я бы >> рекомендовал не TDD, а своевременное _корректное_ прерывание обработки >> (возвращаясь к языкам - возьми perl или tcl, и не ленись кидать и ловить >> исключения, на этой задаче это подходящий инструмент) с подробной >> диагностикой (если perl - освой модуль Carp и функцию confess оттуда). АН> А мне TDD понравился. АН> Если я делаю ошибку (например, вплоть до того, что забыл поставить АН> echo перед сообщением), скрипт вываливается сразу. Если бы не было АН> тестов, я бы потом долго мучался, потому что функция не запускается АН> при первом бэкапе. Это если ты делаешь ошибку, которую тест уже ловит. А если ты делаешь ошибку, которую тест еще не ловит (а она будет, и не одна), то результат будет тот же самый, как если бы теста не было вообще. Внятная и подробная диагностика поэтому обязательна. Но тесты, если хочешь, тоже пиши. >> Особое внимание удели ситуациям, когда в случае ошибки имеет смысл >> продолжать работать с другими данными (неполный бэкап все же лучше >> отсутствующего), но донести до ответственного человека, что именно пошло >> не так. АН> Сейчас я делаю для себя. :-) Ну, значит, до тебя. Доносить-то будет скрипт. >> И регламенту восстановления. Включающему учебные тревоги. Бэкап, >> который просто есть, никому не интересен. Интересен бэкап, с которого >> можно (в смысле, достаточное количество людей действительно может) >> восстановиться. АН> Я понимаю. К счастью, не у себя бэкапами занимаюсь не я. :-) Но у себя-то ими занимаешься ты. АН> Полюбопытствую, кстати, как у них всё построено. Но там нет одной АН> серверной: очень большая распределённая сеть, несколько АН> датацентров, куча машин нижнего уровня, много подсистем... Из этого, кстати, не следует, что у них правильный регламент работы с бэкапами. Так что ты не только поинтересуйся, но и хорошо подумай над тем, что узнаешь. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87liiyulrq....@wizzle.ran.pp.ru