Искам да направя серия от малки презентации в initLab за такива езици. Очаквайте Io, Scheme, Haskell, J, Prolog и прочее. Първият ще е Smalltalk. Датата ще бъде 26ти януари. Часът ще бъде 19:00.

Smalltalk е първият обектно-ориентиран език за програмиране. Всъщност, вторият, но само технически погледнато. Всичко, което възприемаме като ООП идва по един или друг начин от него. Разбира се, повечето идеи са видоизменени до непознаваемост (в C++, например). Няколко известни имена от Addison-Wesley са (бивши) Smalltalk програмисти – Kent Beck, Ward Cunningham, Martin Folwer. В днешно време не е много популярен, но определено има какво да ни научи.

Ето няколко любопитни неща, които ще грабнат интереса ви:

• Кодът не се пази в текстови файлове.
• Виртуалната машина и работната среда са силно интегрирани. Можете да редактирате кода на работната среда от самата работна среда. Докато работите в нея.
• Няма синтаксис за if – имплементиран е в стандартната библиотека.
• Design Pattern-ите в GoF изглеждат малко странни в C++ и Java. В Smalltalk изглеждат учудващо на място.
• Динамично типизиран, но въпреки това има IDE и debugger, сравними с тези за Java.
• Някои странни имена в Ruby (collect, inject, initialize) идват от Smalltalk.
• Изключително прост синтаксис, сравним с този на LISP.

Ако това ви е грабнало вниманието, може да дойдете и да гледате на 26 януари, от 19:00 в initLab. Входът, разбира се, е безплатен.

Този път събитието ще се проведе в офиса на Software Society. Може да намерите повече информация на сайта им.

Идеята не е да решите проблема. Идеята е да обмените умения и да затвърдите фундаментални познания. Това е адски добър начин да научите test-driven development или някой друг трик с текстовия редактор/шела.

Чух за идеята миналата година на NordicRuby, но чак през април се престраших да я пробвам. Организирах малко събитие в initLab, в което поканих само познати. Събрахме се 6 човека и направихме 5 сесии. Писахме на C#, JavaScript, Ruby, Python и дори Scala. Бяхме много доволни. Всеки си тръгна научил нещо.

Искам да организирам друг и този път смятам да поканя всички, които искат да дойдат. Събитието ще се проведе от 9:00 на 9 юли, събота в initLab. Ако искате да участвате сте добре дошли. Не е нужно да сте опитни в TDD — просто носете компютър и добро настроение.

Ето как ще протече:

Ще направим нещата „по книга“ – времето ще е 45 минути, проблема ще е Game of Life, ще трием кода на края на сесиите и ще ползваме test-driven development.

Всяка двойка ще се уговаря помежду си на какъв език да пише. Със сигурност ще си намерите партньори за C#, Java, JavaScript, PHP, Python и Ruby. Вероятно ще има всякакви екзотики.

След всяка сесия ще събираме всички и ще обсъждаме как е минало. Ретроспекциите отнемат към 15 минути, след което ще продължаваме с друга двойка.

За да компенсирам ранното ставане, ще има закуска и кафе в initLab. Ако имате по-специални изисквания (не ядете месо или сте веган), кажете и ще се погрижа. След третата сесия ще отидем в близко заведение да обядваме. След това се връщаме и продължаваме. Реалистично погледнато, ще направим 6 сесии и ще приключим към 17:00.

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

Събитието ще е напълно безплатно (включително закуската).

Не нужно да сте опитни в TDD. Въпреки това, имаме следните изисквания към всеки участник:

• Носете компютър
• Научете правилата на Game of Life. Ако имате възможност, пробвайте да няколко шаблона.
• Изберете си езици, на които ще пишете и научете поне един тестов framework във всеки. Важно е да познавате инструментите и да можете бързо да пускате тестове.
• Задължително подкарайте празен проект за всяка двойка (език, testing framework), с които смятате да работите на вашия компютър. Не искате да прекарате голяма част от сесията в подкарване на проект.

Ако идвате, моля елате в 9:00 и останете за целия ден. Ако ще идвате, пишете ми на stefan точка kanev маймунка гмейл точка ком. Имам нужда да знам колко човека ще присъстват. Моля пишете само ако сте сигурни. Ако ви изникне нещо в последния момент, ще се радвам да ме предупредите.

Ако имате някакви въпроси, ползвайте формата за коментари, пишете в пощенския списък Software Craftsmanship Bulgaria или ми пратете писмо. Може да погледнете кратките отзиви от предишния code retreat или да намерите повече информация на coderetreat.com.

Ще се радвам да ви видя на 9ти!

Първото събиране ще е във вторник, 1ви март, от 19:00 в зала 200. Ще се радвам да ви видя там.

• Как блогът ми ме направи по-добър професионалист на WordCamp BG
• Защо MongoDB? от OpenFest

Слайдовете са на обичайното място.

През 2011 ще се опитам да се представя още по-добре.

Pragmatic Thinking and Learning е книга, която дава ред начини да станем по-добри, без да инвестираме директно в програмиране. Една от основните идеи е, че ученето е умение, и като такова, можем да ставаме по-добри в него. Предлага разнообразни подходи за това.

В книгата има два вида информация — „теория“ и „практика“. „Теорията“ разказва как мозъкът ни работи. Говори за неща като модела на Дрейфус за усвояване на умения или за cognitive biases. „Практиката“ са ред неща, които може да направите, за да подобрите ефективността си. Варират от съвети за боравене с e-mail, през подход за четене на книги, до методи за водене на бележки. Не претендира за изчерпателност или научна достоверност. По-скоро е на принципа „това работи за мен; пробвайте го — може да сработи и за вас“.

Книгата не е методична програма. Вместо това, Анди Хънт разказва много неща, без да навлиза в детайли. Разлистих я преди да започна този текст и се изненадах колко много съм забравил. Идеите са доста и ако искате да приложите всичките, ще се видите в зор.

От друга страна, нещата които си спомням ми влизат в ежедневна употреба. От нея разбрах за mind mapping. Тя ми даде идеята да ходя нявсякъде с тефтерче (Field Notes или Moleskine), в което да водя бележки. Части от процеса ми са вдъхновени от нея.

Горещо ви я препоръчвам. Книгата е интересно четиво, дори и да не имплементирате нито един от съветите.

За първи път правех pair programming през 2005. Това е страхотен начин на работа и горещо ви го препоръчвам. Има ред предизвикателства — да убедите мениджмънта, да се сработите с колегите и дори да си промените навиците (например никакъв IM). Ако се справите с това, резултати се виждат бързо.

Не целя да ви продам идеята или дори да ви обясня какво представлява. Искам само да разкажа защо ми харесва да работя така:

По-високо качество

Работата по двойки подобрява качеството. Това става по няколко начина. Първо, работи срещу мързела — ако ме домързи да напиша тест или да направя даден код ясен, човекът до мен ще ме сръчка. Второ, кодът се гледа от друг чифт очи — партньорът забелязва дефекти и предлага подобрения. Това е като code review в реално време.

Трето, подобрява консистентността на проекта. Всеки се ръководи от правила как да пише, които обикновено са неявни („така ми харесва повече“). Когато имаме разминаване, разговорът първо ги прави явни („аз предпочитам това, защото Х, ти онова, защото Y“), след което ги синтезира („нека в този проект да правим Z“). Резултатът — еднакъв подход.

Възможност за учене

Научавам малки и полезни трикове — „горещи клавиши“ на работната среда, нова shell команда, непознат метод или хитър номер във Vim. Запомням по-лесно, понеже ги виждам в контекст. Мога да питам, ако нещо е неясно. Така се научих на ред неща, сред които git, jQuery и Eclipse.

Ако съм нов в проекта, това е добър начин да навляза в него. Когато имам по-запознат програмист зад гърба си, мога да задавам въпроси или смело да правя промени. Дори да познавам проекта, така научам причините за взети решения по дизайна.

Има и по-тънък момент — сблъсквам с друг начин на мислене. Мога да наблюдавам подхода на партньора, да се опитам да го усвоя и в последствие да разширя собствения си с идеи от неговия. Не съм открил по-ефективен начин да ставам по-добър.

Социална дейност

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

Pair programming-а е ефективен начин да се почувствам част от екипа. Усещам, че преследваме обща цел заедно. Дава ми чувство за принадлежност. Мога да взаимодействам двупосочно с всички чрез човека, с когото работя в момента — ще ми предаде уроците от другите и ще предаде моите на тях.

И още — честият pair programming създава връзка между хората. Това сплотява екипа. Поглеждайки назад, чувствах се много по-добре в екипите, в които го практикувахме. Някои от хората ми липсват.

Обща култура

Един XP екип има нужда от обща култура. За да има колективната собственост, стилът на различните членове трябва да е подобен (или дори идентичен). Трябва да могат независимо да достигат до еднакви или сходни решения на проблемите. В идеалния случай, когато видя парче код, трябва да не мога да позная дали аз съм го писал.

Pair programming е необходим за такава култура. От една страна, той подпомага създаването ѝ — това става всеки път, когато двама стигнат до консенсус и изградят „правило“ за вбъдеще. Така тя се развива естествено и еволюционно. От друга, това е ефективен начин тя да се разпространява и утвърждава. След известно време, всеки от екипа може да каже „ние правим така“, „ние подхождаме така“ и „ние мислим така“. Дори извън екипа да прави, подхожда и мисли по различен начин.

Разговарях с един приятел. Бях прекарал последните няколко години в усилено писане на C и C++ (в училище). Занимавах се с OpenGL и линейна алгебра. Той пък бе открил Java. Водехме дълъг разговор кое е по-добро — C++ или Java. Спомням си как ми каза „Java има много добър garbage collector“, на което отговорих с „Е какво, не можеш ли да си управляваш паметта сам?“. Той отвърна „Мога, ама защо да се занимавам?“. Бях изненадан. Защо не разбираше, че garbage collector-а е излишен? Всеки адекватен програмист може да си управлява паметта. Пък и несъмнено е по-бързо. Не успя да ме убеди.

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

Чудя се — за какво друго реагирам предубедено? Колко идеи изхвърлям, защото са неприложими в текущия контекст? Колко, защото си мисля, че са неприложими? Към колко съм предубеден, защото съм ги чул от лоши програмисти? И колко игнорирам по навик?

Твърде често го виждам в колеги. Няма значение дали става въпрос за библиотека, метод на работа или език за програмиране. Няма значение дали говорите за Java, Ruby или PHP. Реакцията към новото и непознато е скептицизъм.

Не знам какво го поражда. Твърде много неща за учене? Обемът на информацията е страшен? Чувстваш се глупав, ако не успееш да научиш нещо? Изглежда непрактично да се опитваш да разбере всичко? Хората, които учат много неща не вършат никаква работа?

Знам друго — този начин на мислене е вреден. Като програмист не мога да си позволя да спра да уча. Започна ли да отхвърлям новото, след пет години ще съм безполезен. Още повече — ако съм негативен, изпускам ред възможности да подобря уменията си.

Затова се опитвам да поддържам позитивна нагласа към новите неща. Усетя ли, че съм скептичен към нещо непознато, спирам и се замислям. Казвам си, че все още нямам право на мнение. След това вниквам в него. Не е достатъчно да прочета блог пост или книга — трябва да си поиграя, да го видя в различни контексти и да съм преспал над него. И чак тогава решавам какво да мисля.

В крайна сметка, нещата не са абсолютни — едно нещо не е изцяло добро или изцяло лошо. Обикновено една технология има предимства и недостатъци. Работи добре в един контекст и лошо в друг. Части от нея са изработени добре, а от други има какво да се иска. Картинката не е черно-бяла. И ако се вгледам в нея внимателно, имам възможност да науча нещо ново. Или да окача нов инструмент на колана си.

А понякога технологията/идеята е загуба на време. Не може всяка прочетена книга да си заслужава. И това е ОК.

Доналд Кнут е несъгласен (из Coders at Work):

But that’s not the way he [Dijkstra] learned either. He said a lot of really great things and inspirational things, but he’s not always right. Neither am I, but my take on it is this: Take a scientist in any field. The scientist gets older and says, „Oh, yes, some of the things that I’ve been doing have a really great payoff and other things, I’m not using anymore. I’m not going to have my students waste time on the stuff that doesn’t make giant steps. I’m not going to talk about low-level stuff at all. These theoretical concepts are really so powerful — that’s the whole story. Forget about how I got to this point.“

I think that’s a fundamental error made by scientists in every field. They don’t realize that when you’re learning something you’ve got to see something at all levels. You’ve got to see the floor before you build the ceiling. That all goes into the brain and gets shoved down to the point where the older people forget that they needed it.

Това е често срещана история. Протича така:

Човек хваща нещо ново, непознато и нетривиално (например програмиране). Няма опит, не познава скритите мотики и прави тон грешки, очевидни за експерта (например спагети с goto). Още по-лошо, дори не ги осъзнава. Опитният наблюдател (например Дейкстра) се хваща за главата и отсича, че начинащите трябва да се пазят от „опасните“ инструменти (например goto). Впрочем, направо да се забранят. И разбира се, стабилна теоритична подготовка.

Но това не е начина, по който ескперта (например Дейкстра) се е научил.

Което ме навежда на размисли за Design Pattern-и. Няколко познати са ми казвали, че те са опасни, „защото n00b-овете могат лесно да се застрелят с тях“ или „защото им дава нещо, зад което да се крият“. Трудни са, overengineering се прави твърде лесно и ако човек стане pattern happy прави проекта неспасяем.

Хубаво, ама не съм съгласен. По две причини.

Първо, глупакът ще намери начин да се нарани с всякакъв инстумент. Тези доводи могат да се приложат върху всичко. Например автоматизирания refactoring е опасен, понеже прави писането на смотан код лесно. Или тестването е лошо, понеже прави промяната на код времеемка (трябва да променяш и теста). Дори copy/paste е зло, понеже позволява на хората да дублират код по елементарен начин. Виждал съм достатъчно хора, които казват, че /XP|agile|Scrum|TDD|pair programming|collective ownership|refactoring/ е тъпо, понеже са ги виждали приложени тъпо.

А това е жалко. По този начин изхвърляме бебето с мръсната вода. В първата си работа заварих странна форма на XP. Бе неефективна, неразбрана и правеше нещата по глупав начин. Всички я мразеха. Ако се бях повлиял от това, сега щях да твърдя, че XP е тъпо. Но вместо това прочетох книгата и започнах да я прилагам адекватно. И това ме направи порядък по-добър програмист.

„Пазете хората от мощните инструменти, защото могат да си отрежат нещо“ е лоша философия. Това е един от големите проблеми на Java. Езикът е правен така, че абсолютен идиот да не може да се простреля в крака. Предполагам, че това е хубаво за образователни цели. Но за по-сложни проблеми е ограничаващо. Липсата на ред неща (например closures или предефиниране на оператори) предпазва лошите програмисти от глупави грешки, но вързва ръцете на добрите. Не съм съгласен да плащам тази цена.

Второ, аз разбрах ООП-то с Design Patterns. Преди това, за мен то се изчерпваше със C++ и наследяване. От тази книга научих много. Разглеждах pattern-ите внимателно. Търсех принципите, от които авторите са се ръководили. Размишлявах подробно на всяка непозната концепция, като „композиция“, „индиректност“ или „интерфейс“. Четох внимателно. Не ме научи на 27 шаблона, които да прилагам. Научи ме на ценностна система и начин на мислене, с които Ерих Гама и компания са стигнали до тях. Бе безценно.

