воскресенье, 29 марта 2015 г.

Об изменениях

Прочитал такую вот заметку: "Всех пугают перемены". У меня есть что возразить из собственного опыта, что называется - из наболевшего, и обычно в таких случаях пишут комментарии. Но в блоге отсутствует возможность комментирования, в чём я хозяина блога, внезапно, поддерживаю! Комментарии в блогах - это такая вещь, на который слетается всякий неадекват, так что обычно комментарии не стоят потерянного на них времени.

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

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

При этом, топ-менеджмент и бизнесмены никогда не упускают возможность лягнуть нашу власть, которая, издавая новые неожиданные законы, ведёт себя с бизнесменами абсолютно также. Бизнесмен ориентируется на текущую обстановку, делает прогноз развития рынка, готовит бизнес-план, набирает под этот бизнес-план кредитов, а тут вдруг неожиданно правила игры меняются - подписывается указ или принимается закон, который оставляет бизнесмена с кучей долгов, ненужного оборудования и сотрудников. Точно такое же вот "кидалово" практикуется и топ-менеджментом, который из лучших побуждений пытается что-то улучшить в компании, совершенно не пытаясь ознакомиться с планами своих подчинённых. В результате несколько лет планомерной работы могут оказаться перечёркнутыми авторитарным решением руководителя.

Уважаемые руководители, старайтесь общаться со своими подчинёнными. Причём не только с прямыми подчинёнными, но и с их подчинёнными. А когда общаетесь - не иронизируйте над их опасениями, не отмахивайтесь со снобизмом "у меня больше опыта", а внимательно прислушивайтесь и обсуждайте ваши нововведения. Опыт - это такая штука, которую невозможно измерить цифрами. У одного человека его может быть больше в одной области, а у другого - в другой. Можно отмахиваться от чужого опыта, но тогда не удивляйтесь результатам, потому что вы изначально пошли на самообман.

воскресенье, 15 марта 2015 г.

Администрирование PostgreSQL 9. Книга рецептов

Прочитал книгу "Администрирование PostgreSQL 9. Книга рецептов" за авторством Саймона Ригса и Ханну Кросинга, вышедшую в издательстве ДМК Пресс.



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

Если сравнивать с MySQL, то никакого встроенного уплотнения таблиц в нём мне не известно. В случае если вся база данных хранится в одном файле, для возврата незанятого места из этого файла в файловую систему приходилось делать полную резервную копию с последующим удалением файлов и полным восстановлением из резервной копии. В случае хранения таблиц в отдельных файлах в MySQL вернуть место файловой системе можно только полным пересозданием таблицы, сопряжённым с её полной блокировкой. В PostgreSQL возврат незанятого места из файлов таблиц - фоновый процесс.

Если сравнивать резервное копирование с MySQL, то в PostgreSQL поддерживает горячее бинарное резервное копирование путём простого копирования файлов из файловой системы без каких-либо дополнительных инструментов типа xtrabackup или мгновенных снимков LVM. Резервную копию можно снять при помощи простого rsync, предварительно заморозив изменения файлов при помощи хранимой процедуры и разморозив их другой хранимой процедурой после копирования. После этого можно скопировать журналы изменений. При запуске PostgreSQL с такими резервными копиями, изменения из журналов будут перенесены в основное хранилище.

Механизм потоковой репликации в PostgreSQL мне показался более эффективным, чем имеющийся в MySQL. Потому что резервный сервер не выполняет те же запросы для обновления данных, которые выполняет основной сервер, а применяет уже готовые двоичные изменения к файлам хранилища, добавляя или удаляя из него блоки данных.

Кроме того, в PostgreSQL, если верить этой книге, реализована более эффективная поддержка транзакций и их изоляции друг от друга. Одновременно могут работать несколько запросов на обновление одной и той же таблицы, если они затрагивают разные записи одной таблицы. Внутри транзакции выполняются команды на изменение структуры таблиц или изменение индексов. Конечно, в таком случае другие запросы, работающие с изменяемой таблицей, приостанавливаются, поскольку в таком случае изменяются все записи в таблице. Но сам факт того, что структуру нескольких таблиц можно менять согласованно, должен весьма греть душу :)

воскресенье, 8 марта 2015 г.

CGI программирование на Perl

Прочитал недавно книжку, посвящённую разработке веб-приложений на Perl: Скотт Гулич, Шишир Гундаварам, Гюнтер Бирзнекс “CGI-программирование на Perl, 2-е издание”.



Perl в наше время не столь популярен, как PHP, Python или Ruby, поэтому новых книг по нему практически не издаётся. В основном выпускаются переиздания уже давно зарекомендовавших себя книг, которые хорошо продаются. В общем, я собрал все доступные книги по Perl, одной из которых оказалась эта книга. Кстати, эта книга - тоже дополнительный тираж книги 2001 года, выпущенный в 2013 году.

