Assert-овете трябва да се изключват за версията в продукция.

Не, не, не. Три пъти по три не. Assert-овете не трябва да се изключват за нищо на света. Все едно акробатите да тренират със спасителна мрежа, а на живото представлението да са без нея. Отвъд драматичен ефект друго не постигат. Ако ви сърбят пръстите да изключите assert-ите, значи правите нещо много, много грешно. Не ги ползвате правилно, не ползвате изключенията правилно или не ползвате unit тестовете правилно. Но при всички случаи грешите.

Това бе най-дискутираната тема след часовете по python. Бях много изненадан как почти всички не успяваха да зацепят колко лоша идея е това. Позволете ми да обясня. За целта ще започна с някои основи за функциите и изключенията, след което ще покажа как се навързват assert-ите в цялата схема.

Continue reading →

Често чувам от люде, които уважавам, че design pattern-ите са начини да се решат ограничения в статичните езици. И че няма нужда от тях в динамичните – ruby, python и perl. Че са напълно излишни “ООП глупости”, от които един истински програмист няма нужда. Силно несъгласен съм.

Шаблоните представляват различни начини да си организираш идеите за да решиш някакъв структурен проблем. Вземете например функциите – тези които дефинирате с def в ruby и python и с function в JavaScript и PHP. Те са нещо като design pattern – начин да групираш последователност от инструкции, за да ги използваш на повече от едно място (още за да създадеш абстракция, да скриеш имплементация, да изградиш кохезия и т.н.). Съвсем аналогично е – те представляват подход към проблема, а не “статична рецепта за решаването му”.

Ще се опитам да илюстрирам горното, като покажа как изглеждат няколко шаблона в java и съответо в ruby.

Continue reading →

Има една история (от tdd), че дебъгването Is Evil. Дебъгването като процес на фиксване на бъгове трябва да бъде подменено с писане на тестове, които „доказват“ бъга, и според които го фиксваш. – Из българският пощенски списък за Ruby on Rails

Искам да добавя нещо, макар да съм сигурен, че автора на горното е наясно. Целта на дебъгването е да разбереш как точно работи приложението ти, а не да ти идентифицира бъговете (съответно името му може би е малко грешно). Това за което протестира една част от програмистското население: тъпо e да ползваш дебъгване вместо unit тестове. Например да изпълниш кода в дебъгера след като го напишеш за да се увериш, че работи. Да го зачеркваш дебъгването от картинката по тези причини е като да забраняваш предефинирането на оператори – премахваш един много полезен инструмент, за да “предпазваш от грешки” хората, на които не им се мисли много.

Но обратното също е доста лоша идея – да използваш тестването вместо дебъгване. Последното ти дава подробна информация как работи отделен пасаж от кода, докато тестовете служат да правят системата по-устойчива на промени. Теста ти помага да откриеш че има проблем, докато дебъгването – да намериш някакво решение. Съответно, колкото и подробни и задълбочени тестове да правите, те няма да ви помогнат да намерите off-by-one грешката или мястото, където предавате една променлива вместо друга.

Съответно цитираното ми звучи като стандартния резултат от игра на развален телефон в ИТ бранша. Някой казал „„Това че пускате кода в дебъгера не е достатъчно добър гарант““, друг добавил „„Да, по-добре пишете тестове, вместо да ползвате дебъгера за това““ и преди човек да се осъзнае, вече е широко разпространено мнение в мрежата, че TDD зеалотите отричат дебъгера и съответно или са нещастници и съоветно цялата им философия е тъпа или трябва и ти да почнеш да „отричаш дебъгера“, ако искаш да си част от готината им групичка. Както да го погледнеш, не е на добре.

Ръкописите не горят. – Воланд

Преди две седмици разказвах за адския ми проект. Забеляза се следния феномен – за два месеца мога да възпроизведа кода, който екипа ми написа в продължение на две години. Както и да го погледнеш, не изглежда много рентабилно – хем повече ресурси, хем много повече време. И това не е единственият ми такъв случай. Но как си го обясня? Ако на края на всеки проект откривам, че мога да го напиша драматично по-бързо сам, защо не науча как да правя това от самото начало и скоро да се пенсионирам?

