четверг, 31 декабря 2009 г.

Не запускается служба PostgreSql. Что делать?

Это сообщение предназначено прежде всего для меня лично и для нашей службы поддержки, т.к. проблема подобная описанной ниже происходит с завидной периодичностью и нужно помнить основные шаги по ее решению.

Итак, история начинается с того, что мне 30 декабря в 11-30 звонят с сообщением о том, что у одного из наших клиентов не запускается наша система, поскольку не может подключиться к базе данных (в качестве СУБД у нас используется PostgreSql версии 8.1). Люди объясняют это тем, что час назад вырубило свет и компьютер вырубился некорректно, а после включения – все перестало работать:)

Хорошие пользователи нашей системы знают, где находится кнопка пуск и знают, что в системе не двое часиков “одни с цифрами, а другие песочные”. Поэтому единственное, что удалось сделать по телефону, так это попытаться руками запустить службу СУБД, результат – служба таки не запускается. Пришлось пробрасывать на тот компьютер интернет (на компьютерах, где установлена наша система интернета быть не должно) для возможности удаленного подключения.

После подключения к удаленному компьютеру я попытался запустить службу и получил следующее сообщение: “Служба PostgreSql Database Server 8.1” на “Локальный компьютер” была запущена и затем остановлена. Некоторые службы автоматически останавливаются, если им нечего делать, например, служба журналов и оповещений производительности”. Мда…

Проблема в том, что на тот момент это была единственная доступная информация… Логи PostgreSql пусты, записей в них никаких, в системных логах – тоже пустота.

Отладка служб – процесс не простой, поэтому многие разработчики предусматривают механизмы запуска приложения-службы, как обыкновенного консольного приложения с помощью ключей командной строки. И PostgreSql в этом плане – не исключение; для запуска нужно использовать следующую команду (Hint: эту команду можно запустить только из под неадминистративного пользователя системы, правда, если вы об этом забудете, то PostgreSql очень быстро вам об этом напомнит):

postgres -D "<postgresql data directory>"

Запускаем, и смотрим на сообщение об ошибке. В моем случае это сообщение звучало примерно так:

FATAL - bogus data in lock file "postmaster.pid"

Безусловно, мне повезло, проблема оказалась поправимой.  Почему-то указанный файл оказался пустым, и мне понадобилось скопировать его содержимое из рабочего экземпляра СУБД, что не составило особого труда.

Мораль этого сообщения в том, что если база легла, или произошли какие-то другие проблемы с системой, то прежде чем переустанавливать СУБД (или систему целиком) и терять при этом все данные, нужно хотя бы попытаться выяснить в чем проблема, возможно, есть все шансы, что вам удастся восстановить работоспособность не такими радикальными способами.

З.Ы. Всех с наступающим Новым Годом и пожелания того, чтобы ваши системы были стабильными и надежными и не портили ваш сон, но даже если какие-то проблемы и возникали, то у вас всегда были наготове варианты, как с этой ситуацией справиться.

понедельник, 21 декабря 2009 г.

Три факта о книге Роберта Гласса «Факты и заблуждения профессионального программирования»

Facts_and_Fallacies

Факт №1. Автор хотел назвать эту книги “The F-book”

Обсуждение

Роберт Гласс изначально хотел, чтобы эта книга получила название “Fifty-Five Frequently Forgotten Fundamental Facts (and a Few Fallacies) about Software Engineering” (Пятьдесят пять часто забываемых фундаментальных фактов (и несколько заблуждений) из области разработки программного обеспечения), или коротко “The F-book”, однако издатели посчитали первое название слишком длинным, а во втором названии букву F – слишком грязной (F-word обозначает не только слово, начинающееся с буквы F, но и вообще слово, не рекомендуемое к употреблению в приличном обществе (спасибо редакторам за разъяснения)), поэтому сошлись на более коротком и презентабельном названии.

Полемика

Каждый автор мечтает о том, чтобы его книга выделялась среди множества книг других авторов. Некоторые наиболее популярные и известные книги получают неформальные названия (например, GoF-book или Dragon-book), которые дают им преданные читатели, и вполне понятно желание Роберта Гласса, чтобы его книга получила подобное особое название. Однако одного желания автора недостаточно, чтобы это произошло и несмотря на намеки автора о неформальном названии этой книги, она так и не получила свое неформальное имя (хотя кто знает, возможно еще не все потеряно).

