татко Крокодил

Това е лекцията ми от varnaconf – “Какво ми се иска да знаеха програмистите (а явно не го знаят)”.
(имаше няколко различни заглавия в тоя смисъл, не успях да подбера най-грубото)

Може би най-важното е да знаят, че имам лопата и си я държа под ръка…

Иначе, малко по-сериозно, да почна от там защо изобщо реших да водя лекцията. Пряко свързана е с работата ми и реално представлява мрънкане/оплакване от някаква част от проблемите, с които съм се срещал и не съм очаквал, че ще се срещна.
Моята работа по принцип е да карам неща, писани от други хора да работят. Това включва много debug-ване (което ми е едно от любимите занимания), много четене на код и малко писане. Държа да си кажа, аз не мога да пиша кой-знае колко добре, липсва ми времето и желанието за толкова съсредоточаване (ttee ми отне няколко дни, а не би трябвало).
Четенето на код е основно да разбера защо нещо не работи (или понякога как изобщо работи), съответно с мисъл за бъдещето обяснявам на хората къде е проблема, как може да се оправи, как аз съм го оправил, така че в бъдеще да не видя същото нещо. За съжаление ако историята ни учи на нещо, то е, че хората не се учат от историята, та моите опити са доста неуспешни. Приемете това като едно просто изливане на мъката.

Спрях се на два типа проблеми – теоретични и от неинформираност, понеже бях ограничен в 30 минути, но ще се опитам да засегна нещата в по-голяма дълбочина тук.

Ще започна с първия теоретичен проблем – copy-paste.
Copy-paste е метод за разпространение на грешката. Не мога да преброя колко пъти съм видял код, копиран няколко пъти и във всичките места със същата грешка. Човек би си помисли, че това е понеже няма как да се избегне (наистина има такива случаи), но най-често изглежда или като мързел от страна на програмиста, като липса на абстрактно мислене или като непознаване на езика и средствата на разработка. Голяма част от повторения код изглежда като писан от хора, които не са наясно че има неща като for цикли, функции, макроси и т.н..
Доколкото знам, започват да се появяват инструменти, които поне могат да откриват такива неща, но не съм забелязал сериозната им употреба. Тези неща много лесно се хващат с четене на кода (deja vu, “това някъде съм го виждал) и е едно от нещата, които code review може лесно да хване.

Умното писане ми е друг проблем. Много често се случва след-начинаещ програмист да открие нова възможност на езика, нов lib, нов метод на писане и да започне да го прилага навсякъде, където види, просто защото му се вижда много готин. Така се прилага безсмислено сложно средство за решаване на прости проблеми, което прави debug-ването много трудно, защото както е казал Браян Кърниган, “дебъгването е два пъти по-сложно от програмирането, така че ако програмирате с пълния си капацитет, не сте достатъчно умен да да го дебъгвате после”.
Някои езици много улесняват подобни неща, например Perl и C++. Мнението на Al Viro за C++ и защо не се ползва за kernel-а много добре показва проблема – накратко, езикът има твърде много възможности, всеки програмист свиква с някакво под-множество от тях, и когато в един проект се съберат да пишат няколко човека, се получава страшна смесица от стилове.
(на лекцията бях казал грешно, че идва от Линус, но мисля, че говорех за това, доста отдавна съм го чел)
По принцип често ме викат, когато трябва да се debug-не нещо такова супер сложно и омазано и най-честото нещо, което казвам е, че трябва да се пренапише.
(За пример за умен код давам примерните реализации на fizzbuzz, ако някой някога ми напише нещо като последната в production код, ще трябва да има преди нея поне толкова голям коментар, който обяснява защо е написано така и как точно работи)

