Кой е Джон Голт?

Много ме изненада, че търсене в гугъл за „Кой е Джон Голт“ не връща никакви резултати. И ми се стори много забавно. Съответно, този кратък пост се опитва да реши проблема.

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

Ако не разбрахте в кой ред на мисли или смисълът на този пост ви се губи, просто го подминете без коментар.

The Pragmatic Programmer

Най-накрая прочетох една важна и основна книга на софтуерния занаятчия: The Pragmatic Programmer: From Journeyman to Master. Страхотна е. Фокусът е върху практическите (прагматичните) и полезни неща, като всяка идея е много добре аргументирана и представена. Аз научих много неща от нея:

  • как да си опростя процеса
  • за какво да внимавам като правя refactoring
  • как да си организирам кода, че да може да се тества особено лесно
  • някои особено хитри начини да държа проекта добре документиран

Тази книга не ви учи как да пишете код. Учи ви как да разработвате софтуер. И то по особено приятен и прагматичен начин.

Най-мъдрите неща в нея са разпръснати в 70 съвета из целия текст. Първият е „Care about your craft“, а последния – „Sign your work“. Философията на човека, който наистина обича да прави софтуер, а не просто да отбива номера от 9 до 5. Ако сте сред тези хора, книгата определено ще ви хареса. Ако не – как въобще попаднахте на този блог? 🙂

Mushroom management

Това IT-то просто не си е работа. Зарязвайте тази лудост и хващайте някоя по-нормална и здравомислеща професия – например водопроводчик. Ще ви е доста по-добре и няма да сте заобиколени с толкова идиотия и лудост.

Свежа илюстрация на горните редове е „термина“ mushroom management. Отнася се за IT отдела. Може да го интерпретирате така:

Keep them in the dark and throw shit at them. And they grow.

Сиреч: събирате група програмисти (гъбите), слагате ги на тъмно (малка влажна стая с щори и стар хардуер) и започвате да хвърляте „тор“ по тях (проблеми, поддръжка, PHP). И те се развиват. Правят нов продукт, поддържат стария, въобще – докарват ви пари.

Не сме хора ние програмистите и туйто.

<button name=“commit“>

Най-честата грешка, която правя в HTML:

<form>
    ……
    <button name="submit" type="submit">Submit</button>
</form>

Разликата е много коварна. Понеже бутона се намира във форма, той е достъпен в JavaScript като form.submit. Което е неприятно, понеже скрива функцията form.submit() и кара повечето ви скриптове да престават да работят по мистериозни причини. Мъдри са хората от Rails като техния submit_tag по подразбиране генерира име commit. Не просто избягват проблема автоматично, но и тренират навик, с който да не попадате в него. В резултат, когато не пиша на Rails винаги си наименовам submit бутоните по този начин. И съм много доволен от това.

Днес…

…имах странен сън. Една баба, не много различна от тази ходи нанякъде. Поглед в земята, почти затворени очи, бавно и мудно. И ей така, от никъде, някой хвърля молив (или може би беше пръчка?), който се забива право в едното око. Погледът ѝ (в другото) за момент се избистря, та завърта глава „към камерата“ и казва ясно „Python е полипарадигмален език за програмиране“. След което прави леко завъртане надясно и пада на земята като бутнат стол. Без никакво сгъване в коленете.

След това се събудих.

Май имам нужда от почивка. Голяма почивка.

Програмиране и шофиране

В книжката си за екстремно програмиране, Кент Бек прави интересна аналогия между разработката на софтуер и шофирането. Тя касае спецификациите. Големият мит на софтуерното разработване гласи, че първо клиента пише спецификация, след това програмистите правят дизайн и накрая го кодят. Поставя се една посока и след това се върви по нея. Кент Бек твърди, че по-скоро прилича на шофирането – дори на най-правото шосе, ако насочите колата право напред и пуснете волана, след най-много минута-две ще сте извън пътя. След като изберат посоката, шофьорите постоянно налагат малки корекции за да не напуснат платното. Така правят и софтуерните разработчици – в процеса на разработка постоянно да правят малки корекции по изискванията, кода и дизайна. Хрумна ми как тази метафора може да бъде доразвита. Continue reading