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

Интерфейси и абстрактни класове (в Java)

Често ми се случва да се чудя дали да ползвам абстрактен клас или интерфейс докато пиша на Java. И двете идват от леко остарелия ООП апарат на C++, в който наследяването се ползва предимно за две неща – предотвратяване на повторение на код и абстракция. Та, хрумна ми една проста схемичка как да определя кога какво да ползвам.

Continue reading

Uniform Access Principle

Днес прочетох за нещо, наречено Meyer’s Uniform Access Principle. Това е един много интересен прицип касаещ ООП езиците. Гласи горе-долу следното:

Атрибутите на един обект трябва да се достъпват чрез нотация, която не позволява да се различи дали те са имплементирани чрез запис или чрез изчисление.

Иначе казано, line.length не трябва да издава дали става въпрос за поле или метод, изчисляващ разстоянието между двата края. Това е много хубава идея, понеже промотира любимите ми думички – абстракция и енкапсулация. Та, замислих се доколко това важи в езиците, които ползвам.

Continue reading