Re: Несколько вопросов вразброс
Артём Н. -> 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 перед сообщением), скрипт вываливается сразу. Если бы не было
АН> тестов, я бы потом долго мучался, потому что функция не запускается
АН> при первом бэкапе.
Это если ты делаешь ошибку, которую тест уже ловит. А если ты делаешь
ошибку, которую тест еще не ловит (а она будет, и не одна), то результат
будет тот же самый, как если бы теста не было вообще. Внятная и
подробная диагностика поэтому обязательна. Но тесты, если хочешь, тоже
пиши.
>> Особое внимание удели ситуациям, когда в случае ошибки имеет смысл
>> продолжать работать с другими данными (неполный бэкап все же лучше
>> отсутствующего), но донести до ответственного человека, что именно пошло
>> не так.
АН> Сейчас я делаю для себя. :-)
Ну, значит, до тебя. Доносить-то будет скрипт.
>> И регламенту восстановления. Включающему учебные тревоги. Бэкап,
>> который просто есть, никому не интересен. Интересен бэкап, с которого
>> можно (в смысле, достаточное количество людей действительно может)
>> восстановиться.
АН> Я понимаю. К счастью, не у себя бэкапами занимаюсь не я. :-)
Но у себя-то ими занимаешься ты.
АН> Полюбопытствую, кстати, как у них всё построено. Но там нет одной
АН> серверной: очень большая распределённая сеть, несколько
АН> датацентров, куча машин нижнего уровня, много подсистем...
Из этого, кстати, не следует, что у них правильный регламент работы с
бэкапами. Так что ты не только поинтересуйся, но и хорошо подумай над
тем, что узнаешь.
Reply to: