[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: