Posts Tagged ‘varnaconf’

Записи от VarnaConf 2012

Thursday, August 16th, 2012

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

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

2012-08-13 Лекцията ми от VarnaConf (tldr)

Monday, August 13th, 2012

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

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

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

2012-08-12 VarnaConf

Sunday, August 12th, 2012

Вчера беше VarnaConf.

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

Аз пристигнах в четвъртък във Варна с Жоро Митев, като преди това бях пратил кашона с техниката по куриери. Видяхме локалния hackerspace (Varnalab), където вечерта Кънев изнесе 3 часа лекция за vim, видяхме се с локалните хора и изобщо си изкарахме весело.

В петък отидохме до Варненския Свободен Университет, за да разположим техниката и да видим залата (за която преди това Радо ми беше пратил малко снимки), което направихме за час-два (за какво можеше да стане по-добре – след малко). Последва мотаене, ядене, пиене и пак лекция във VarnaLab за увод в Ruby (пак от Кънев – после аз съм обичал да говоря много :) ).

Самата конференция беше много добра. Започнахме с 20тина минути закъснение (Радо закъсня, трудно ми е да му го простя, щото е спал повече от мен), но всичко си работеше и с много усилия успяхме горе-долу да спазим половината график. Имаше 80-100 човека (очакванията на всички бяха за 2-3 пъти по-малко), съответно има сериозен шанс това да стане редовно ежегодно събитие.

От лекциите си спомням следното:

Радо направи много хубава лекция за как добре да пишем и ремонтираме код;
Стефан (Кънев) изнесе стандартния си вид представление/лекция (имаме голям късмет, че не е религиозен лидер), която по броя slide-ове и информация в тях трябваше да е около час и половина, а той имаше по програма половин час;
Митьо (Димитър Димитров) говори за Ruby on Rails, като за разлика от Кънев имаше slide-ове и информация за 3 часа;
Андрей Радев показа “Как да превземем света с vim” и надмина показаното от Стефан в четвъртък. Накрая обясняваше как човек може да си направи с vim не само собствен lightsaber, но и lightsaber chainsaw, или дори lightsaber chainsaw nunchaku (с което съм напълно съгласен). Демонстрацията му в рамките на 10 минути на няколкото модула/скрипта, които той сам си е писал мисля, че напълно шашна публиката;
Калин Чернев говори за hackerspace-ове;
Аз мрънках от програмисти (презентацията ми в pdf или odp), вероятно ще разпиша цялата си лекция като blog post в идните дни;
И Христо Дешев разказа за полифазното спане, или как да спим по-малко, като спим да речем по половин час на всеки 4 или различни други варианти.
(имаше още две лекции, но бях доста отнесен/зает, за да ги слушам)

Важен feature на лекцията беше, че на обяд имаше безплатна пица за всички присъстващи (и понеже аз стоях при техниката, Митьо ме спаси от гладна смърт, като ми донесе няколко парчета).
(изобщо във Варна живях основно на пици, те са перфектната храна)

Последва after-party в някаква пицария – хапнахме, пийнахме, говорихме, говорихме, говорихме на хиляди теми, след което аз се прибрах да спя, и след няколко часа трябва да се метна на автобуса и да се прибера в София.

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

(Имам примерен отрязък от звука, в който Кънев представя лектора и после лектора говори известно време, ако някой има идеи какво би помогнало като филтри и т.н., моля да каже)

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

(а в моя pipeline вече са два post-а – как се прави streaming/запис/encoding/рязане, и онова мрънкане за програмистите, някой ден ще ги напиша)

2012-08-05 VarnaConf

Sunday, August 5th, 2012

На 11.08 (събота) във Варна, във Варненският Свободен Университет ще се проведе VarnaConf – еднодневна конференция за developer-и. Аз ще имам една кратка лекция там (основно мрънкане), но се очертава да има по-интересни неща, програмата и лекторите могат да се видят на сайта.

Ще се stream-ва (освен ако нещо тотално не се сбози) на http://stream.initlab.org:8787/vc.ts, където в момента върви на loop едно клипче с програмата и “Too Tight” на Falik за фон. Мисля, че с vlc най-добре ще може да се гледа, но до събота има много време всички да тестват и да кажат дали имат някакви проблеми (и да си ги решат). Ако има желаещи, в София в initLab може да се организира прожекция – има всичко нужно за целта, само някой трябва сутринта да отвори.
(може като Радо се събуди по някое време да предложи по-хубав клип и някаква друга creative commons музика)

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

Update: Оправих url-то на stream-а, бях пропуснал порта (8787).