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

Ето текста на презентацията ми от Openfest 2012 за това как 700 сървъра се поддържат по-лесно от 3. Оставил съм бележка на кой слайд съм, понеже има няколко полезни картинки из презентацията (pdf, odp).

Update: видео запис.

[слайд 2]
Занимавам се със сървъри в общи линии от малък и винаги ми е било интересно. След като в последните 3 години се занимавах с една голяма система (около 750 машини, 7.5PB място, 260gbps трафик в разни моменти) открих как големите системи са по-лесни за поддръжка, понеже ни карат да правим нещата по правилния начин (иначе просто няма да се справим).
Също така искам да отбележа, че аз съм адски мързелив и не много умен (за последното даже имам издаден документ от МЕНСА) и намирам това за лесно, т.е. според мен всеки, който реши може да се справи:)

[слайд 3]
Това е снимка от едно от първите неща, с които съм се занимавал (за съжаление нямам снимка на първия си сървър, как стоеше до един шкаф с 6-7 модема и това си беше цялата система). Да сравним с

[слайд 4]
тези две снимки, на които отляво можем да видим извънгаранционни гръмнали дискове (около 400бр.), и в дясно пак извънгаранционни гръмнали сървъри (няма как да се направи снимка на работещите машини, която да е достатъчно интересна).

[слайд 5]

Малко бележки, преди да започна – аз различавам три типа “операции”.

Първият тип е малката фирма. Там има един-два-три сървъра, системният администратор поддържа всичко, от климатиците до базите данни и web сървърите, не му дават много време да спи, няма особено голям бюджет и като цяло всичко се прави по неприятен и неефективен начин.

Вторият вид са големите, “enterprise” операции – като пример мога да дам телекомите (които за мен са много повече неприятен начин на мислене, отколкото нещо друго) – това са компании, които разработват и изобщо разбират частично технологията си и основно плащат на външни фирми много пари, които после да могат да поемат вината за проблемите, и да реагират в някакво време (например 2-4 часа) за да оправят счупеното.

Третият вид са тези, за които ще говоря, и които по принцип наричам “порно компании”, поради това, че повечето от по-големите фирми, които се занимават да сервират и т.н. порно по интернет са такива (но и twitter, reddit, github също си приличат с тях). Това са операции, които сами поддържат почти цялата си инфраструктура и продукти, които използват почти ексклузивно open-source софтуер, дописват го за собствени цели и успяват с бюджет, който е с един-два пъти по-малък порядък от enterprise хората да постигнат толкова или повече.

(има четвърти тип, който пропуснах на лекцията, гигантите като facebook и google, от които идват някои от идеите по-долу).

И понеже има шанс да се появи въпросът “тия неща какво значение имат, като всичко ни е в облака”, малък отговор: облакът ни дава нещо, което е много подобно на моите железа, просто няма нужда да си поддържате сами хардуера. Поддръжката на хардуера поне при мен за 700 машини отнема средно по около час-два на седмица. Останалото си важи с пълна сила.

[слайд 6]

Големите системи ни принуждават да научим някои неща, без които никога няма да можем да се справим с натоварването. Разширяването на системите е много по-лесно от разширяването на персонала и доста по-ясно като задача, та ако не се работи правилно, много често админите на някаква система издъхват, преди да е стигнала някакви сериозни размери. Изброил съм доста от полезните уроци, които са ми улеснили много работата – повечето ги има в хубавите книги.
Изобщо, ако ви е интересна темата, идете и прочетете “The practice of system and network administration”. Ще откриете много интересни работи…

[слайд 7]

Да започнем с мониторинга. Лафът “има два типа хора, такива на които им е гърмял хард диск и такива, на които ще им гръмне” ми е толкова любим, че чак го написах в презентацията …
Поддръжката на система без monitoring е подобна на шофирането сляп и глух. Няма да имате идея какво правите, какво се случва и какво го предизвиква и в общи линии ще трябва да гадаете.
Имам една примерна случка от съвсем наскоро – един приятел има лична машина, co-locate-ната някъде, на която има два RAID1 масива с по два диска. Преди около година един диск от единия масив отказал, след това преди 3-4 месеца отказал още един диск, но от другия масив. По някое време един негов приятел минавал през colocation-а и после му казал “абе ти знаеш ли, че на твоята машина отпред светят две червени лампички?” (някъде тук моя приятел твърдеше, че colocation support-а е трябвало да му каже, че има такова нещо, но те няма откъде да знаят това дали е нормално или не, няма стандарт за нотификация от предните панели). Та, тръгнал той да сменя дисковете, но докато се накани му гръмнал още един диск, а докато backup-вал – и последния.
Както би казал Captain Hindsight в такъв случай – “трябвало е да има monitoring и това нямаше да се случи”.

Monitoring-а ви пази от downtime – ще видите гръмналия диск преди да стане бедствие, пълнещата се файлова система преди базата ви данни да спре да може да изпълнява заявки или mail server-а ви да може да приема поща, ще ви каже, че някой service ви е спрял и какво ли не още.
Също така monitoring-ът ще ви даде данни за бъдещо планиране – колко трафик правите, с каква скорост си запълвате ресурсите, в кои периоди може да очаквате повече или по-малко натоварване, и т.н., и т.н..

Аз лично ползвам nagios за всичките си машини, включително и за някои неща по работната ми станция вкъщи.

[слайд 8]

Тук съм показал как изглежда моя системен статус – това е nagios checker, plugin за firefox, който показва постоянно статуса на един или няколко nagios-а (това е редчето най-най-долу) и при on-mouse-over показва по-подробен статус (всичко останало, което се вижда в жълто/червено). На този се вижда как два от ftp сървърите са малко по-натоварени, има 4 дискови масива, които се rebuild-ват, два масива дето са изхвърлили по един диск, един масив, който си мисли по въпроса и един IPMI модул, който изглежда е изгорял.
Има варианти на plugin-а и директно за gnome или каквато работна среда ползвате, всеки както му е удобно. Много хора ползват външен монитор или нещо такова да им стои там целия статус.

[слайд 9]

Може да видите няколко публични примерни monitoring-а – моят публичен nagios, един munin пак за същите машини (страхотен tool, лесен за конфигуриране, прави много добри графики и писането на plugin-и е направо радост за душата), и един пример за великолепно подкаран nagios с много услуги. Моят например има по 7-8 услуги за машина, които се следят, те имат по 20-30 и все подходящо измислени, препоръчвам на всеки да погледне какво и как следят.

[слайд 10]

Това е нещо старо като света, даже го намерих в една книга за писане на бази данни от 1992ра. Идеята е, че за една система не трябва да се налага да се променят няколко различни места, когато се прави промяна по нея – не трябва да се пипнат конфигурациите на 8-9 различни неща и да се направят други 10 действия, понеже хората грешат, ние сме хора и ще сбъркаме нещо. Или ще пропуснем определено действие, или ще объркаме нещо, докато го правим, а ако направим скрипт, който от една централна конфигурация да създаде всичките тия конфигурации и направи действията, първо ще си спестим работа, второ ще си спестим грешки. Скриптовете определено грешат по-рядко от хората…
Този съвет за съжаление рядко е използваем в малки системи.

[слайд 11]

Тук съм дал един мой примерен скрипт, който генерира конфигурация на dhcp сървър. Скриптът е грозен до смърт и съдържа в себе си три езика – bash script, SQL и dhcp config – но съвсем накратко прави следното: генерира един конфигурационен файл, тества дали е различен от текущия, ако да – пробва да рестартира с него, и ако не сработи, ми праща mail и връща старата конфигурация. Елементарно е да се напише, работи като слънце и не ме кара да правя много неща – този скрипт и още няколко се изпълняват от cron-а и всичко се update-ва без никаква човешка намеса.

[слайд 12]

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

[слайд 13]

Автоматичните инсталации са нещо почти животоспасяващо, а и аз при мен съм решил въпроса по толкова готин начин, че не мога да не се похваля :)

По принцип началната инсталация е мястото с най-много грешки. Във всеки един инсталатор има м/у 20 и 100 избора, които трябва да се направят, особено ако става въпрос за сървър и потенциалът за грешка или просто различна инсталация е огромен. Вероятно няма начин един човек да направи 10 инсталации през debian-ския инсталатор за една седмица и да направи 10те машини еднакви (има шанс и 10те да са съвсем различни). Да си оставяте такава дейност е като да си пречите сами.
(за съжаление и това е безсмислено за по-малки системи, ако имате един сървър, няма от кой да е различен)

Това доста хора го научават бързо, и на местата, където машините се дават preinstalled (като например всичките инстанции по cloud-овете) хората си имат един малък скрипт, който качват на машината и който я довежда до желаното до тях състояние.

При мен инсталацията представлява следното: първо ми монтират машините в rack-овете и ги настройват да boot-нат по мрежа. Машините тръгват, зареждат през pxe/nfs един image, в който тръгва нормална операционна система, на която последният и boot script (/etc/conf.d/local.start, понеже е gentoo) стартира един мой скрипт, който от своя страна се свързва с една централна машина и казва “здрасти, аз съм с mac адрес еди-кой-си”. Централната система проверява този mac адрес на кой switch/port се намира, проверява в таблицата със сървърите (вижте на слайд 12) какво трябва да има там, дали е работещо или не и или казва “не прави нищо, не знам за тая машина/вече е инсталирана”, или дава нужните настройки като hostname, ip, net, gw. Ако има получени настройки, скриптът създава partition-и, прави файлови системи, настройва разни полезни неща като адреси на ipmi контролера и парола за него, разархивира един готов image, сменя по файловата система настройките като за машината, рапортува на централната система, че е готов и рестартира. Централната система си отбелязва, че машината е готова и че трябва да и даде да boot-не нещо друго на следващия път.
След което аз на сутринта си пускам лаптопа и виждам – а, имам още 18 инсталирани машини, хайде да им качвам съдържание (което също се прави с една-две команди). Мисля си, че единственият по-мързелив начин щеше да е да ми ги пращат готови инсталирани.

[слайд 14]
Тук малко ще се отклоня и ще се опитам да обясня колко важна е автоматизацията. Системните администратори сме мързеливи и ТРЯБВА да бъдем – хората, които не ги мързи ще си кажат “защо да автоматизирам това просто нещо, ще ми се налага да го правя само веднъж седмично/веднъж на ден” и в един момент се натрупват достатъчно такива дреболии, че не им остава време да се огледат и се получава “death by a thousand cuts”. Мързелът е важен, и може да видите на

[слайд 16]
програмист, който тренира за системен администратор.

[обратно на слайд 14]

Всичко, което се прави често, трябва да се автоматизира. Всичко, което се повтаря и се прави рядко – също, защото има шанс между две правения да забравим как става. Научете се да пишете код и пишете, това ще ви спаси живота. Няма нужда даже да е добре, ето един мой пример:

[слайд 15]

Това е един много прост скрипт, който проверява кои машини са report-нали, че имат проблеми с дисковите масиви, логва се да види какво се случва и ми вади списък в следния вид:

rack/cage (SD id)               server  port    serial
XXX/DA3:20460 (CUST.YYY)        s333    p9      JPW9H0HQ2XS8AH
XXX/DA3:20460 (CUST.YYY)        s452    p5      JPW9J0HD1J3JMC
XXX/DA3:20460 (CUST.YYY)        s542    p3      JPW9N0HZ0MN8JL

Това аз мога да го пратя на човека през океана, който да иде на място и да ги смени. Не съм направил скрипта и да праща поща, понеже има няколко случая, в които и аз трябва да погледна, преди да съм сигурен, че дисковете може да се извадят спокойно.
(някой ме беше попитал защо там има ssh root и т.н. – първо аз ползвам ssh agent и няма как някой, който се добере до машината да добие лесно достъп до всичките, и второ аз работя само от root – аз admin-ствам тези машини и почти няма команда, която да може да работи от нормален потребител, а да пиша sudo на всеки ред е безсмислено).

[слайд 17]

И една леко религиозна тема – трябва ви хубав naming convention. Това е от нещата, за които просто няма друг начин при големи системи. По принцип важното е имената да са лесни за произнасяне и запомняне (доста хора използват филми/сериали като източник (Simpsons), други използват фентъзи книги (в Толкин има около 200-300 героя, в Малазанска книга на мъртвите – около 1000)). Аз лично за тази система използвам съвсем простата конвенция от една буква, определяща функцията на машината (w – web server, d – db server, s – storage) и номер. Така знам машината какво прави само по името и е съвсем лесно да я кажа на човека отсреща, който се намира в шумния datacenter и около него вият 10-15000 вентилатора.
(от друга страна, личните ми машини имат съвсем random имена, щото са малко и защото успявам да ги запомня – marla, tyler, cassie, lain, alpha…)

[слайд 18]

Резервните пътища са нещо също много важно. Почти всеки, който някога е администрирал каквото и да е отдалечено си е отрязвал клона, на който седи (в слайда има прекрасен пример с ifconfig eth0 down).

Искам да дам три примера от при мен за резервни пътища. Първият е как всеки сървър при мен има IPMI модул, който има отделен мрежов порт, закачен за отделен switch, така че да мога да стигна до машината и да видя какво се случва с нея, ако се налага, както и да мога да я командвам. Това дава възможност да разбера например, че дадена машина е прегряла и се е изключила, вместо да се чудя дали не е проблем в мрежовия и порт.

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

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

[слайд 19]

Може би понеже аз съм тръгнал от интернет доставчик ми е странна идеята някой друг да ми оперира мрежата, но това се оказва стандарта в момента – хората си наемат/слагат машини в някой datacenter, от datacenter-а им дават internet и мрежа през един порт на всяка машина и така цялата комуникация между компонентите на една система става 1) през порта, който е и за външния трафик и се бори с него и 2) през мрежа на някой друг, с различни цели и съответно такава, на която не може да се вярва. Мрежата е централен компонент на всяка една система в наши дни и невъзможността да знаете какво се случва в нея и невъзможността да го променяте/контролирате ви ограничава сериозно.
(например моята автоматична инсталация нямаше да има начин да става толкова лесно, ако не си контролирах мрежата)

Една фирма, с която работих преди известно време имаше огромен проблем с това, че не си контролираше мрежата – те са по-големи от това, с което се занимавам (имат около 1800 машини в 4-5 големи datacenter-а) и съответно понеже им се налагаше да репликират mysql през internet, бяха правили някакви страшни и почти гениални изпълнение, за да им работят нещата, а докато бях при тях, основните проблеми идваха от мрежата.

Също така собствената мрежа ви дава възможност да пуснете BGP, да си вземете ASN и за всякакви такива други хубави трибуквени съкращения :) Така може да купувате свързаност от няколко различни доставчика и да не трябва да им търпите проблемите.
Ще говоря накрая и за една много хубава моя система за наблюдение на трафика, която пак щеше да е невъзможна без моя мрежа.

[слайд 20]

Ако някой ден се навия да направя по-голям курс по системна администрация (или цяла магистратура), изпитът на края ще се проведе по следния начин: ще хвана студентите, ще идем да пием някъде, ще ги пратя да спят и след това ще ги събудя в 4-5 сутринта да решат проблем. Оценката им ще бъде на база на това колко часа downtime са имали.

Нещата трябва да се правят просто, защото проблемите винаги ще изникват в най-лошите възможни моменти и трябва да може да се справите без значение в какво състояние се намирате. Това значи и да може да пазите цялата система в главата си, целият и state, което значи и нещата да са максимално унифицирани (защото колкото по-малко неща трябва да помните, толкова по-лесно ще ги запомните).

Препоръчвам на всички да тестват следното – да се напият, да си си легнат към 12 и да са си навили алармата за 4 сутринта, след което да станат и да се опитат да направят нещо просто (например да решат квадратно уравнение или някой прост тест за интелигентност). Вероятно ще има отрезвяващ ефект :)

Нека да цитирам Jim Gray, “Although there are no textbooks on simplicity, simple systems work and complex don’t.”. Това всички го виждат, но никой не иска да го приеме, понеже изглежда простите системи не са готини, и човек не изглежда умен, ако не направи нещо гигантско и сложно (което после се оказва невъзможно за поддръжка). Както при програмирането дебъгването е три пъти по-сложно от писането, така при правенето на системи работата с тях и оправянето на проблеми е доста по-сложно от измислянето и поне според мен хората, които правят много сложни и “умни” системи не са особено умни.

[слайд 21]

Искам да спомена и малко проблеми, които можем да срещнем в големите системи.

Първият е разпределението на натоварванията и събитията. Нека да дам за пример пасивния ми monitoring – той представлява cron скрипт, който веднъж на 5 минути се стартира и праща малко данни към един централен демон, който обработва информацията. Това при достатъчно сървъри би довело до претоварване на централната система и решението е съвсем просто – един sleep за random секунди (м/у 1 и 60), така че събитията да са пръснати във времето.

Другият е премахването на SPOF (single points of failure). Много често като наследство от времената, в които дадена система е била малка се намират разни компоненти, които ако откажат и цялата система спира да работи. В голяма система това трябва да се избягва и като цяло компонентите да могат да се заместват един-друг или да не са толкова важни, понеже колкото повече отделни части имате, толкова по-голям е шанса някоя от тях да откаже. Ако всяка част ви е жизненоважна, то ще трябва през цялото време да тичате след всеки дребен проблем и да нямате време да свършите нещо реално полезно.
Да се направи нещо дистрибутирано е сложна задача – стъпката от една до две машини (или даже от single thread до няколко thread-а) е тежка и по-сложна от тази от две до хиляда, но определено си струва. Ще ви спести будения посред нощите от големи проблеми и ще ви даде допълнително спокойствие.
(например аз почти нямам компоненти, които могат да убият цялата система със срива си, съответно мога да спя спокойно и каквото и да стане, да мога да го оправя на сутринта, като стана)

[слайд 21]

Ето един пример защо е важно да сме дублирани и да не зависим от отделни дребни неща – понеже редките явления в достатъчно голяма система стават нещо нормално. Този screenshot показва как на машина с 12 диска и 12те са гръмнали в един и същи момент.

Това ми се е случвало два пъти.
(първия път сърцето ми прескочи един път:) )

[слайд 22]

Две интересни неща, от големите системи и от при мен по принцип.

Едното е нещо, което много хора според мен не правят правилно. Много често се казва – имаме нов проект, айде да купим още web, db и т.н. сървъри и да направим отделна инфраструктура, вместо просто да се разшири текущата. Така човек се озовава с много малки компонентчета, от които който и да е ако замине, има някакъв downtime на някаква услуга и съответно пожари за гасене. Разширяването на текущите системи, и дистрибутирането (доколкото е възможно) всичко да може да работи от всяка машина дава огромно scalability, издръжливост на атаки и доста по-спокоен сън. Аз лично трябва да гледам внимателно дали някой ни DoS-ва, понеже при нас нещата са достатъчно добре разпределени, че почти да няма кой да ни засили ефективна атака.
Според мен и така трябва да се борят DoS атаките.

Другото хубаво нещо, което написахме и което исках да пусна да се ползва публично, беше система за следене на трафика и загубата на пакети. При нас ползваме web сървър, който е вътрешно производство, и той праща по един пакет статистика за всеки connection, който е завършил, с данни колко байта и пакета са минали, към кой ip адрес, за колко време, тип на трафика и колко TCP retransmit-а е имало. На база на тази статистика и BGP таблицата аз мога да видя почасово към кои мрежи и автономни системи (и през кои пътища) имам повече загуби и да преценя дали искам да изместя част от трафика някъде другаде.
(след конференцията един приятел се нави да port-не нещото за apache и да пуснем колкото можем от него open-source, та може да има новини по темата скоро)

[слайд 24]

Та, ако ви е TL;DR лекцията, какво си струва да запомните:
1) имайте (добър) monitoring
2) правете нещата толкова просто, че да може да ги ремонтирате в 4 сутринта на пияна глава
3) Автоматизирайте
4) Имайте резервни варианти

(и пращайте корекции на тоя текст, че е писан на един път)

Свърши Openfest 2012, и въпреки че не бях в организацията пак съм скапан.
(дължи се на работа и участие в 4-5 лекции (2 мои))

Вероятно ще напиша нещо по-дълго тия дни, включително двете си лекции (Яна ще напише нейната част от лекцията за депресията).

И двете лекции се получиха доста добре, въпреки че втората не успяхме да я репетираме изобщо (и я дописвахме в неделя на обяд). Ето презентацията от първата (odp,pdf) и втората (odp, pdf). Мисля да помоля организаторите да ми дадат записа на втората да го пусна по-рано.

Специално за втората аз и Яна си бяхме дали адресите накрая, за хора, които имат нужда да си говорят с някой (vasil(at)ludost.net, yana(at)ludost.net), също така се включи и Нейчо Михов (neycho.mihov(at)gmail.com), ще добавя в тоя post (и като измисля някакъв сайт за целта – и там) адресите на всички останали желаещи да слушат другите.
Може би най-хубавото и неочаквано нещо беше колко много хора след това ми благодариха, казаха колко е била хубава лекцията и казаха, че сериозно са се замислили. Искам да благодаря на всички от “програмния комитет”, които бяха на моя страна за правенето на тая лекция, и най-вече на Стефан Кънев.

Също така мисля, че този openfest затвърди традицията аз и Стефан Кънев да се ебаваме един с друг. Той ми провежда “интервюта” и в предишните си презентации намираше къде да ме добави (в последната ме нямаше), а след историята със снимането обяви, че ако с мен се снимат 50 човека, ще направи продължение на intro клипчето от openfest.
(историята със снимането е как като бях отишъл на една лекция от курса по Python и си говорех с него в почивката дойдоха при нас няколко студента, той ги пита какво искат да питат и те му казаха – нищо не искаме да питаме, искаме да се снимаме с крокодила… Кънев много обича да я разказва тая история…)
След като с мен се снимаха много хора, аз в последния slide на лекцията за депресията сложих една снимка на Кънев, допипната от Лъчко, на която да изглежда депресиран и приканих хората да се снимат с него, за да го ощастливят. Погледнете, мисля, че Лъчко страхотно се е справил :)

В крайна сметка обаче той води – с мен се снимаха толкова хора, че в един момент ми беше трудно да гледам от всичките светкавици. Чудя се как да му организирам flash mob.

(а колко хубаво си допихме и куфяхме на afterparty-то, думи не могат да опишат, та оставям на някой друг да разкаже :) )

Update: iffi също се включи в списъка на слушащите.
Update 2: Стефан Кънев също се включи в списъка на слушащите.

Идва OpenFest 2012, ще правя там две лекции.

Едната ще е за това колко по-лесно се поддържат 700 сървъра, отколкото 3 – според разни хора това би било интересно (за мен голяма част от нещата са твърде стандартни и ги пише по всичките книги). В последните 2-3 години насъбрах много забавен опит около това и се надявам да не се получи много скучно. Ще бъде от 17:00 в събота в зала София.

Другата ще е по любимата ми в последната една година тема за депресията, самоубийствата, проблемите в главата и други такива весели неща. Отдавна мисля, че е нужна подобна лекция – проблемът е голям в цялото IT общество, но всички се опитват да не го забелязват (при това доста успешно). Ще я водя заедно с Яна Петрова. Ще бъде в неделя в галерията от 14:00.
(имаше сериозен вой и отпор против лекцията, но и доста хора, които се заинтересуваха и бяха за)

Иначе, има още няколко интересни неща. Едното е лекцията на Венета Донова за юридическите моменти около поддържането на сайт и предлагане на услуги през него, от 12:00 в събота в зала София (за която поемам част от вината, аз я навих да я прави), другото е лекцията на Владо Василев за hackerspaces на балканите, в България и какво се случва в последната една година, от 15:20 в събота в галерията(където имам някакво минимално участие и третата (с която нямам нищо общо) е лекцията на Стефан Кънев за парадигмите в програмирането, от 11:15 в събота в зала София (поставя си много висока цел с тая лекция, да видим как ще се справи :) ).

(а мен ме чака още доста писане и редактиране, особено за втората ми лекция)

Преди няколко дни ми се обадиха да ми кажат “понеже < специфични причини>, трябва да подкараме тука един скенер под linux, да се сещаш някой да може да помогне, например в initLab?”. Понеже на мен ми беше леко скучно, седнах със Алекс Станев да видим какво можем да направим.

Хардуерът беше един Canon DR-3010C и към него Flatbed Scanning Unit 101 (който се водеше като допълнителна част към другия и че не може да работи отделно). Сашо с малко хакване беше успял да подкара самия DR със SANE (patch-ът беше тривиален и вероятно ще го submit-нат скоро), но с другото желязо имаше проблем.

След като със зор подкарахме нещото на един windows, за да го заслушаме и да видим как работи. Flatbed-а тръгна само със софтуера на canon, като преди това трябваше да няма лист в другото устройство, но видяхме малко комуникация и че изобщо работи. След като открихме, че протоколът му няма нищо общо с другия го отворихме, видяхме чиповете вътре, открихме, че е с GL846. Оказа се, че тоя flatbed си е съвсем отделен скенер, който може да се контролира директно, както и че в SANE има драйвер за близки до него чипове (в този чип стои целия контрол и USB-то, т.е. комуникира се директно с него). Пробвахме се да го подкараме със съществуващите драйвери, но явно има достатъчна разлика м/у чиповете, че да трябва да се пише.

Та решението на въпроса е в крайна сметка някой да отдели една седмица и да patch-не съществуващите драйвери (има си подробна документация) и да направи flatbed-а използваем сам по себе си – задачка за програмисти, интересната работа свърши:)

Днес ме замъкнаха на странно събитие – openCoffee (в betahouse), на което се представяха две приложения, свързани с таксита. Едното беше в общи линии система за поръчване/намиране на таксита, другата – каталог на фирми, като и в двете имаше рейтинг, който да помага на хората да се ориентират. Като цяло първата идея беше по-интересна (taxiMe или нещо такова).

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

Втората па е тривиално атакуема, с един скрипт, който генерира рейтинги (направо бизнес може да се направи, “ще ви вдигнем рейтинга и ще преебем тоя на конкуренцията ви”).

Това обаче, което ми направи голямо впечатление е как специално вторите хора си мислеха (а май и първите), че само тяхното приложение може да говори с техните сървъри и ако някой реши да прави такива неща, ще му трябват милион телефони и download-и, реални хора и т.н., вместо просто да се reverse-не протокола (не повече от ден работа, ако ползват https и проверяват сертификати, 5-10 минути в противен случай). Направо си спомням в BOFH един израз, “It truly breaks my heart to see trust like that go unpunished”.

