Записки программиста, обо всем и ни о чем. Но, наверное, больше профессионального.

2007-03-31

законы Паркинсона

Взялся читать "Законы Паркинсона". Обалдеть!
Не могу удержаться от цитирования:

Нынешней администрации, и деловой, и правительственной, постоянно
приходится отбирать людей. Неумолимый закон Паркинсона гарантирует
непрестанную нужду в кадрах, но выбрать того, кого надо, не так легко.
Расскажем о методах отбора, применявшихся в былое время, и о методах
нынешних.
Раньше (а отчасти и теперь) применялись метод британский и метод
китайский. Оба они заслуживают внимания хотя бы потому, что принесли
гораздо больше пользы, чем вреда. Британский метод (старого типа) основан
на личной беседе, в которой соискатель должен объяснить, кто он такой.
Немолодые джентльмены, сидящие вокруг краснодеревого стола, спрашивают его
имя и фамилию. Предположим, он отвечает: "Джон Сеймур". Один из членов
комиссии интересуется: "А вы не родственник ли герцогу Сомерсетскому?" На
это соискатель, скорее всего, ответит: "Нет". Другой джентльмен скажет:
"Тогда, быть может, епископу Вестминстерскому?" Если и здесь ответом будет
"нет", третий джентльмен возопит: "Так _чей_ же вы родственник?" В том
случае, когда соискатель отвечает: "Ну, отец мой торгует рыбой в
Чипсайде..." - беседу можно считать исчерпанной. Комиссия переглядывается,
один из членов звонит, а другой говорит лакею: "Вывести". Одно имя
вычеркивается без обсуждений. Если следующим предстанет Генри Молине,
племянник графа Сефтонского, шансы его будут велики вплоть до появления
Джорджа Говарда, который сумеет доказать, что он - внук герцога
Норфолкского. Комиссия не встретит трудностей, пока ей не придется
выбирать между третьим сыном баронета и вторым, хотя и побочным, сыном
виконта. Но и тут можно справиться в специальной книге, так что выбор
прост, а нередко и удачен.
Адмиралтейская разновидность метода (напомним: старого типа) отличается
лишь тем, что выбор ограниченней. На адмиралов не действуют титулы как
таковые. Им важно, связан ли соискатель с моряками. Идеальный ответ на
второй вопрос: "Да, адмирал Паркер - мой дядя, капитан Фоли - отец,
коммодор Фоли - дед. Мать моя - дочь адмирала Харди. Капитан Харди
приходится мне дядей. Мой старший брат - лейтенант королевского флота,
другой мой брат учится в морском училище, а третий ходит в матроске". -
"Так, так, - говорит главный адмирал. - А почему вам вздумалось идти во
флот?" Ответ на этот вопрос практически безразличен, поскольку секретарь
уже отметил имя в списке. Если приходится выбирать из двух таких
соискателей, какой-нибудь адмирал попросит назвать номера такси, на
которых они приехали. Тот, кто честно ответит: "Не знаю", будет отвергнут,
а тот, кто быстро соврет "23-51", будет принят, как юноша с хваткой. Метод
нередко давал блестящие результаты.
Британский метод нового типа выработался в девятнадцатом веке, как
более уместный для демократической страны. Комиссия живо интересуется:
"Где учились?" И, услышав ответ: "Хэрроу", "Хейлибери" или "Регби", задает
второй вопрос: "Во что играете?" Хороший соискатель ответит на это: "Я
играю в теннис за Англию, в крикет за Йоркшир, в регби за клуб "Арлекин" и
в гандбол за "Винчестер". Тогда задают третий вопрос: "А в поло не
играли?" - чтобы он не возомнил о себе, хотя и без поло такой соискатель
заслуживает внимания. Если же на первый вопрос ответом будет "Уиглворт",
беседа не затянется. "Что?!" - удивится председатель. "А где это?" -
вскричат остальные, когда вопрошаемый повторит название. "В Ланкашире", -
объяснит он, и кто-нибудь для порядка все же спросит насчет игр, но ответ
"Настольный теннис за Уигэн, велосипедные гонки за Блекпул и биллиард за
Уиглворт" окончательно преградит ему путь. Возможны нечленораздельные
замечания о наглецах, расходующих чужое время. И этот метод давал неплохие
результаты.

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 гигам виртуальной оперативки. А четвертый гиг типа про запас.

