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 перед сообщением), скрипт вываливается сразу. Если бы не было тестов, я бы потом долго мучался, потому что функция не запускается при первом бэкапе. > Особое внимание удели ситуациям, когда в случае ошибки имеет смысл > продолжать работать с другими данными (неполный бэкап все же лучше > отсутствующего), но донести до ответственного человека, что именно пошло > не так. Сейчас я делаю для себя. :-) > И регламенту восстановления. Включающему учебные тревоги. Бэкап, > который просто есть, никому не интересен. Интересен бэкап, с которого > можно (в смысле, достаточное количество людей действительно может) > восстановиться. Я понимаю. К счастью, не у себя бэкапами занимаюсь не я. :-) Полюбопытствую, кстати, как у них всё построено. Но там нет одной серверной: очень большая распределённая сеть, несколько датацентров, куча машин нижнего уровня, много подсистем... -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