Проблемът с валидацията може би ще иска отделна публикация, лекция, учебник, курс или религия по темата. Факт е, че след толкова години security и всякакви подобни проблеми никой не проверява получените данни.
(след малко дискусии с Кънев и още няколко човека искам да обясня, че например трансформирането на данните до вид, който е валиден също е вид валидация, т.е. правилното escape-ване например)
Докато водих лекции на едни ученици около летния лагер на БАН преди година-две във Варна, присъствах на тяхно предаване на проект, който представляваше симулация на банкомат – в общи линии му се подаваше сума и програмата по някакъв начин казваше в какви банкноти и по колко ще я върне. Имаше всякакви красиви реализации и т.н., но повечето изгърмяваха по неприятен начин (или зацикляха, или програмата умираше) на всичко, което не беше съвсем валидно – отрицателни числа, дроби, такива, за които нямаха типове банкноти – само защото нямаха няколко прости проверки в началото и вярваха, че входът ще е верен.
(това с вярването сигурно работи в религиите, но не и в програмирането)
Елементарното нещо – да се направи проверка още на входа на данните, се пропуска от всички. Много често ако има валидация, е от типа “shotgun” (т.е. все едно сте лепнали кода на стената и от далече сте стреляли по него с пушка със сачми, и където е паднала сачма там сте сложили проверка за нещо) и повече пречи, отколкото помага.
Друга такава елементарна грешка е идеята “аз пиша клиента и сървъра за нещо, значи данните ще са ми верни и няма защо да ги проверявам”, което е така до момента, в който някой друг се добере до този интерфейс и започне да праща там. Резултатите от това варират между викове “кой го е писал това” и вопли “как са ни хакнали и са ни потрили всичко?”…
Вариация на предното е “само аз пиша в базата, знам какво е и няма нужда да го проверявам” – имаше няколко случая на cross-site scripting през такива проблеми.
И нещо, за което малко хора се сещат изобщо, а на малкото останали хора, които държат на performance (като например game developer-ите) им е противопоказно е defensive programming-а – да се прави допълнителна проверка на още няколко места, понеже в крайна сметка всички допускаме грешки, нормално явление е да ги допускаме и е добре да ги хващаме. Пряко следствие от това е, че assert-ите не се пускат само в debug код, а и в production.

Като допълнение към валидацията, което не можах да разпъна добре на лекцията е, че няма замисляне колко сложни да се правят протоколите, така че да са лесни за валидация. Писах за лекциите от 28c3 и по-точно за Packet-in-packet атаката и за the science of insecurity, така че няма да повтарям (много), но е важно да правим всичко така, че да ни е нужен максимално прост апарат за обработката и валидацията му – колкото повече от нещата ни могат да се разберат и обработят с краен автомат например, толкова по-добре. В противен случай можем да се озовем в ситуацията на антивирусния софтуер, който спрямо математическата теория не може да бъде направен да работи напълно правилно.
(Проблемът там е като следствие от теоремата на Гьодел, която казва, че вътре в една система не можем да проверим дали всяко твърдение в нея е вярно или невярно, т.е. няма как със средствата на машина на Тюринг да валидираме друга машина на Тюринг)

И за пример за невъзможна за валидиране и използва сериозно система ще дам комбинацията от HTML5 и CSS3 (без JavaScript), която се оказва, че е Turing-complete.

След чистата теория нека да хванем няколко по-преки проблема.

“I don’t believe in miracles, I rely on them” изглежда да е стандартна програмистка философия. Трудно се схваща, че почти всичко може да върне грешка и съответно трябва да се направи нещо, ако това се случи. Като за начало, имам две парчета код за пример. Първото е “наивната версия”:

#define BUFSZ 8192
int fd0, fd1;
size_t len;
char buff[BUFSZ];

fd0 = open(file1, O_RDONLY);
fd1 = open(file2, O_RDWR);

while ( (len = read(fd0, buff, BUFSZ) !=0 ) ) {
	write(fd1, buff, len);
}

close(fd0);
close(fd1);

Второто е ремонтираната (DIE трябва да печата име на файл, име на функция, ред, подадения string и strerror(errno)):

#define BUFSZ 8192
#define DIE()...

int fd0, fd1;
size_t len;
char buff[BUFSZ];

if ( ( fd0 = open(file1, O_RDONLY) ) <0 ) DIE("open fd0");
if ( ( fd1 = open(file1, O_RDONLY) ) <0 ) DIE("open fd1");

while ( (len = read(fd0, buff, BUFSZ) > 0 ) ) {
	if ( write(fd1, buff, len) < len) DIE("writing");
}
if (len<0) DIE("reading");
close(fd0);
close(fd1);

(Оставил съм втората версия както ми е в презентацията, с грешките от един copy-paste. И аз съм идиот, това го видях на самата лекция, когато ми го посочиха)

Разликата е ясна, и примери от първия тип може да се срещат къде ли не. Най-често съм виждал такива неща при php програмистите, което може би идва от това, че понеже всяка маймуна може да пише на php, твърде много маймуни са започнали да го правят.

Втората версия не прави някаква магия и да решава проблема – тя просто ни дава едно важно свойство, наречено “failfast”, т.е. програмата да прекрати изпълнението си колкото се може по-скоро след като стане ясно, че не може да го завърши правилно. С код с подобно поведение и няколко други прекрасни неща, като идемпотентност на изпълнението (много дразнеща дума, значи в общо линии че ако кодът се изпълни 1 или N пъти, резултатът в крайното състояние ще е все същия, т.е. можем да повтаряме колкото си искаме) и ACID свойства можем да правим истински работещи системи, а не такива, които се чупят, като някой ги погледне накриво.

Fallacies of distributed computing са друго нещо, което много ми се искаше да е известно на повечето програмисти. Много често хората пропускат колко гнусно нещо като поведение е мрежата. Ще се спра накратко на няколко от проблемите:

Мрежата не е с нулева латентност – усеща се когато например се изисква два компонента да работят синхронно и да си разменят постоянно съобщения, за да си синхронизират състоянието. Тогава дори бързата локална мрежа ще вкара сериозни забавяния, а в момента, в който минем на нещо на по-дълги разстояния, повечето такива неща просто спират да работят.
Това е и едно от нещата, които не можем да очакваме по-добрия хардуер и физиката да поправят, понеже поне до момента няма нещо, което да можем да използваме за предаване на данни и да е по-бързо от скоростта на светлината.

Пропускателната способност не е безкрайна – понякога хората не се усещат, че предаването на указател към огромни данни през мрежата не става точно така.

Мрежата не е reliable – нормално е за мрежата да губи пакети, да изчезва, да има jitter, а ако е internet е нормално това да е още по-зле. Съответно не може да се пише какъвто и да е софтуер, който я използва без да се имат в предвид тези failure modes и да се взимат мерки за тях.

Мрежата не е сигурна – може да се подслушва, някой да се представя за някой друг и т.н. и т.н. и т.н., неща, които ги чуваме даже по новините и все пак никой не се сеща да ползва криптография.

Накратко, мрежата ви мрази.

Накратко два доста конкретни проблема от ползването на version control-а – още не се преподава сериозно, хората започват да го учат в движение в първата си работа и това води до всякакви проблеми, например до ползване на CVS или до това ако двама човека работят заедно, да седят един до друг и да си разменят файлове по skype.

Първият проблем от неяснотата как се използват VCS (version control systems) е че когато кажеш на някой “branch-ни това, за да работим спокойно по trunk-а” изобщо не те разбират, а като обясниш “направи копие еди-къде-си”, хората просто взимат файловете и ги add-ват наново там, което води до загуба на history-то. След като им се посочи грешката, те продължават да не схващат защо това е такъв проблем, понеже за тях VCS-а е само backup и commit messages са някакъв бълвоч, който никой не гледа, а когато потрябва да се гледат, вече е късно.
(Много е забавно да се анализират всички commit messages на някоя фирма и да се види кои са най-често срещаните думи. Моята любима (беше на 10то място в една фирма) е “blahovina”)

Вторият проблем е как като се прави някакъв сайт, редовно се слага config файла в repository-то. Понеже този файл е различен за production-а, staging-а и за машините на developer-ите, редовно се случва някой да го commit-не от грешната машина и да го update-не в production-а, чупейки всичко. Двете решения, за които аз знам са или да се прави template на този файл и само той да стои в repo-то, а другото е да се detect-ва средата и да се load-ват подходящите настройки (както прави rails, доколкото схванах).

И един bonus за четящите тук – нещо, което не можах да спомена в лекцията, но обсъждахме доста подробно след това, външните dependencies на един проект, кой носи отговорност за тях и как се update-ват. Ще говоря основно за неща, които се deploy-ват по сървъри, но има доста паралели и с end-user-ския софтуер.

По принцип имаме два варианта. Единият е да използваме външните неща от дистрибуцията/операционната система, оставяйки на тях отговорността (и подбирайки ги правилно, например да ползваме debian stable или centos или rhel), другия е ние да си ги вкараме в проекта и да си носим отговорността за тях.

Много проекти се спират на втория вариант, след което обаче забравят какво са вкарали, или пък дават зависимости през външна пакетна система (например ruby gem-ове) и пак забравят да ги update-ват. Или не забравят да ги update-ват, но не смеят, понеже ще се счупи нещо. Или ще update-нат цялото нещо към най-новата версия заради някакъв супер готин нов feature и ще потрошат цялата система.

За това хората, които не разбират как се прави това, не трябва да го правят – ако човек не участва в оперативната работа (я като админ, я като част от devops екип), по-добре да остави на другите да му кажат версии и външни пакети, за да може да се работи стабилно и без downtime. Като малка реклама на debian stable (и донякъде ubuntu server lts), те правят дистрибуция много подходяща за сървъри, понеже въпреки, че са със стари пакети, те реално за живота на дистрибуцията винаги backport-ват важните patch-ове (основно за security проблеми), така че системата е едновременно и сигурна и не се променя поведението ѝ.

Специално за външните dependencies също мога да направя цяла отделна лекция, в която да си излея мъката.

За всички, преживели изчитането на това – снимка на обстановката, в която спах във Варна :)

(най-много ме зарадваха силно невярващите погледи на някои хора от залата, т.е. има надежда, че има програмисти, които знаят тия неща)

Мина лекцията във вторник, има запис и може да си свалите пълния архив с презентацията и парчетата псевдокод.

Отделно ето я и самата презентация.

Става въпрос за тип задача, която не намерих в design patterns, и за която има различни парчета софтуер, които правят нещо подобно (rabbitmq, gearman). Основната причина да се пише от нулата, вместо да се ползва нещо готово е, че се интегрира много по-добре в съществуващата система и така е доста по-просто, отколкото да се добавя още някакво парче код.
(и е интересна задача :) ).
Имам в практиката си три реализации, като това, което показвам прилича най-вече на една от тях, система за encode-ване в няколко формата на видео. Имаме много сървъри, които се занимават с encode-ването (cli.*) и които си взимат задачи от централен диспечер (srv.*), който има някакъв вариант да пази persistent state (в моя случай – база данни). Задачите са индемпотентни, т.е. могат да бъдат изпълнени повече от един път, ако се наложи.

Езикът, който съм ползвал в примерите е в общи линии псевдокод, който прилича на смесица от perl и php. Странните неща в него са, че има мнoжествено връщане (т.е. конструкция от типа $a, $b = f()) и че respond в srv.* връща отговор на клиента и излиза, т.е. прилича малко на return. man pages описват семантиката на fork и wait.

Начален вариант на решението би бил с този диспечер и този клиент.

Първият проблем, който се вижда е, че ако сървърът не успее да свърши задачата, няма как да го съобщи на диспечера. Това лесно се коригира с добавяне още на един тип заявка към диспечера:
Версия 1: диспечер и diff от предишната версия, клиент и diff от предишната версия.

Вторият проблем е какво става, ако заявим, че искаме задача, диспечера ни я задели, но не получим отговора? Ако нямаме обработка на този случай, в такива ситуации ще се натрупват задачи, които се водят, че се обработват и реално никой не ги е взел. Решението, до което аз стигнах е да добавя на всеки сървър transaction id и при заделяне на задача диспечерът да отбелязва сървъра и transaction id. Ако клиентската част подаде заявка за нова задача и не получи отговор, трябва специално да подаде обратно заявка за “cancel”, за да сме сигурни, че неполучената задача е върната в pool-а на свободните задачи.
Версия 2: диспечер и diff от предишната версия, клиент и diff от предишната версия.

Третият проблем е рестартирането на някой от сървърите, които обработват задачи – например поради спрял ток. Когато той се стартира отново, според диспечера ще има няколко задачи, които той обработва и за които той не знае. Решението е просто – добавя се тип заявка, която се подава при рестарт и почиства работещите задачи за даден сървър.
Версия 3: диспечер и diff от предишната версия, клиент и diff от предишната версия.

Четвъртият проблем (който би трябвало да е един от първите) е колко често и кога да се опитваме да повторим заявка към сървъра. Всяка заявка, която може да подадем може да стигне, но може и да не стигне до сървъра, или ако стигне, нямаме гаранция, че ще получим отговор. Съответно трябва да добавим към srv_request() в клиентската част логика колко пъти и как да опитва – само веднъж, много пъти или безкрайно. Заявяването на задача трябва да се изпълнява точно един път, останалите неща – докато се получи отговор.
(от “много пъти” смисъл в повечето случаи няма и би трябвало да го махна от кода)
Друг проблем, който се вижда доста бързо е, че ни трябва нещо от типа на exponential backoff, за да разредим честотата на опити от страна на сървърите към диспечера. Това се прави, за да се избегне ситуация от която след restart изведнъж се изсипват твърде много заявки в/у диспечера и има шанс да го претоварят. Същото нещо може да се види и в доста мрежови протоколи, например TCP.
Версия 4: клиент и diff от предишната версия.

Петият проблем е да ограничим колко товарим себе си (и донякъде сървъра), като ограничим броя задачи, които изпълняваме. Прави се сравнително просто, с брояч на вървящите в момента child процеси.
Версия 5: клиент и diff от предишната версия.

Шестата версия е основно дописване и доподреждане на кода, с оправяне на няколко проблема, които само ми хрумнаха и не съм виждал на живо. Едното нещо е валидация на state на определена задача, другото е един race condition м/у fetch и cancel (който по принцип не трябва да може да се случи).
Версия 6: диспечер и diff от предишната версия.

Има функционалност, която по различни причини не е дописана в този код:

– да връщаме на всеки сървър колко да изчака, преди пак да пита за задача, като метод за flow control.
– job timeout/job restart – да решаваме по някакъв начин кога да рестартираме определена задача (понеже е възможно сървърът и да е умрял и да не се е върнал повече). Това не пасва добре в текущия код, т.е. трябва да се напише отделен компонент, който се вика периодично или работи като демон при диспечера, който да изпълнява тази функционалност, а самата логика за това зависи твърде много от контекста.
– Log на всички събития – животоспасяващ при всякакво дебъгване.
– Monitoring и аларми при различни състояния, дефинирани като проблемни (твърде много чакащи задачи, твърде много обработвани и т.н.) – пак трябва да е в отделен от тези два компонента.

Ще водя още една лекция в initLab във вторник (17.06) от 19:30. Пак ще се stream-ва на http://tyler.ludost.net:8787/lab.ts и пак през irc ще могат да се задават въпроси.

Мина лекцията в initlab за книгите. Имаше десет книги в първоначалния план, но накрая говорих и за още две.

Първоначалният списък:
(link-овете са към goodreads, от там може да се ориентирате лесно)

За писането: Мемоари на занаята на Стивън Кинг, заедно с Правопис и пунктуация на българския език (издателство на БАН).

Хората трябва да могат да пишат и да ползват собственият си език.

Shooting an Elephant на Джордж Оруел.

Събрани есета. Показват колко добре умее да пише Оруел, съдържат класическото му (и цитирано от всички) есе за как се пише, както и много неща за истинския журнализъм, езика и истината. Няколко цитата:
“Political language is designed to make lies sound truthful and murder respectable, and to give an appearance of solidity to pure wind. ”
“The greatest enemy of clear language is insincerity.”
“Journalism is printing what someone else does not want printed: everything else is public relations.”

Дзен и изкуството да се поддържа мотоциклет на Робърт М. Пърсиг.

Философска книга. В нея всеки намира ралзични интересни неща – някой спомена как цялата книга според един негов приятел била за музика, според мен е за технологии, сигурно има и други мнения. Една от главите беше поредния тласък да спра да преподавам във ФМИ и да мисля друг вариант.

The Invisible Gorilla and Other Ways Our Intuition Deceives Us на Christopher Chabris и Daniel Simons

Книгата, която ме накара най-накрая да направя подобна лекция. Описва колко много грешим и се лъжем сами. Понеже ме мързи, подробности има в ревюто ми (или може някой път да напиша цял post).

The Psychopath Test на Jon Ronson

От нея се запалих да чета неща по тема психиатрия.

Liars and Outliers на Bruce Schneier

“Приложение на теория на игрите за обществото”

Промиване на мозъци – психологията на тоталитаризма на Робърт Лифтън

Вече съм писал за нея

Masters of Doom на David Kushner

Историята на хората, направили id Software. Който не знае кой е John Carmack определено трябва да я прочете.

Kingpin: How One Hacker Took Over the Billion-Dollar Cybercrime Undergroundна Kevin Poulsen

Историята на Iceman (една от големите фигури в credit card fraud средите).

Better: A Surgeon’s Notes on Performance на Atul Gawande

Хирург, който обяснява как приложението на прости статистически и технически методи може да подобри ефективността на работата. Много от нещата са приложими в нашата област (и много не са).

Две книги, които не бяха в списъка:

Sex at dawn: The Prehistoric Origins of Modern Sexuality на Christopher Ryan, Cacilda Jethá

Основно еволюционна биология. Да цитирам Voland, “не е задължително да сте съгласни, но трябва да я прочетете”.

Blindsight на Peter Watts

Заради тази книга прочетох “The invisible gorilla” и още няколко книги. Едно от най-най-добрите неща в твърдата фантастика в последните години, вече и съм писал за нея. Книгата е под creative commons лиценз и всеки лесно може да намери откъде да я свали за каквото устройство иска.

Самата лекция мина средно добре. Дрънках два часа, като можеше вероятно да се събера в един, но се получи доста интересна дискусия. Също така се получи хората да гледат отдалечено streaming-а и да задават въпроси през irc. Записът се encode-ва и ще пусна link като е готов.

Има още много книги, за които бих говорил (някои от тях споменах). Може и да се направи дискусия върху връзките между тях, например цялостна дискусия за social engineering-а и защитата от него в светлината на “The Invisible Gorilla”, “Ghost in the Wires” (автобиографията на Кевин Митник), “Liars and Outliers”, “Kingpin” и още каквото се сетим…

Какво мислите за лекция за книги по следната тематика:
“компютърно-историческа” (като “Kingpin” и “Masters of Doom”)
“твърда фантастика” (“Blindsight”)
“Neal Stephenson”
или просто пак такава мешаница от теми?

Update: на streaming-а е имало в пиковия момент 15 човека. Изглежда има достатъчно интерес да се прави пак :)

Update 2: Запис.

Update 3: Списък с всички книги, за които бих говорил по темата, по идея на Ники Бачийски.

От 14:30 в събота (7 юли) в initLab ще направя лекция по темата “10 не-техническо-компютърджийски книги, интересни за компютърджии” (още работя по заглавието).
(часът е избран така че всички да са станали, които го правят – обядвали и да е преди концертите)

Спрямо четенето има различни групи хора.

Има такива, които не могат да четат – поради болест, неграмотност и т.н. – за тях аз нямам какво да направя. Има хора, които обаче могат и или си търсят какво, или не знаят за дадени книги и че биха им били интересни. Целта на тази лекция е да се покажат в няколко области интересни книги, които биха се харесали на хора с компютърджийски и подобни интереси.
(още работя по списъка книги)

Лекцията ще се излъчва на http://tyler.ludost.net:8787/lab.ts , ще има запис на va.ludost.net. Вероятно ще блогна казаното на лекцията след това.
Ако някой иска да задава въпроси, но няма да присъства на място – в irc на marla.ludost.net ще има канал #initlab и се надявам да намеря кой да стои там и да ми предава въпросите.

В петък, 8ми юни от 19:00 в initLab ще има лекция на Larry Maloney, представител на HackerDojo по темата за hackerspace-овете, тяхното развитие и те какво са научили, докато са правили HackerDojo.

Лекцията ще е на английски, има някакъв шанс да я запишем и качим.

Update: Може да се гледа на http://tyler.ludost.net:8787/lab.ts
Update 2: Има и запис на лекцията. Би трябвало да има и още един, от един фотоапарат, ще кача и него като го обработя.

Напомниха ми, че не съм бил писал от 10 дни. Дължи се на мързел и мога да се оправдавам, че си давах почивка на читателите от простотиите, дето бях писал последно.

Накратко – работа. Завърших пренасянето на нещо, дето търкаляше на 6-7 машини на една в друг datacenter (която още не е умряла и като гледам, спокойно ще издържи до идването на новия хардуер), махнах си от схемите и monitoring-а едно количество стари неща и в общи линии поне за момента нещата изглеждат сравнително подредени (т.е. време е да почне пак мазането). Ще вземе да се окаже, че имам останало време да се хвана с едни основни почиствания, дето стоят на заден план от много време…
(ето тук е момента, в който в главите на колегите изниква думата “renumbering” и почват да се притесняват)

След първото написано нещо по лекцията за openfest ми се мотаят само идеи, но нищо, дето да става за записване. Добре поне, че имам месец и нещо дотогава :) Мисля да правя дискусия по темата за образованието и по-точно за предаването на знания специално в областта на IT-то, това, което съм написал досега е доста грубо и на моменти директно озлобено, ще се преписва.

Изчетох “Dust of Dreams” на Ериксън, книгата е наистина страхотна (както и останалото), чакаме последната (догодина по някое време, предполагам). Един от моментите беше как в последните няколко глави изведнъж се случиха събитията от края на предишната книга и читателя заедно с всички герои се чувства като цапнат с мокър парцал :)

И като нещо, което отдавна не бях правил – изгледах няколкото сезона на “Sayonara Zetsubou-Sensei”, едно много странно и на моменти зло аниме (започва с весело момиче, което отива на училище през пролетта и вижда как някой се беси, който някой после и се оказва учител). Аз поне се хилих като идиот на първите 5 минути, преди да свикна с идеите им (първи епизод си струва да се гледа ако ще само за идеята да се разбере какво било “trying to make oneself taller”).

(днешния празник не го празнувам)

Като за начало – Нийл Стивънсън ще издава нова книга, Anathem, вече съм я pre-order-нал (очаква се да излезе на 9 септември).

Днес БТК за пореден път се сринаха за около два часа – проблем с единия им upstream. Грам идея си нямам защо им трябваха два часа да завъртят един route или просто да свалят един-два интерфейса (не вярвам да нямат свободен капацитет). Да не говорим за невероятните реакции на техния helpdesk, който в писменото описание на проблема ни каза, че па хептен нямало проблем (щото те пуснали един traceroute и нищо не видели). Тия хора не са наред…
(няма да коментирам “пратете ни screenshot”. Уж говорим с VIP helpdesk-а)

Написал съм си основните бележки за лекцията в четвъртък, сега остана да сглобя една презентация и няколко схеми (не успях днес да порисувам в офиса, чудя се дали Visio работи под wine – ако да, ще си купя едно).

А, и се върнах обратно към pidgin 2.2 – в 2.4 са строшили ICQ-то (и ПАК са омазали интерфейса. Идиоти.).