Учудващо, въпреки рисковата ми група (C++ бе единственият ми ОО език), не изцвъках 17 pattern-а за две седмици. Вместо това започнах да правя по-добър дизайн, защото вече имах ценности и рамки, в които да мисля. Започнаха да ми идват по-добри идеи и да правя по-малко грешки. Цялостно, станах по-добър.

Не мисля, че съм изключението. Сигурно ще кажете „да, но ти си адекватен програмист и затова не си се окепазил“. Хубаво, съгласен съм. Но ако не бях адекватен програмист, можеше да се омажа с всичко. Можех да прочета Кнут и да напълня кода си с AVL дървета, двоични търсения и алгоритми за сортиране. Или, не дай си боже, можеше да прочета Applying UML and Patterns и да почна да строя системи с 90 слоя, задвижвани от XML. Ако човек е неадекватен, ще се омаже и с най-простия инструмент. Или ще го издигне в религия.

И да, направих грешки. Несъмнено съм overdesign-вал. Не съм стигал до крайности, но е имало случаи, в които съм могъл да мина по-просто. Месец по-късно се е налагало да поддържам и съм си вземал поуката. Човек се учи от грешките си. И ако грешките са малки и могат да се допускат контролирано, това е безценен опит.

Така че, моят съвет е: прочетете Design Patterns внимателно. Вникнете в нея. Дръжте я близо до леглото си. Прилагайте идеите в нея. Може да научите много и да станете по-добри. Ще ви даде полезни инструменти.

А ако изпаднете в неизлечима архитектурна астронавтика и Hello world-а ви изглежда така, може би трябва преквалифицирате. Старата мъдрост гласи, че ако имате единствено чук, всичко изглежда като пирон. Това е лоша нагласа за един програмист. Също като тази, в която изхвърляте идеи само защото са опасни в чуждите ръце.

Както писах по-рано, говорих за MongoDB. Качил съм слайдове в SlideShare. Дори не се опитах да правя снимки тази година — Ники и без това се е справил в порядък по-добре, отколкото аз бих могъл.

Ето какво ми направи впечатление:

Радо направи супер интересна презентация за jQuery. Започна с един доволно намазан widget и постепенно го рефакторира до нещо модулно и приятно. Научих полезни неща. Горещо препоръчвам да разгледате презентацията му и кодът към нея.

Дончо направи презентация за open source и Microsoft. Разбира се, част от публиката му се нахвърли. Две неща ми направиха впечатление. Първо, справи се блестящо с хейта. Второ, някои коментари на хора от публиката бяха абсурдни. Чудя се, нужно ли бе да бъдем толкова дребнави и заядливи? Не може ли да се държим като зрели хора с някакви ценности (отворен код), а не като банда хейтъри, които да скачат на всичко, що не е GNU/Linux/BSD?

Петьо и Христо говориха интересни неща, както винаги. Основната мисъл, която измъкнах от тях бе: кодът ви трябва да се чете от другите във вашата организация. Не мога да съм по-съгласен. Учудих се колко много хора не знаят какво е GitHub. Ако нямате акаунт, спрете веднага да четете и се регистрирайте. Блогът ми ще почака.

Веселин говори интересни неща за NoSQL . Беше ми забавно да науча нещо за тези, с които не съм си играл. Получи се хубаво, понеже говорих след него и презентациите ни не се пресичаха особено. От друга страна, изказахме една-две противоположни тези, но това са дребни кахъри.

Божидар направо ме разби. Презентация му ми бе по-смешна от моята. За нещастие, нямаше достатъчно време да каже всичко, което искаше. Нещата не бяха нови за мен — В Scala и Clojure съм убеден отдавна, докато в Groovy — разубеден отдавна. Въпреки това се размазах.

И си купих 18 книги от O’Reilly.