Някой ден трябва да се направи workshop “Как да чупим на хората хубавите и недомислени service-и”.

С позволението на организаторите:
Записи с description;
Директория.

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

Спимисеспимисеспимисе.

(преди всичко – браво на dzver-а, че въпреки всички идиотски пречки и т.н. се справи с wordcamp-а, без да се налага после да го прибираме в някоя лудница, браво и на Ники Бачийски).

Днес беше WordCamp Sofia 2012.

Вчера следобед разположихме техниката, вечерта направихме малък запой, сутринта станах в 7:30 (изобщо не ми е ясно как го постигнах) и се занесох на място.

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

Записах лекциите (до тук е ясно, че на Марио половината я няма и като гледам, една от другите има проблем), изнесох и аз една (същата като от varnaconf, но по-зле), като цяло беше весело.

Две лекции ми бяха интересни. Първата беше на Калин Терзийски, за вдъхновението – получи се доста интересно, въпреки че сякаш не беше за този тип публика и трябва да видим кой я е харесал (за момента май сме само аз, Комитата и Стефан, повечето по-млади не са). Втората беше на Кънев, от която почти нищо не мога да си спомня, но някакви части ще влязат в лекцията ми за депресията.
(за съжаление точно след лекцията на Терзийски започна моята в другия поток и не можах да си поговоря с него)

Afterparty-то беше интересно, в някакъв странен бар (май се казваше “Dada”), където се засякох с всякакви стари познати, пийнахме добре и даже по едно време Марио посвири на пианото. Аз успях да сбъркам пак Калин и Ниньо (и да помисля Калин за Радо), смятам сериозно да проуча как точно тия тримата са се събрали в лаба и защо са ми толкова подобни. Само се притеснявам, че ще взема да изкарам наяве някаква история от техните родове, дето никой не я знае…

Имаше и въпроси по темата дали с Кънев живеем заедно (не) и дали имаме някаква връзка (не, въпреки че му се иска). Вероятно трябва да се напише FAQ по въпроса.
(примерни въпрос/отговор:
Q: Защо Стефан прави палачинки сутринта през weekend-ите?
A: Защото знае, че е любимата храна на крокодила и го подмамва с подли намерения.
)

Откривам, че паметта ми никаква я няма и вероятно трябва да намаля малко четенето и прекъсванията. Очаквайте записи от wordcamp тия дни.

(концертът започна в 22:30 и свърши към 02:30)

Започнаха странните австралийци от Alithia, които свириха нещо странно (пишеше “astral core” или нещо такова), имаха добри идеи и ми се видяха някакси недовършени. Взел съм си двата им диска да ги прослушам и да видя как са на студиен запис.

Последваха Кайно йесно слонце, които са любопитна музика за такъв концерт – много ambient, много спокойно, чак цялата публика насяда пред сцената, за да ги слуша. Лошото е, че те трябва да свирят в някоя опера/филхармония или някакво такова място, в което публиката мълчи – те самите са тиха група и никой не могат да надвикат, включително партито от съседната дискотека.

Smallman пак свириха страхотно, въпреки че бяха бая уморени и че имаше няколко криви технически проблема. Направиха и няколко нови парчета, да видим кога ще се появи албума (нищо не споменаха по въпроса). Усещането след тях е някакво размазано и спокойно, не като след нещо с много куфеене (не че нямаше).

Мина втората книжна лекция. Бях уморен, говорих зле и доста “значи”. В общи линии препоръчвам да видите книгите въпреки некадърния начин, по който съм говорил/писал за тях. Блокирал съм и се надявам да се оправя за седмица две (ако трябва, ще се напия лошо, да направя hard reset).

Запис.

В крайна беше смесица от различни книги. Общото е, че карат човек да мисли и са приятни за четене.

Cryptonomicon на Neal Stephenson

“Историческа фантастика” – история, която включва хора като Алан Тюринг, Дългас Макартър, Чърчил и други интeресни исторически фигури, обсъждайки през цялото време криптографията, приложенията и, data heaven-ите и други близки теми. Много добре написана, книгата е една от най-известните такива в компютърджийските среди.

Barefoot into cyberspace на Becky Hogge (може да се чете/свали на сайта ѝ).

Описание на историята от последните няколко години в “киберпространството”.Описва CCC конгреса, срещите си с Rop Gonggrijp и Julian Assange, Cory Doctorow и може да представи доста от събитията от тогава в перспектива.

Coders at work

Интервюта с различни програмисти – как работят, какво са правили, и т.н.. Включва:
Доналд Кнут
Кен Томпсън
Питър Норвиг
Jamie Zawinski
Полезно е да се види как работят хората, чиито софтуер по един или друг начин ползваме. Кънев ме помоли да отбележа как никой от тях не ползва debugger и debug-ват с print.

Where the wizards stay up late на Katie Hafner и Mathew Lyon

История на създаването на Internet. Обхваща нещата от първата разработка на IMP-овете за ARPAnet до нещата, които ползваме в наши дни. Има доста подробности, но нивото е достатъчно ниско, за да може да се разбере от повечето хора.

TCP/IP Illustrated Vol.1 на W. Richard Stevens

Все още най-доброто описание на tcp/ip протоколите. Въпреки, че книгата е от 1994, има нужда от съвсем малко добавки и съдържа всичко нужно, за да се схване как работят протоколите. Аз съм я чел с удоволствие преди сън.

The practice of system and network administration на Thomas Limonicelli и Christine Hogan.

КнигаТА за системна и мрежова администрация. В нея няма команди и обяснения как да пуснете нещо съвсем конкретно, но реално има почти всичко, свързано със системната и мрежова администрация, от базови принципи за правене на системи, през различни типове услуги, до глави като “Being Happy” и “Firing System Administrators” (което е от нещата, които много хора не знаят). Трябва просто един път да погледнете съдържанието :) Книгата е на достъпен език и може да бъде четена спокойно от не-технически хора.

Little brother на Cory Doctorow, достъпна под свободен лиценз, например тук.

Донякъде антиутопия – описва свят, в който след още един атентат американците тотално се побъркват и въвеждат средно-тоталитарни мерки в един град. Разказът е за група тинейжъри, които се борят срещу това чрез различни технологии. Добър увод за някои технологии като rfid, криптография с публични ключове и mesh мрежи.

Gang leader for a day на Sudhir Venkatesh

Като студент по социология пратили автора да разпита по някакъв въпросник хората в по-“мрачните” квартали на Чикаго. След като една банда го задържала известно време и му изкарали акъла, в крайна сметка се сприятелил с тях и направил най-хубавото изследване на живота там. Книгата описва седемте години, които е прекарал сред тези хора и как как за един ден е заместил лидера на една от локалните банди.
В книгата няма много графики, таблици и т.н., но ако ви хареса, може да потърсите другите му неща, където има и които са си директно научни изследвания.

V for Vendetta на Alan Moore, илюстрирано от David Lloyd

Алан Мур е един от големите писатели в областта на комиксите – нещата, които пише се занимават с интересни и дълбоки проблеми и карат хората да се замислят. Филмите, правени по двата комикса не струват – опитват се да направят да има добри и лоши, но реално в нещата на Alan Moore такива няма, има просто две (или повече) страни и е в ръцете на читателя да реши дали предпочита някоя от тях.

Yokohama Kaidashi Kikou на Hitoshi Ashinano.

“Ambient” комикс – добре нарисуван, с хубава и спокойна история, за четене в дъждовни дни :) Няма го преведен официално, но има хубав неофициален превод на английски и руски, вероятно и на други езици. Държа си при мен любимата си глава и по принцип го препрочитам от време на време.

И като bonus – “То” на Стивън Кинг. Не я четете преди лягане, но я прочетете – голяма и интересна история, влиза ви под кожата и ако не друг, може да ви покаже как се пише наистина добре.

Update: Оказва се, че TCP/IP Illustrated vol.1 имала второ издание, с допълнения – нещо, за което говорих, че ми се иска да стане. Изглежда прилично на пръв поглед, като я прочета, ще пиша пак.

Update: Лекцията ще се проведе на 4 октомври 2012 в initLab от 20:00.

Планирам да направя втора книжна лекция, пак в initLab. Възможните теми са:

1) компютърно-исторически книги
2) твърда фантастика, чиито идеи ще имат/имат отражение в компютърджийството
3) класически технически книги
4) “главознание”
5) смесица от каквото ми падне

Предпочитания?

(лекцията мисля да е на края на тая седмица (неделя) или следващата (вторник/четвъртък)).

(не пиша това заради конкретен случай/човек)

Септември е гаден месец. Хората се прибират от отпуски, става им студено и започват да се случват всякакви гадости – късания, умирания, генерални депресии и т.н. и т.н., та май е крайно време да напиша това.

За повечето хора фразата от заглавието е някаква грозна шега или подигравка. Всъщност е доста полезна философия – така и така не е ясно какво ни очаква и трябва да сме подготвени за най-лошото, защо трябва и да страдаме?

Това е като логичното продължение на “Life sucks, and then you die” – и какво от това? Трябва ли по пътя всички да страдаме? Гадността на живота донякъде не зависи от нас, но как се чувстваме си е изцяло под наш контрол (ако трябва, с помощни средства като C2H5OH).

Да отбележа, аз не съм от групата на болните позитивисти, които казват “радвайте се, нещата ще се оправят”. Не е ясно дали ще се оправят, но това няма значение.

Или, да се повторя още един път, “Life sucks, suffering is optional”.

Ако това не помага и не ви се намира кой да ви изпише дрога, може да се успокоявате с мисълта, че има бегъл шанс светът да свърши след няколко месеца и да не се мъчите повече :)

(или защо трябва да си носим някакви стотинки в джоба)

Редовно около мен хората се чудят да направят A или B, и аз постоянно разказвам за тоя метод, та май е крайно време да го блогна.

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

След като на всяка стъпка имаме по две възможности, взимаме една монетка (от 50 ст или 1 лв са най-подходящи, защото са достатъчно големи), казваме – ези за това решение, тура за това (или герб/стотинка, аз така и не научих кое е ези и кое тура), хвърляме монетката и докато пада, на нас вече ни се е изяснило в главата кое искаме (ако все пак не се е изяснило, значи че няма разлика и можем да вземем решението от монетата). Повтаряме упражнението, докато стигнем до листо/край в дървото на решенията.

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