В една от творбите на Михаил Булгаков героят създава ръкопис, който в последствие захвърля в камината. Когато научава това, Воланд му отговаря с горния цитат. Много дълбока мисъл и има прекрасен паралел с програмирането. Continue reading →

Програмистските блогове са за споделяне на опит. И като притежател на такива (блог и опит) ми идe отвътре да споделя малко. Искам да пробвам нещо – ще разкажа подробно за проблем от работата ми и как го решавам. Не мисля да навлизам в технически детайли, а да илюстрирам моя подход. Демек ми е интересно как другите хора от занаята работят и съответно може на тях да им е интересно как аз работя.

Не съм сигурен какво ще излезе, така че при неуспех ще трябва да потърпите (или просто да не четете). Но в случай, че се окаже интересно, хвърлям ръкавицата на няколко от познатите/приятелите ми. Смятам че имат хубави приказки за разказване и поне аз бих ги чел с удоволствие. Номинираните са Петьо, Свилен, Ники и Митьо. Бих добавил и Riznlog, но не познавам пичовете а и едва ли ме четат. Continue reading →

джудо

минимални усилия за максимален резултат; подход, в който се избира най-евтиният (откъм време, усилия и ресурси) път, който би довел до най-голям резултат

кайзен

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

Continue reading →

Над 40 дни от последния пост в блога ми. Ако сте си помислили, че ми се е случило нещо от голямо значение… правилно сте си помислили. Последните пет седмици бях в интензивен период касаещ Адския проект, който търкалям през последните две години. Това включва финалната права за завършване на всичко, истерия покрай deploy, дълга и приятна двуседмична почивка по празниците, пускане на версия 1.0.1 (по-точно 1.0.0.1) и онази досадна поддръжка в първите дни след release, изпълнена единствено със ситни подобрения. Понеже това бе „основният“ ми проект толкова време, той оказа голямо влияние както в професионалното ми развитие, така и в личния ми живот.

Ще ми се да споделя някои от нещата които научих от него. Ако не за друго, за да има къде да ги прочета след време. И ще ги разбия на няколко поста – така хем да не отегчавам малкото хора четящи този блог, хем ще се върна плавно към навика да пиша тук. Continue reading →

I simply cannot resist translating the last post in English. Here it goes.

Take a look at this post by Reg Braithwaithe. It is a short article delving into code writing conventions. This is a topic I have contemplated a lot on and I have a somewhat fascist outlook to it. This link is a great opportunity to share them with you. Continue reading →

Хвърлете един поглед на това. Кратка статийка, която навлиза в детайли за стандартите за писане на код. Това е тема, над която съм размишлявал доста време и имам някои фашистки разбирания. Връзката ми дава страхотен повод да споделя някои впечатления.

Continue reading →

В живота на всички нас ги има онези гадни периоди на депресия и мрак. Докато те траят, през главата ти често минават мисли за алкохол, наркотици и дори самоубийство. Но най-накрая моя такъв период, продължил последните две години и половина, приключи – Eclipse вече не хвърля грешки поради недостиг на памет!

Странно е как може да се занимавам сериозно с професионално програмиране на Java от толкова много време и все пак да допуска такава глупава аматьорска грешка(*). Изключението в заглавието е най-честата причина работната ми среда да забива. Дълго време си мислех, че Java е зъл демон смучещ памет, вместо човешки души и че 2GB са приятен, но недостатъчен лукс. Но когато сложих и третото чипче и Eclipse продължи да гърми с OutOfMemory, без дори да заеме цялата физическа памет, ситуацията започна да ме съмнява. След кратко допитване до познати, открих че следния ред в конфигурацията прави магии:

Цялото това нещо минава и за сървъра на който съм качил нещата. Защо се получава и каква е цялата врътка с това PermGen може да прочетете тук. Аз вече съм един щастлив java developer, който отново си е пуснал всичките добавки към работната среда и не му се е налагало да я рестартира няколко дена. Отново, да се чуди човек как не ми е хрумнало да се поинтересувам защо става така пред последните две години и половина.

(*) Всъщност, в същия ден разбрах, че проекта който търкалям през половината от това време всъщност не ползва connection pool и Hibernate-а смело прави нови връзки за щяло и нещяло. Един от онези редки моменти, за които съм благодарен на човешката (моята) глупост – реших си проблемите с паметта и скоростта за пет минути, без много труд.