Факт №2. Практически каждый профессиональный разработчик найдет что-то полезное в этой книге

Обсуждение

Роберт Гласс на страницах этой книги поднимает весьма широкий спектр вопросов и проблем, с которыми сталкиваются профессиональные разработчики во время своей повседневной деятельности. В книге можно выделить несколько ключевых тем: сложность программных продуктов и процессов; неправильные оценки и давление сроков сдачи; проблемы устранения ошибок; инспекция кода; особенности сопровождения программных продуктов и многое другое.

Полемика

По словам самого же автора, в этой книге он стремится ответить на вопрос «Что?», а не «Как?». «Здесь для меня важно вытащить эти факты обратно на поверхность, где их можно свободно обсуждать и достичь прогресса в практическом следовании им». Он поднимает широкий спектр вопросов, которые целиком покрывают жизненный цикл процесса разработки и пытается обратить ваше внимание на ту или иную проблему. Автор не дает ответы на поднимаемые вопросы, и считает, что самое главное – это осознание того факта, что эта проблема вообще существует.

Польза от этой книги напрямую зависит от опыта читателя. Для одних будут наиболее интересными вопросы об управлении проектами, человеческом факторе и сложностях оценок; для вторых – вопросы проектирования, архитектуры и особенности перехода от проектированию к кодированию; для третьих – вопросы сложности ПО и ответ на вопрос, почему увеличение сложности задачи на 25% приводит к увеличению сложности решения на 100%; для четвертых – особенности тестирования, инспекции кода и ответ на вопрос, почему стопроцентное покрытие кода тестами ничего в итоге не дает; для пятых – сложности, связанные с сопровождением продукта и вопросом, какой процент затрат идет на исправление ошибок и на разработку новых функций; для шестых– ответ на вопрос, почему же качество современных программных продуктов такое низкое.

Большая часть этих фактов и заблуждений в том или ином виде обсуждается в других источниках, но нужно признать, что автор во многом прав и далеко не все в нашей области знают, помнят и осознают эти проблемы. С фактами из этой книги можно соглашаться или не соглашаться, но главное, «чтобы ваш творческий дух получил по ходу дела дополнительный стимул, а в голове уже зрели мысли о том, как нам лучше выполнить работу по созданию и сопровождению ПО».

Факт №3. Книга Роберта Гласса весьма интересна, но до шедевра явно не дотягивает

Обсуждение

Книга Роберта Гласса будет полезной многим разработчикам, но я не могу поставить ее в один ряд с книгами Демарко и Листера, Брукса и Йордона, Ханта и Томаса. Книга интересна и полезна, но не гениальна.

Полемика

Этот факт является весьма спорным и многие читатели этой книги могут со мной не согласиться. Гениальность произведения сложно описать словами и еще сложнее обосновать, почему одна книга относится к гениальной, а другая – нет. Нужно признать, что эта книга весьма популярна у читательской аудитории, но нужно признать и то, что ее не цитируют в каждой второй книге по разработке ПО. Книга производит впечатление добротной, хорошо проработанной, она достойно раскрывает практически все темы, которых касается, но все же ей чего-то не хватает. Роберт Гласс придерживается своего стиля, местами ироничного, местами серьезного. Но читая факты нет ощущения эйфории, как от чтения Демарко или Брукса. Разница владения языком становится особенно заметной в главах о менеджменте, в которых Роберт как раз опирается на «Человеческий фактор» и «Мифический человеко-месяц». Написано хорошо, интересно, но цитат, которые бы подошли на роль плакатов в комнату программистов, увы, практически нет. Если взять вопрос о сложности ПО, то ему в книге уделено 15 (!) фактов, но при этом полнота и качество изложения существенно уступает Бруксу и Бучу. Опять же, хорошо, добротно, но не гениально.

Завершая полемику этого факта, стоит признать, что количество книг, которые компьютерное сообщество признает гениальными – единицы. Как и в любой другой области, в области компьютерной литературы, гениев слишком мало и движение вперед основано на добротных профессионалах, к которым и относится книга Роберта Гласса с его фактами и заблуждениями профессионального программирования.