Не знам дали имам особено хубаво обяснение защо (и изобщо как) работи тоя метод. Може да го сравня с оня експеримент с котката на Шрьодингер – като проверим наистина, можем да разберем състоянието, и когато с монетката сме изправени пред резултат можем да сравним него с реалното ни очакване/искане. Подобно нещо се получава, ако си говорим с някой и той се чуди дали да направи A или B и му кажем “направи A” – понякога ще се случи да каже “не ми харесва, ще направя B” – което е подобен процес, на реално осмисляне на варианта.
Същото нещо може да се направи без помощни средства като монети, други хора и т.н., но изглежда, че това е по-лесно за повечето хора, вместо да приемат, че са взели едното решение и да видят/разберат колко им харесва.

(подобно нещо беше писала и iffi)

Докато си вися на Aniventure, малък status update:

Лекции записваме всякакви. Последно беше crash course в django, още записваме лекциите на курса по микроелектроника (които успяват да направят по една non-stop лекция от 19:30 до 23:00 без някой да припадне) и се появяват всякакви нови идеи, от които вероятно ще се реализират 10% и ще пак ще се запълни времето на лаба.
(всъщност, всякакви интересни идеи за лаба се приемат, мисля, че си го пише на сайта :) )

Аз имам идеи за две лекции – едната е как става поддръжката на 700-800 машини (системата в hotfile), за която вече имам фирменото съгласие, другата е депресията, самоубийствата и другите такива весели неща (за която все повече и повече говоря в последно време, наскоро на един рожден ден се напих и говорих около 3-4 часа по темата). Не е ясно дали ще мога да реализирам и двете (за втората още не съм сигурен, че искам да се захвана, на първата съм готов на 30-40%).

Също така, търся някой да помогне с малко javascript, да направим нещата на va.ludost.net гледаеми през някой flash player – самите файлове нямат проблем, модула за seek-ване ще го добавя в web сървъра тия дни, само някой трябва да направи свързващия момент. Ако се намира желаещ, да се обади, ще седнем някой ден в лаба и ще попишем :)

След като много време се каних и не го свърших, Велин направи RBL за източници на български спам. Попълнен е от един списък мои правила и един негов, репликиран е на три машини с добра свързаност и може да се ползва свободно от който си иска (на собствена отговорност, as usual).

Update: Правило за spamassassin:

header FCCF_BG_RBL      eval:check_rbl('fccf_bg','rbl.fccf.net')
describe FCCF_BG_RBL    rbl.fccf.net for sources of Bulgarian spam
score FCCF_BG_RBL       3.5 3.5 3.5

(score-овете вече може да си ги настроите както искате)

Понеже тия дни ме е хванала словесната диария, седнах и описах как правя записите и streaming-а, с надеждата и други хора да се възползват от това, както и да има някой друг, който да го прави вместо мен в lab-а от време на време.

Пишете, ако имате корекции, идеи и т.н., онова там е wiki, така че може директно да добавяте и там.
(в момента с Андрей правим експерименти да записваме screencast в лаба, после ще опиша опита и от това забавление)

Киро (voland) (който има общо с организацията на събитието) ме зариби да ида на Ratio, което ще се проведе на 29.09 в София (подробности за къде и т.н. има на сайта).

Изглежда интересно, лекторите нямат вид на идиоти и като цяло не ми се вижда bullshit конференция като TED. Има някакъв минимален вход (може да се види на link-а за регистрация) и online продажбата на билети работи (трудно, мъчително и с бъгове, но върши работа).

(disclaimer: не са ми плащали, това не е реклама, на мен наистина ми изглежда интересно)

Докато вися на палачинките при Кънев, няклко кратки неща.

Продължават да се качват записите за курса по микроелектроника.

Вчера почти без да искам засякох Марио Пешев да води лекция в лаба (така е, като не гледам календара) и съответно го записах и качих (не го stream-нах, понеже никой не знаеше). Има лекция за Django след две седмици, тя също ще се записва/stream-ва, а аз ще чета календара по-често.

Тия дни release-наха MusOpen DVD-то със записи на изпълнения на класическа музика под отворен лиценз, съответно имам с какво да направя хубав фон на постоянно висящото излъчване на stream-а на лаба, та като събера желание ще пусна да върви нещо там.

Записите могат да бъдат намерени в wiki-то на va.ludost.net или директно в http://va.ludost.net/files/varnaconf/2012/ (директорията с файловете).

Звукът е ремонтиран донякъде (почистване на шум и усилване) и би трябвало да е донякъде разбираем, за в бъдеще ще се вкарва директно от пулта в камерата, само да се снабдя с нужния хардуер. Също така няма отпечатъци от пръсти по обектива, размазаните неща, които се виждат на екрана на проектора са просто как някой по погрешка е драснал на него и се е опитал да го изтрие с гъбата.
Оставил съм всички представяния и announcement-и, понеже е важно да документираме първите стъпки на MC Стефан Кънев за поколенията. Препоръчвам на всички конференции в България да го канят да върши тоя тип работа, ще им се увеличи посещаемостта :)
(най-малкото той си има приличен фен клуб)

За летния курс по микроелектроника в initLab – записите могат да се видя в wiki-то на va.ludost.net или направо в директорията там, за момента е качена уводната лекция от вторник. Stream-а ще е достъпен на http://stream.ludost.net/lab.ts (оправих в общи линии проблема и няма нужда да се дописва и порта).

(май съм готов със записите от varnaconf, ако бъдат харесани от няколко човека, ще пусна link и тук).

Това е лекцията ми от 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 също мога да направя цяла отделна лекция, в която да си излея мъката.

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

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