Взялся читать "Законы Паркинсона". Обалдеть!
Не могу удержаться от цитирования:
Нынешней администрации, и деловой, и правительственной, постоянно
приходится отбирать людей. Неумолимый закон Паркинсона гарантирует
непрестанную нужду в кадрах, но выбрать того, кого надо, не так легко.
Расскажем о методах отбора, применявшихся в былое время, и о методах
нынешних.
Раньше (а отчасти и теперь) применялись метод британский и метод
китайский. Оба они заслуживают внимания хотя бы потому, что принесли
гораздо больше пользы, чем вреда. Британский метод (старого типа) основан
на личной беседе, в которой соискатель должен объяснить, кто он такой.
Немолодые джентльмены, сидящие вокруг краснодеревого стола, спрашивают его
имя и фамилию. Предположим, он отвечает: "Джон Сеймур". Один из членов
комиссии интересуется: "А вы не родственник ли герцогу Сомерсетскому?" На
это соискатель, скорее всего, ответит: "Нет". Другой джентльмен скажет:
"Тогда, быть может, епископу Вестминстерскому?" Если и здесь ответом будет
"нет", третий джентльмен возопит: "Так _чей_ же вы родственник?" В том
случае, когда соискатель отвечает: "Ну, отец мой торгует рыбой в
Чипсайде..." - беседу можно считать исчерпанной. Комиссия переглядывается,
один из членов звонит, а другой говорит лакею: "Вывести". Одно имя
вычеркивается без обсуждений. Если следующим предстанет Генри Молине,
племянник графа Сефтонского, шансы его будут велики вплоть до появления
Джорджа Говарда, который сумеет доказать, что он - внук герцога
Норфолкского. Комиссия не встретит трудностей, пока ей не придется
выбирать между третьим сыном баронета и вторым, хотя и побочным, сыном
виконта. Но и тут можно справиться в специальной книге, так что выбор
прост, а нередко и удачен.
Адмиралтейская разновидность метода (напомним: старого типа) отличается
лишь тем, что выбор ограниченней. На адмиралов не действуют титулы как
таковые. Им важно, связан ли соискатель с моряками. Идеальный ответ на
второй вопрос: "Да, адмирал Паркер - мой дядя, капитан Фоли - отец,
коммодор Фоли - дед. Мать моя - дочь адмирала Харди. Капитан Харди
приходится мне дядей. Мой старший брат - лейтенант королевского флота,
другой мой брат учится в морском училище, а третий ходит в матроске". -
"Так, так, - говорит главный адмирал. - А почему вам вздумалось идти во
флот?" Ответ на этот вопрос практически безразличен, поскольку секретарь
уже отметил имя в списке. Если приходится выбирать из двух таких
соискателей, какой-нибудь адмирал попросит назвать номера такси, на
которых они приехали. Тот, кто честно ответит: "Не знаю", будет отвергнут,
а тот, кто быстро соврет "23-51", будет принят, как юноша с хваткой. Метод
нередко давал блестящие результаты.
Британский метод нового типа выработался в девятнадцатом веке, как
более уместный для демократической страны. Комиссия живо интересуется:
"Где учились?" И, услышав ответ: "Хэрроу", "Хейлибери" или "Регби", задает
второй вопрос: "Во что играете?" Хороший соискатель ответит на это: "Я
играю в теннис за Англию, в крикет за Йоркшир, в регби за клуб "Арлекин" и
в гандбол за "Винчестер". Тогда задают третий вопрос: "А в поло не
играли?" - чтобы он не возомнил о себе, хотя и без поло такой соискатель
заслуживает внимания. Если же на первый вопрос ответом будет "Уиглворт",
беседа не затянется. "Что?!" - удивится председатель. "А где это?" -
вскричат остальные, когда вопрошаемый повторит название. "В Ланкашире", -
объяснит он, и кто-нибудь для порядка все же спросит насчет игр, но ответ
"Настольный теннис за Уигэн, велосипедные гонки за Блекпул и биллиард за
Уиглворт" окончательно преградит ему путь. Возможны нечленораздельные
замечания о наглецах, расходующих чужое время. И этот метод давал неплохие
результаты.
2007-03-31
законы Паркинсона
2007-03-08
ms sql server 2000 + blob
Хочу поделиться результатами личного опыта борьбы с BLOB данными в базе данных под MS SQL Server 2000 sp4.
Неважно по какой причине, стал я проводить тесты на предмет - как удобнее и надежнее загрузить в БД бинарные файлы и потом выгружать их оттуда.
С выгрузкой проблем вроде не обнаружилось, а вот с загрузкой...
Берем в одну руку ADO от мелкихпрограммеров, в другую БД с полем типа image, в третью любой скриптовый язык, для манипуляций обьектами ADO. И пользуясь методом ADO AppendChunk для нашего поля, пытаемся загрузить в БД файлы разного размера.
В моем случае облом произошел на уровне 150 - 160 мегабайт. Памяти, говорит, не хватает. Это при том, что то море памяти, которое выделено СУБД даже не все использовано. Полез в гугель. Нашел. Ответ такой - для загрузки через сеть (сетевые протоколы) требуется непрерывный участок оперативки под загружаемый обьект. Теперь все понятно. Поскольку фрагментацией оперативки управлять невозможно, заранее неизвестно, при каком размере файла случится облом. А что самое интересно, нет возможности грузить частями. Все. Финиш. ADO использвать нельзя.
Совершенно спокойно файлы любого размера (я грузил 300 с лихуем мегабайт) грузятся путем написания хранимой процедуры, использующей набор конструкций:
select @ptr=textptr([blob]) from tabblob where id=@id
updatetext tabblob.[blob] @ptr NULL 0 @binaryout
Дополнение - выгружать файлы из БД на диск с помошью хранимой процедуры нельзя, методов обратных нет (ха, Мелкомягким это не внове), самый простой способ - как раз через ADO. Вот такая петрушка: загружать - хранимой процедурой, выгружать - через внешний инструмент. И никак иначе. В сад...
Надо будет посмотреть, как ADO с ORACLE дружит при блобных операциях.
4GB оперативки
Есть у меня комп, вот такой:
мазерборд Asus A8N-SLI, проц. Athlon 64 x2 4200+
и 4 планки памяти по 1 гигабайту. Остальное здесь значения не имеет.
Раньше было две планки по гигабайту, и хлопот никаких. А теперь вот озаботился тем, что потихоньку из продажи вымываются планки памяти DDR-просто. Решил, пока не поздно закупить еще две, чтоб в сумме 4 гига получилось. Я в курсе, что это проблемное количество памяти, уже был опыт сборки компа с 4 гигами. Но с тех пор прошло 2 года...
Короче, ставлю память, запускаю... короче опустим середину, сразу к выводам.
В бивисе есть опции, две штуки, одна SW 4GB remapping, другая HW 4GB remapping. Разница понятна - первая четвертый гигабайт памяти переносит в как бы пятый неким софтовым путем, вторая хардверным, при условии поддержки процом. Хардверный ремаппинг быстрее, процентов на 10. Если эти опции применять, получаем первые 3гига, потом до четырех дырка и после четырех еще гиг до пяти. Если опции не включать, этот четвертый гиг уходит куда то в "PCI devices" и в системе не виден.
ОК. Включаем опцию ремаппинга и пытаемся увидеть 4 гига под виндой хп 2 сервис пак. Фигвам. Несмотря на все опции PAE винда вырубает все, что выше 4 гигов. По словам билли, "потому как народ драйверы писать не умеет и они глючат в режиме PAE". Становится непонятно, зачем вообще нужен режим PAE. Тем более, что на его работу тратятся дополнительно еще ресурсы оперативки и процессора. Правда режим DEP требует включенного режима PAE, но это другая история.
В итоге мы имеем: хреновый бивис, который не может нормально выдать нам четвертый гиг памяти, плюс хреновую винду, которая декларирует режим PAE, но реально не дает пользоваться памятью выше 4 гигов. Что в лоб, что по лбу. Короче, хотите 4 гига и выше - покупайте нормальные мазерборды и ставьте 64 битные системы, ну или винсервер 2003 энтерпрайз.
В итоге я выбрал такую комбинацию опций: в бивисе хардверный ремаппинг (чтоб при установке нормальной операционки не вспоминать, что там надо подшаманить) и в винде опции /NOPAE /3GB
что дает программам доступ к 3 гигам виртуальной оперативки. А четвертый гиг типа про запас.
Для любителей самим разбираться в деталях даю ссылки:
2007-03-01
Ценить настоящее
Сегодня мыслил мысль: почему мы так слабо ценим настоящее и так мало заботимся о будущем?
И намыслил банальную идею - потому, что не умеем расставаться с прошлым.
Цепляемся за прошедшее, жалеем о том что уже было, злимся на свершившееся, короче, живем в прошедшем времени. Просто некогда насладиться текущим моментом!
А ведь когда у человека есть единственное сокровище, как он его ценит, а?
Как бы мы ценили наш текущий момент, если бы в полной мере осознавали, что кроме него у нас ничего нет!