вторник, 8 декабря 2009 г.

О цитате “Преждевременная оптимизация – корень всех зол”

Многие специалисты компьютерной области знают (ну, или хотя бы слышали) следующее высказывание:

Преждевременная оптимизация - корень всех зол в программировании

Большая часть этих самых компьютерных специалистов склоняется к мысли, что автором этой цитаты является Дональд Кнут и хотя для многих программистов не важно, кто на самом деле является автором, у меня этот вопрос вызывал интерес и я решил заняться им более подробно.

Существует как минимум три разновидности этой фразы, которая встречается в различных трудах Дональда Кнута.

Первый вариант:
Преждевременная оптимизация - корень всех зол в программировании
Оригинал:
Premature optimization is the root of all evil
Источник:
1974 год, лекция, посвященная вручению премии Тьюринга, Computer Programming as an Art, Communications of the ACM, Volume 17, Issue 12, Dec. 1974 (see p.671)).
Полная версия оригинала:
The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

Второй вариант:
Нам следует забывать о небольшой эффективности, например, в 97% случаев: преждевременная оптимизация - корень всех зол. Хотя мы не должны отказываться от своих возможностей в этих критических 3%
Оригинал:
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3.
Источник:
1974 год, статья Structured Programming with go to Statements, ACM Computing Surveys, Vol 6, No. 4, Dec. 1974 (see p.268)  (эта статья является критикой статьи Эдсгера Дейкстры Go To Sta­te­ment Con­si­de­red Harm­ful).

Третий вариант:
Я также знал, но забыл афоризм Хоара о том, что преждевременная оптимизация — корень всех зол в программировании
Оригинал:
But I also knew, and forgot, Hoare’s dictum that premature optimization is the root of all evil in programming.
Источник:
1989 год, статья The Errors of Tex, Software—Practice & Experience, Volume 19, Issue 7 (July 1989), pp. 607–685, а также в книге Literate Programming (p. 276)

Все три варианта появились в трудах Дональда Кнута, но судя по третьей цитате складывается впечатление, что изначальным автором фразы был другой знаменитый ученый в области компьютерной науки Тони Хоар (C.A.R. Hoare), также лауреат премии Тьюринга, автор быстрой сортировки, Логики Хоара и много чего другого.

С момента выхода в свет The Errors of Tex, прошло уже два десятка лет, но до сих пор нигде не удается найти информацию, подтверждающую слова Кнута о том, что автором этой фразы является именно Хоар. Более того, сам Хоар в 2004 году в личной переписке с Hans Genwits написал о том, что он НЕ является автором этой цитаты (оригинал здесь):

Dear Hans,
I’m sorry I have no reco­llec­tion how this quo­ta­tion came about.? I might have attri­bu­ted it to Eds­ger Dijkstra.
I think it would be fair for you assume it is com­mon cul­ture or folklore.
Tony.

На самом деле не так и важно, кто является автором этого высказывания, Дональд Кнут, Эдсгер Дейкстра, Тони Хоар, или кто-то не столь именитый в области компьютерных наук. Важно то, что эта фраза стала известной именно благодаря Дональду Кнуту.

Ну и последнее, помните, Дональд Кнут говорил о 97%, а не о 100%;)

пятница, 4 декабря 2009 г.

Новый блог. Цитатник компьютерной литературы

“Для меня уже давно стало привычкой читать специализированную литературу с набором из двух десятков закладок и карандашом за ухом, в противном случае столь приятное времяпрепровождение мне кажется пустой тратой времени. При чтении книг нужно обязательно критически оценивать поступающую информацию, делать какие-то пометки на полях, подчеркивать интересные или спорные мысли, выписывать цитаты, обсуждать интересные моменты”.

Ссылка на первое сообщение, в котором более подробно описываются причины, побудившие к созданию этого блога, а также намерения о том, какие цитаты будут в нем публиковаться.

Собственно сам блог: ru-quotes.blogspot.com

Буду рад любым комментариям, как по форме (оформлению блога), так и по содержимому.