… и малко други неща извън големия постинг за НСБОП.

Взех си най-накрая последната книга на Солженицин на български за евреите в Русия, купът за изчитане порастна още повече. Минах през Orange, където в момента работи Светла, поръчах си една книжка и освен това я помолих да провери за няколко други книги (цикъла “Червеното колело” на Солженицин – не са издавани на български, но поне първите три са преведени на английски).
(в началото съм на “The bonehutners” на Ериксън (шестата от Малазанска книга на мъртвите), а трябва и да изчета по-внимателно “Old times” на Харолд Пинтър (това, по което е правено “Завръщане”), пристигна тия дни).

Около работата се появи много интересна тема за лекция, тия дни ще започна по-подробното разписване. За момента се очертава да я говоря на Astricon (ако ме вземат натам, иначе ще я говори шефа), и може би на Openfest. Най-големия проблем е как да я събера в 1 час, а не в 4…

(а с какъв кеф изядох днес половин кило ягоди …)

Няколко неща…

Четох днешния “дебат” с Явор Колев и разни други хора на тема последните събития около ГДБОП (бивши НСБОП). Не отговориха на няколко въпроса, например защо против ДА не са предприети никакви мерки и много добре заобиколиха въпроса за доказателствената сила на нещата, които са насъбрали. Специално Веселин Колев много добре им го каза, а има и още няколко човека оттам, с които би ми било доста интересно да се запозная. Самия текст го има на сайта на IDG някъде.
(беше ужасно забавно да се види как журналистката-организаторка не можа да каже почти нищо :) ).

Аз си оправих проблема, който имах с net-а (старата мрежова платка не понасяше лавината от broadcast трафик и се шашкаше от време на време) и сега си слушам Тангра… Беше бая забавно да слушам как в предаването “Некрономикон” водещия чете части от разкази на Лъвкрафт, мислех си, че времената на тези неща са отминали, но слава богу, не са :). Сега ми остава да си купя и едно wireless AP и да мога да си работя спокойно от леглото…
(въпрос м/у другото – търся си надуваеми столове и подобни неща, някой да знае къде има? В Billa и Практикер няма)

В четвъртък успях да изнеса една лекция за различни цялостни системи, която не се получи особено добре, умората ми идва твърде много. За сметка на това около един въпрос на тема послушването на мрежата успя да се заформи доста интересен разговор…

Деня не беше особено лек… Успях да стана някъде около 12, да се поосвестя до 13, и да ида да взема камерата от Мариян, след което да сдъвча една баничка за закуска и да се добера до офиса на Жоро да доубием презентацията за лекцията. Той беше дописал останалите слайдове, та остана само да направим преглед и малко корекции (в които отдалечено помогна и Сиси (жената на Жоро), ей-това е жена-герой (завършила и българска филология) :) ).

Самата лекция успяхме да я изкараме – имахме в последния момент проблеми с достатъчно дългите разклонители, ама ги оправихме. Жоро говори около час и 40 минути за всякакви хубави неща (имаме пълен запис, тая нощ ще го оставя да се encode-ва), а публиката му задава доста въпроси.

Последва празнуване на рождения ден на Владо Каравелов (голям да му порасне (оборота)! :) ) във Fans… Пихме, забавлявахме се, свириха Ер голем (с един невероятен китарист, направо ми събра очите). Беше бая весело, аз изпих прилично количество уиски (не пия бира тия дни заради гърлото) и реших, че прибирането пеша е лоша идея след това :)
(аз му пожелах и следващия му повод да черпи да е като тоя на Жоро, ама май не му хареса идеята… :) )

А утре Котя има имен ден… Как ще преживея и това празнуване – изобщо не съм наясно. Да взема да се разболея и да пипна блога да и показва само на нея, че съм болен ли … :)

п.с. Червото каза, че отказва алкохола (за около три месеца). Нека му помогнем, че иначе нов черен дроб (че и толкова издръжлив) няма отде да намерим :)