Что можно сказать о книге? Ожидать многого от книги, посвящённой веб-разработке и вышедшей в 2001 году, не приходится. Понятно, что многое из описанного в книге устарело. Книга была написана в эпоху, когда веб-приложения на Perl писались с использованием модуля CGI или с использованием Apache и mod_perl. Книга акцентирует внимание на программировании с использованием модуля CGI, довольно поверхностно и вскользь описывает преимущества FastCGI и mod_perl. В ней нет ни слова о PSGI, Plack, Catalyst, Mojolicious, Dancer и Dancer2, которые являются современными технологиями веб-разработки на Perl.

В то же время нельзя сказать и что книга совершенно бесполезна. Значительное количество текста посвящено вопросам безопасности в веб-программировании. Подробно рассматриваются возможные механизмы поддержки сеансов (сейчас общепринято использовать для этого механизм Cookie, который поддерживается всеми современными браузерами), описываются методы увеличения удобства веб-приложений за счёт использования Javascript. Особенно полезными мне показались разделы, посвящённые модулю GD для генерации картинок и использованию XML. Наконец-то хоть кто-то смог простым языком объяснить сильные стороны XML. В общем-то, после прочтения главы об XML я понял, что не имеет особого смысла использовать XML без DTD, то есть описания структуры документа, при помощи которой можно в значительной мере защититься от возможных проблем.

В отличие от большинства современных книг, посвящённых веб-разработке, эта книга практически не касается SQL. Гораздо больше внимания в ней уделяется вопросам блокировки файлов с данными для поддержания их целостности. Хранить данные в файлах может показаться старомодным чудачеством, однако, на мой взгляд, довольно часто СУБД и SQL могут оказаться избыточными, не говоря о вездесущем использовании ORM по делу и без дела! Но если в книге не упоминаются альтернативы SQL, то у новичков формируется ложный стереотип о том, что любое веб-приложение должно использовать базу данных. А у людей, начинающих веб-программирование сразу с освоения Django или Rails и вовсе может сформироваться чувство, что не бывает веб-приложений, не использующих ORM.

воскресенье, 1 марта 2015 г.

Пара прочитанных книг

Дочитал пару книг, которые начал читать ещё в прошлом году - уж слишком тяжело они шли.

Генрих Альтшуллер. Найти идею. Введение в ТРИЗ - теорию решения изобретательских задач



Часто встречал восторженные отзывы на ТРИЗ - теории решения изобретательских задач и АРИЗ - алгоритме решения изобретательских задач. Интерес подогревали различные примеры сложных инженерных и бытовых задач, решённые с помощью ТРИЗ. В общем, учитывая репутацию ТРИЗ, я просто не мог обойти вниманием эту книгу, тем более она хорошо вписывается в интересующую меня тему о науке управления и проблемах человечества.

Что можно сказать о книге по прочтении? В названии ТРИЗ стоит сделать акцент на последних буквах - эта книга концентрируется не на решении задач вообще, а на решении сугубо изобретательских задач. Конечно, какой-то толк будет если попытаться применить ТРИЗ и к жизненным задачам, но скорее всего решение будет продиктовано не логикой развития систем, а вашей собственной логикой. Кроме того, даже для того, чтобы использовать ТРИЗ для решения изобретательских задач, нужно иметь хороший изобретательский кругозор - быть знакомым с большим количеством различных физических явлений и приёмов, применённых в конкретных изобретениях. ТРИЗ хороша для того, чтобы упорядочить то, что уже есть в голове, но ничего нового ТРИЗ сама по себе в голову не вложит.

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

Антуан де Сент-Экзюпери. Южный почтовый. Ночной полет. Планета людей. Военный летчик. Маленький принц. Цитадель



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

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

Вторую половину книги составляет произведение под названием "Цитадель". Вот эта половина и была самой тяжёлой, потому что представляет собой бесконечный поток размышлений некоего восточного правителя. В "Цитадели" нет сюжета, так что её свободно можно читать хоть с середины, хоть с конца. Ценность этих размышлений для меня осталась весьма сомнительной. При чтении сознание постоянно норовило уснуть и переключиться на посторонние мысли. Было не так много моментов, которые захватывали моё воображение красочностью историй: история о колодце Эль Ксур, про город в пустыне, окружённый стенами без ворот, про хромого мальчика, про жадного министра, про разлучённых друзей-садовников. Если бы "Цитадель" была бы как-то структурирована и представляла собой сборник притч в стиле "Тысячи и одной ночи", мне бы она понравилась гораздо больше. К сожалению, этому не дано сбыться, т.к. произведение фактически является компиляцией черновиков автора, сделанной редакторами. Сам Экзюпери закончить "Цитадель" не успел.