Для любителей самим разбираться в деталях даю ссылки:

да, количество памяти в винде удобно смотреть в окне проги msinfo32

2007-03-01

Ценить настоящее

Сегодня мыслил мысль: почему мы так слабо ценим настоящее и так мало заботимся о будущем?
И намыслил банальную идею - потому, что не умеем расставаться с прошлым.
Цепляемся за прошедшее, жалеем о том что уже было, злимся на свершившееся, короче, живем в прошедшем времени. Просто некогда насладиться текущим моментом!
А ведь когда у человека есть единственное сокровище, как он его ценит, а?
Как бы мы ценили наш текущий момент, если бы в полной мере осознавали, что кроме него у нас ничего нет!

Архив блога

Ярлыки

linux (241) python (191) citation (186) web-develop (170) gov.ru (159) video (124) бытовуха (115) sysadm (100) GIS (97) Zope(Plone) (88) бурчалки (84) Book (83) programming (82) грабли (77) Fun (76) development (73) windsurfing (72) Microsoft (64) hiload (62) internet provider (57) opensource (57) security (57) опыт (55) movie (52) Wisdom (51) ML (47) driving (45) hardware (45) language (45) money (42) JS (41) curse (40) bigdata (39) DBMS (38) ArcGIS (34) history (31) PDA (30) howto (30) holyday (29) Google (27) Oracle (27) tourism (27) virtbox (27) health (26) vacation (24) AI (23) Autodesk (23) SQL (23) Java (22) humor (22) knowledge (22) translate (20) CSS (19) cheatsheet (19) hack (19) Apache (16) Manager (15) web-browser (15) Никонов (15) functional programming (14) happiness (14) music (14) todo (14) PHP (13) course (13) scala (13) weapon (13) HTTP. Apache (12) Klaipeda (12) SSH (12) frameworks (12) hero (12) im (12) settings (12) HTML (11) SciTE (11) USA (11) crypto (11) game (11) map (11) HTTPD (9) ODF (9) купи/продай (9) Photo (8) benchmark (8) documentation (8) 3D (7) CS (7) DNS (7) NoSQL (7) cloud (7) django (7) gun (7) matroska (7) telephony (7) Microsoft Office (6) VCS (6) bluetooth (6) pidgin (6) proxy (6) Donald Knuth (5) ETL (5) NVIDIA (5) Palanga (5) REST (5) bash (5) flash (5) keyboard (5) price (5) samba (5) CGI (4) LISP (4) RoR (4) cache (4) car (4) display (4) holywar (4) nginx (4) pistol (4) spark (4) xml (4) Лебедев (4) IDE (3) IE8 (3) J2EE (3) NTFS (3) RDP (3) holiday (3) mount (3) Гоблин (3) кухня (3) урюк (3) AMQP (2) ERP (2) IE7 (2) NAS (2) Naudoc (2) PDF (2) address (2) air (2) british (2) coffee (2) fitness (2) font (2) ftp (2) fuckup (2) messaging (2) notify (2) sharepoint (2) ssl/tls (2) stardict (2) tests (2) tunnel (2) udev (2) APT (1) CRUD (1) Canyonlands (1) Cyprus (1) DVDShrink (1) Jabber (1) K9Copy (1) Matlab (1) Portugal (1) VBA (1) WD My Book (1) autoit (1) bike (1) cannabis (1) chat (1) concurrent (1) dbf (1) ext4 (1) idioten (1) join (1) krusader (1) license (1) life (1) migration (1) mindmap (1) navitel (1) pneumatic weapon (1) quiz (1) regexp (1) robot (1) science (1) serialization (1) spatial (1) tie (1) vim (1) Науру (1) крысы (1) налоги (1) пианино (1)