Re: Несколько вопросов вразброс
04.07.2012 23:52, Artem Chuprina пишет:
> >> На практике же основная проблема тестов заключается в том, что они сами
> >> содержат ошибки и часто тестируют не то, что надо
> АН> Тесты для тестов... >< Тесты, в принципе, должны быть просты и
> АН> малы, как мне кажется.
> Тогда они не покроют код.
Но это лучше, чем ничего?
> И каждый из них
> имеет примерно тот же размер, что тестируемый код. Вот тебе уже тесты
> втрое толще тестируемого кода.
> И иначе не получается, а асимптотику я, исходя из своих знаний теории,
> оцениваю как экспоненциальную. Т.е. объем тестов - некая константа в
> степени объема кода. Время их выполнения - другая константа,
> побольше...
И на практике?
Но это не говорит о том, что нужно от них отказываться...
> >> Так вот, я не поручусь, что агда тебя заставит доказать программу.
> >> Скорее всего, не заставит. Но то, что она согласится скомпилировать,
> >> будет надежнее, чем то, что ты сможешь автоматически оттестировать за
> >> разумное время. Ключевое слово тут "автоматически" - ручное
> >> тестированние может открыть много нового.
> >>
> >> >> >> >> >> Любой статически типизированный функциональный язык с нормальной
> >> >> >> >> >> системой типов, начиная с того же Haskell или Ocaml.
> >> >> >> >> АН> Ocaml? Любопытно. Пожалуй, посмотрю подробнее.
> >> >> >> >> АН> Для него есть какая-то IDE? И как с библиотеками?
> >> >> >> >> Я знаю одну IDE на все случаи жизни. Emacs.
> >> >> >> АН> И для всяких там GUI? ;-) В общем, я им не пользуюсь.
> >> >> >> Ну да. Поскольку мои дизайнерские способности ниже средних, в отличие
> >> >> >> от способностей в разработке поведения, я предпочитаю GUI, которые
> >> >> >> пишут, а не рисуют. Внешний вид - дефолтный, а поведение описывается
> >> >> >> словами.
> >> >> АН> Дык, "внешний вид" - это не картинка кнопки, а компоновка. Всё же
> >> >> АН> словами не опишешь. Видеть надо.
> >> >> Компоновка как раз очень неплохо описывается словами. Заодно потом не
> >> >> возникает типичных для мышконавозенного гуя ситуаций, когда при переводе
> >> >> на русский половина надписей получается обрезанной, и в лучшем случае -
> >> >> поперек, а то я у фотошопа видал, что видно нижнюю половину одной строки
> >> >> и верхнюю - другой...
> >> АН> Я понимаю, что практически любой интерфейс описывается словами. :-)
> >> АН> Такой же язык. Но создавать его, описывая словами, мне кажется не
> >> АН> самой лучшей и перспективной идеей.
> >>
> >> А зря. Если описывать его поведение словами, предварительно подуманными
> >> головой, а визуал оставить на простенькую автоматику, то... выглядеть он
> >> будет не шедеврально.
> АН> Выглядеть - в плане?
>
> Ну вот тебе не нравится интерфейс, сделанный на Tk. Внешне. Типа,
> gtk'шный круче. С виду.
Терпеть его не могу. Стараюсь программы с gtk интерфейсом использовать только
когда нет альтернативы. Предпочитаю QT.
> >> Зато им будет удобно пользоваться. А от
> >> интерфейса, о чем современные мышевозильцы под давлением маркетологов
> >> обычно забывают, требуется именно удобно себя вести, а не красиво
> >> выглядеть. Иначе непонятно, зачем он вообще нужен - если ты хочешь
> >> красивого, выведи себе xsetroot'ом на весь экран картину Рериха, и сиди,
> >> наслаждайся...
> АН> Построение интерфейса не сводится к его описанию.
> АН> То, как он выглядит, нельзя отделять от того, как он себя ведёт.
> АН> "Красота" должна тоже быть.
> Красота должна сводиться к удобству. Если шрифт корявый, его неудобно
> читать (привет вашей gtk, которая работает через fontconfig, который
> подставляет шрифты взамен отсуствующих так, что хочется приговорить его
> автора весь остаток жизни смотреть на эти подстановки).
Ну, я о таком не знаю. :-)
> Если его удобно читать, то он красивый.
o.O ЩИТО? Шрифт Mistral, Vladimir Script или Brush Script читать неудобно
(причём, не только рукописные, но и большую часть декоративных шрифтов).
Тем не менее, он красивый. Я согласен, что делать информационный блок, используя
их, будет только бландинка или психически нездоровый человек.
Но, тем не менее, они используются (и многие стоят денег). И очень полезны, если
используются к месту. Их место - _выделение_ логотипов, заголовков, мест
акцентирования внимания.
И гораздо удобнее читать то, что оформил хороший специалист-дизайнер, правильно
использовав выразительные средства. Они не являются "лишними" наворотами. Просто
у них свои границы применимости.
Не нужно "запрещать красивости", если вы просто не умеете их готовить. :-)
> Вся остальная красота, не сводящаяся к удобству, на моей памяти пользы
> делу не приносила. Продать интерфейс, над которым поработал дизайнер,
> конечно, проще. Проблема в том, что покупает один человек, а работает с
> купленной программой - другой.
1. Дизайнер - не художник.
2. Дизайн - не рисование для того, чтобы "глазу было приятно".
Хороший дизайнер может совместить и удобство, и красоту. Но это сложно.
Кстати, бывают и промышленные дизайнеры. Дизайнеры оборудования... Архитектурные
дизайнеры.
Их работа не сводится к "рисованию". Их работой является построение системы так,
чтобы она удовлетворяла заданным условиям. И, если это дизайнер интерфейсов, это
не значит, что он разрабатывает именно ЧМИ.
> >> АН> C прост и элегантен. :-)
> >> Прост и элегантен, если мы говорим о языках уровня C, Pascal. Если
> >> говорим о скриптовых - tcl. А C - это язык, сделанный практиками для
> >> себя, и простота и элегантность его, как и у Perl, весьма умеренны.
> >> Элегантность в жертву практичности и те, и другие приносили без
> >> содрогания.
> АН> Ну да, только практичность включает элегантность и простоту.
> На практике все хорошо в меру. В том числе элегантность и простота.
Согласен. Главное - найти меру.
> >> Вот C++ получился еще и непрактичным. Хотя лемминги пользуются.
> АН> Да и не только они. Но C++ - это что-то монструозное. Кстати, ведь
> АН> он ещё и функциональную парадигму включает сейчас?
> Если я правильно ошибаюсь, то еще хуже, чем включал ее C. То есть на C
> это солнце приходилось закатывать вручную, но это хотя бы можно было
> написать так, чтобы код был обозрим, а сообщения об ошибках понятны...
Я о том, что новый "стандарт" включает какие-то средства для поддержки
функциональной парадигмы (сейчас уже не помню что).
> >> >> Для задач, которые можно решать на sh, этого достаточно. Ну, может, еще
> >> >> IPC::Open2 и IPC::Open3, когда надо и на вход подавать поток, и на
> >> >> выходе его забирать, да еще (в случае Open3) stderr анализировать.
> >> АН> Не знаю, может Perl и хорош. Но Camel Book, о котором тут писали на 1000 с
> >> АН> копейками страниц? И тогда уж сравните с книгой K&R...
> >> Зато между объемом кода и временем для решения одной и той же задачи
> >> разница будет в противоположную сторону, и куда больше. Книгу ты
> >> читаешь один раз (потом можешь обращаться как к справочнику, но тут уже
> >> объем мало влияет). Код пишешь (предположительно) многократно. Дальше
> >> думай сам.
> АН> Дело не столько в количестве часов, потраченном на книгу, сколько в
> АН> том, что оба языка позволяют сделать одно и тоже.
> Да. То же, что ассемблер, машина Тьюринга и Haskell. Они все
> Тьюринг-полны. Вопрос в том, сколько времени у тебя уйдет на одну и ту
> же задачу на этих инструментах.
Вы утрируете. :-) И, опять же, какой ассемблер? У него недостатком (в данном
контексте) является привязка к архитектуре, а отнюдь не бедность выразительных
средств (MASM и fasm вспомните) или отсутствие библиотек.
> Ну, сам я гуй не особо писал, особенно на C. Код к базам данных тоже,
> но видел, как он выглядит. На перле писал, и много. Куда больше, чем
> успел бы на C за всю свою жизнь. С сетевыми протоколами разница
> поменьше, раза в три, не больше, но там и библиотеки попроще. С сетью
> можно tcl с C сравнить, вот тут разница будет разительна.
Да, я понял почему мне Perl как-то не очень "по нутру". Мне он кажется очень
перегруженным, по ощущениям. Как и C++, но C++ - это, всё-таки C+объекты (ну ещё
шаблоны), a Perl - это и sh, и awk, и sed - куча всего...
> >> >> Пока я не стал большим любителем ОС Emacs, я пользовался tkabber в
> >> >> качестве jabber-клиента.
> >> АН> Этот тот, у которого суровый серый интерфейс? o.O
> >> Да. Но можно раскрасить в несколько строчек конфига. Мне было не надо,
> >> он мне для разговоров словами был нужен, а не для любования. А в
> >> разговоре чаще важно, чтобы ничего, в том числе попугайская раскраска,
> >> не отвлекало от темы.
> АН> И ещё он всегда выглядит в стиле tk, где бы не запускался: великое
> АН> единообразие. :-)
> Есть мнение, что это преимущество, а не недостаток. Тут, правда, многое
> зависит от того, с чем ты работаешь - с приложением или с системой. И
> если с системой, то что ты под нею понимаешь. Возможно, для tkabber это
> скорее недостаток, но если я сяду за винду и запущу в ней tkabber, мне
> удобнее будет видеть его таким же, как в линуксе, и чтобы вел себя так
> же.
Возможно. Но, думаю, если это не специфическое приложение, которое работает на
системе монопольно (большой АРМ, например), оно должно выглядеть так же, как и
все остальные приложения. Думаю, каша из Motif/Qt/Tk/GTK и "чего-то своего" вам
знакома?
> АН> Я хотел (и хочу) надёжного и быстрого ПО, которое может быть
> АН> написано сравнительно просто, быстро, без акцента на языке и
> АН> сильного напряжения. :-)
> Так чего ж ты тогда от перла отмахиваешься? У лиспов и tcl порог
> вхождения выше, хорошо бы иметь высшее образование в Computer Science
> (не обязательно, но хорошо бы). Для быстрого вхождения в Haskell хорошо
> бы иметь в Computer Science уже степень, причем защищенную не на
> реферате, а на самостоятельной работе - иначе вхождение в него занимает
> годы. А вот перлом до запрошенного тобой уровня можно овладеть довольно
> быстро.
А какое будет качество кода? :-\
> АН> 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 есть записи, а не отношения (если вы хотите сказать, что я не прав, то
отношения какого типа?). UID является ключом для выборки одного из независимых
кортежей. Т.о., это просто плоская таблица.
Вот passwd и group - уже представляют из себя БД.
Так что, passwd и БД - это совершенно разные вещи.
> АН> БД - это именно структура связей. Реестр - иерархическая БД, всякие
> АН> *sql - реляционные, но везде есть отношения.
>
> >> - реестр - единая БД для множества никак не связанных между собой
> >> программ, которая в результате оказывается труднообозримой и крайне
> >> слабо пригодной для чтения или изменения человеком (а какая же она
> >> после этого конфигурация, если чтобы в нее залезть, требуется
> >> отдельная программа со специфическим интерфейсом, а чтобы разобраться
> >> в том, что там содержится - отдел аналитики?)
> АН> Кстати, реестр - это отдельный сложный вопрос. Ведь он похож на
> АН> ФС. С некоторой точки зрения - иерархия в /etc тоже похожа на
> АН> реестр... Основная разница в том, что ключи реестра нечитаемы для
> АН> человека (в том смысле, что там используются UID, глубокая
> АН> вложенность и низкая ортогональность (к примеру, информация о
> АН> расширениях, как правило, записывается в двух местах, а для чего?)
> АН> и т.п.). И, вдобавок, реестр - лишняя сущность. Его функцию может
> АН> выполнять ФС. Скорее всего, они создали его ради оптимизации:
> АН> ускорения доступа к большому числу настроек системы. Но я не
> АН> интересовался. Если это так, то проблема не в реестре. А в
> АН> системе: "архитектура" реестра - прямое следствие из архитектуры
> АН> системы.
>
> Много чего похоже на ФС. dbm можно сделать похожей на ФС. На
> реляционной базе эмулятор ФС делается с легкостью.
Так есть и ФС, являющиеся БД. Тот же ZFS. Это уровень хранения данных, а не
уровень модели. Модель - дерево.
Я не про это. Просто не совсем корректно выразился.
Реестр буквально похож на ФС. На NTFS.
У него нет, наверное, ссылок (в чём я не уверен), а всё остальное есть.
С точки зрения пользователя - это ФС, которая содержит всё тоже самое (в т.ч.
установку прав доступа на ветви).
Отсюда напрашивается вывод: его стоило делать не на ФС только ради оптимизации.
> dbm можно сделать похожей на ФС.
whatis dbm? o.O
> Проблема с реестром
> как хранилищем конфигурации в том, что _человеку_ трудно с такой
> конфигурацией работать. А конфигурация - она, в общем, для человека
> отделена от кода и данных в отдельную сущность.
То, что с ним трудно работать и так ясно. Важно полно ответить на вопрос - почему?
> >> - mysql же отличается от этих двоих тем, что это не БД, а СУБД.
> АН> Как и Sqlite. :-)
> Ну, можно и так интерпретировать. В зависимости от того, на чем
> акцентировать внимание. Если на том, что sqlite предоставляет
> транзакционность - то да, а если на том, что СУБД - это отдельная
> сущность, с протоколами доступа, желательно отдельным DBA, который умеет
> ее настраивать и т.д., то нет. Я акцентировал на втором.
Почему СУБД должна быть обязательно неким сложным комплексом с кучей систем?
По-моему, это особенности реализации.
> АН> Ещё несколько типов таблиц, транзакции, возможность работы, как модуля,
> АН> поддержка репликации и возможность построения кластеров. Ну и т.д..
> АН> Но на том уровне абстракции - они не отличаются. :-)
> А главное, на этой задаче они все не нужны.
Да, согласен.
> >> Он, опять же, хорош на своих задачах,
> >> но если я вижу _персональный_ mysqld, я понимаю, что программами этого
> >> разработчика пользоваться не следует даже начинать, лучше сразу
> >> поискать, а то и написать альтернативу. А то себе дороже выйдет.
> АН> Почему? Ну, например, программа тащит его в дистрибьютиве или
> АН> требует для установки (snort-mysql, например). Это же не значит,
> АН> что она обязательно плохо написана..?
> Да потому что использование mysql там, где достаточно как максимум
> sqlite, а чаще - простого текстового файла, говорит о квалификации
> разработчика, и хорошего оно о ней говорит очень мало. И позволяет
> предположить, что если автоматика этой системы хоть чем-то тебя не
> устраивает, ты можешь застрелиться - это будет более легкая смерть, чем
> муки попыток сконфигурировать ее под себя.
Ага. Но есть и другой вариант - персональный "*bd*d", там где вполне подошёл бы
mysqld. Ещё хуже. :-(
> Ну, я уж молчу про то, что о понятии "ноутбук работает от аккумулятора"
> автор этой программы, вероятно, не слышал.
Хм... Mysql так сильно жрёт CPU?
> >> >> АН> Ну а какие варианты, когда требуется такая сложная система?
> >> >> АН> Изобретать свой велосипед, в итоге сводящийся с СУБД?
> >> >> Если такая сложная система конфигурации действительно требуется, то
> >> >> уровень сложности самой задачи там запредельный. Настолько
> >> >> запредельный, что я, со всем своим опытом, сто раз подумаю, прежде чем
> >> >> начать ее решать.
> >> АН> Обязательно? А если это расширяемая задача. А разработчики проектируют
> >> АН> "сверху-вниз", действуя на далёкую перспективу?
> >>
> >> _Так_ проектируемая система не доживет до этой далекой перспективы. А
> >> если доживет, то обнаружит, что на самом деле все совсем не так, как
> >> казалось много лет назад, на стадии проектирования.
> АН> Мда. Возможно. Тоже нужен баланс.
> Да не возможно, а точно. Предъяви мне хоть одну систему, которая так
> проектировалась и до этой перспективы дожила.
Ээээ... Multics? OS/360 (хотя, не уверен)?
> Некоторый баланс нужен, конечно, KISS в чистом виде приводит к
> растягиванию итераций со второй по примерно десятую раза в три каждой.
> Но баланс должен быть довольно сильно смещен в сторону KISS.
Да, только тоже надо понять где simple, а где - нет.
> >> СУБД, как правило, пытаются хранить свои настройки в себе же.
> >> Получается плохо :-)
> АН> Ну, в случае падения (но для этого есть другие решения). А так -
> АН> что плохого?
> Ну, для начала, пока что ни одной не удалось. Чтобы упасть, надо сперва
> взлететь. А если у нее вся конфигурация внутри базы данных, то откуда
> она узнает, где базу-то взять?
Так, в смысле, в БД хранится схема данных и права пользователей. Что в этом плохого?
> Короче, сходи на сайты MySQL и PostgreSQL и почитай, насколько там
> развесистые конфиги, хранящиеся вне БД. По крайней мере постгресовцы
> точно пытались по максимуму втянуть конфигурацию в БД. И всё, что
> осталось снаружи - это то, что втянуть не удалось.
Про Postgres не знаю. Про mysql - знаю. Помнится, ничего такого уж очень сильно
развесистого там нет.
> >> Нет, я понял мысль. Если у тебя вся логика в БД, то да, имеет смысл по
> >> крайней мере пытаться хранить там настройки приложения. И то -
> >> настройки клиента тебе таки придется, скорее всего, вынести еще куда-то,
> >> а то он не сумеет подключиться.
> АН> Минимум, необходимый для подключения и плюс немного "сахара"
> АН> (достаточно общего).
> Ну, опять-таки, хочешь узнать, каковы практические требования - сходи на
> те же два сайта и почитай про конфиги клиентских библиотек.
И с библиотекой их работал. Там не так много. Если, конечно, не требуется нечто
совсем уж нестандартное.
> >> Но практика показывает, что хранимые
> >> процедуры - это далеко не самое удобное место для хранения логики. У
> >> них обычно язык сильно ограничен, и реализация на них этой логики
> >> получается куда более геморройной, чем вне базы.
> АН> Но куда от них деться?
> АН> Они дают:
> АН> 1. Безопасность;
> АН> 2. Дополнительную надёжность;
> АН> 3. Часто - скорость;
> АН> 4. Унификацию интерфейса (что не на последнем месте, просто не всегда требуется).
>
> АН> И что, есть альтернатива (выделенный сервер приложений - не в счёт)?
>
> Именно выделенный сервер приложений.
Но это вариант для слишком масштабного проекта. А если масштаб не позволяет?
> И только если ты упираешья в
> скорость и хранимая процедура действительно позволяет ускорить работу (а
> не наоборот, что тоже бывает) - то хранимая процедура. Всё остальное
> выделенный сервер приложений (вернее, сервер приложения - на каждое
> приложение имеет смысл держать свой) обеспечивает лучше. Даже
> унификацию интерфейса к банальному выполнению SQL-запросов обеспечивает
> никак не сама СУБД, а библиотека DBD :-)
И ещё сервер приложений тоже должен на чём-то работать...
Кстати, да. Я согласен: вы подсказали отличный вариант (на перспективу, а не в
случае, когда вся логика уже записана в СУБД :-) ).
Сервер приложений должен представлять собой известный движок (чтобы обеспечить
независимость от платформы). Либо сервер приложений, как таковой, к примеру Java
серверы приложений, либо легковесный известный скриптовый движок, который
встроен в минимальную обвязку. Это позволит весь комплекс СУБД/СП/клиент
запустить на одной машине. А, при необходимости, развернуть на любой ОС.
Вариант?
> АН> Ещё хочется что-то делать, но очень хочется такого
> АН> избежать. Надоело. И вопрос - как?
> Вот если хочешь избежать - выдели логику в отдельное место. БД есть БД,
> и не стоит сливать на нее несвойственные ей задачи. А свойственны ей
> хранение и быстрая выдача данных, если смотреть независимо от
> архитектуры, а апдейт их от архитектуры уже зависит. Апдейт записей по
> одной, наприме, не свойствен реляционной БД, и реляционки к таким
> задачам прикручивают не от хорошей жизни, а от недостатка готовых к
> использованию в production альтернатив. Типа готовых реляционных СУБД
> много, а нереляционных мало, и положить это на реляционную модель
> неудобно, но можно.
> Чего у нас там не совсем сырого и нормально доступного из нереляционных,
> помимо BerkeleyDB? MongoDB только?
О нереляционных я знаю только по теории. На практике не сталкивался.
> А идея пихать в базу данных бизнес-логику на практике показала себя
> неудачной. Или отдельный сервер приложения, через который клиенты ходят
> в БД (более управляемая конструкция), или, если задача попроще, встроить
> в клиента.
Причём, сервер приложений не обязательно должен быть сетевым. :-)
В случае со скриптовым движком. Есть ядро (ну, например, взять MVC шаблон):
обвязка+движок - контроллер. V и C - подключаемый интерфейс ввода-вывода (ИВВ)
(думаю, здесь инверсия зависимостей к месту). ИВВ может быть любой.
Как варианты: сеть, вызовы функций, IPC.
Первый вариант позволит построить на ядре сетевой сервер для крупных приложений.
Второй вариант позволит построить тонкий клиент, включающий в код сервер
приложений и обращающийся к ядру напрямую.
Третий вариант позволит построить взаимодействие на локальной машине нескольких
клиентов (это мои фантазии, ы, эротические - терминальный сервер (не обязательно
для CLI клиентов o.O), например, хотя реально - это нафиг не нужно), не
используя между ними сеть.
И ещё куча вариантов. А логика сервера может быть программируемой на люом
понятном языке (даже больше - наверняка есть движки с бэкэндами и фронтэндами
под желаемый язык, как и движки с настраиваемым синтаксисом, о которых я просто
не знаю), к примеру PascalScript или JavaScript или диалект Pascal для 1С.
Причём, есть вариант JITC...
Хм... Реально ли? Не слишком сложно?
> При этом, прежде чем воспользоваться каким бы то ни было ORM, включая
> самописный - хорошо подумай, а нужен ли он тут вообще.
Я думал. Решил, что нужен.
> Большинство
> языков для прототипирования и мейнстримных к добавлению абстракций
> приспособлены не очень хорошо, но если на мейнстримных это еще окупается
> (я бы сказал, что не окупается сам мейнстримный язык), то на скриптовых
> чаще нет. Ну и ORM - это довольно слабая абстракция (собственно, потому
> ее добавление так просто и потому оно так редко окупается - добавить-то
> просто, да пользы мало).
Вопрос - какой ОРП. Всё зависит от уровня представления. Я добавил именно ради
абстракции. Грубо говоря, клиент - это клиент, а договор - это договор.
Следовательно, я могу оперировать в терминах предметной области (реально - так
красиво не получилось).
> Вот в частноти, если к задаче хорошо
> прикручивается ORM - значит, задача по-хорошему не под реляционку. То
> есть, может, ее и надо сделать на реляционке, потому что больше не на
> чем, но по крайней мере подумать об альтернативах стоит.
О каких?
> Если говорить о скриптах бэкапа, с которых мы начинали, то я бы
> рекомендовал не TDD, а своевременное _корректное_ прерывание обработки
> (возвращаясь к языкам - возьми perl или tcl, и не ленись кидать и ловить
> исключения, на этой задаче это подходящий инструмент) с подробной
> диагностикой (если perl - освой модуль Carp и функцию confess оттуда).
А мне TDD понравился.
Если я делаю ошибку (например, вплоть до того, что забыл поставить echo перед
сообщением), скрипт вываливается сразу. Если бы не было тестов, я бы потом долго
мучался, потому что функция не запускается при первом бэкапе.
> Особое внимание удели ситуациям, когда в случае ошибки имеет смысл
> продолжать работать с другими данными (неполный бэкап все же лучше
> отсутствующего), но донести до ответственного человека, что именно пошло
> не так.
Сейчас я делаю для себя. :-)
> И регламенту восстановления. Включающему учебные тревоги. Бэкап,
> который просто есть, никому не интересен. Интересен бэкап, с которого
> можно (в смысле, достаточное количество людей действительно может)
> восстановиться.
Я понимаю. К счастью, не у себя бэкапами занимаюсь не я. :-) Полюбопытствую,
кстати, как у них всё построено. Но там нет одной серверной: очень большая
распределённая сеть, несколько датацентров, куча машин нижнего уровня, много
подсистем...
Reply to: