Кога да търсим нова професия?

Събудих се със сравнително добра идея как да помогна на толкова много объркани хора в избора им на кариера. Позанимавали са се малко с програмиране, учили са малко в университета, поработили са няколко месеца. Дали това е правилни житейски път? Как да разберем?

Ето класически проблем, който илюстрира много. Искаме да изпратим писмо до всички активни потребители, че системата няма да работи през уикенда. Едно „класическо“ решение на Ruby. Умишлено написано в не-ruby стил.

Continue reading

Внимание към детайла

Любимата ми мантра. Трябва да сме внимателни към детайлите. За всичко и навсякъде (или поне почти). Например днескашното xkcd. Смешно е отвсякъде, макар че шегата може да убегне на някои хора. И е смешно на много нива. Например, забележете нотираната музика. Може би си мислите, че са „просто някакви ноти там“. Но не е така – едва ли автора щеше да си даде труда да нотира в си бемол минор, ако нямаше нещо конкретно предвид. Може ли да е сетите какво? Не? Ами, ето ви цялата песен.

До всички архитекти

Имам дълъг TODO списък за какво искам да направя в живота си. Една от точките е да притежавам огромно жилище, проектирано от съвременния вариант на Хауард Роарк. Но определено ще трябва да почака, докато не забогатея за да си го позволя. Дотогова се примирявам с живеене където има, като въобще не ми пречи да сменям местата в които оперирам сравниелно често (вече загубих бройката на колко места съм живял). Но настоящата ми щаб-квартира страда от един много неприятен дизайнерски проблем. Така че ако познавате някой архитект или бъдещ такъв, моля предупредете го не пада в този подъл капан. Continue reading

Интересно програмиране

Програмирането не ми е интересно.

Чувал съм горните думи редица пъти. Сред всякакви мои познати – ученици, биолози, музиканти, техническа поддръжка и дори програмисти. Докато смятам, че последните трябва да се преквалифицират във водопроводчици, то думите на първите леко ме учудват. Пръв ще кажа, че програмирането изобщо не е за всеки, но понякога ми е трудно да разбера защо на хората не им е интересно. Continue reading

Грешки, изключения и assert-ове

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

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

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

Continue reading

Ja, må den leva!

Честит рожден ден! На блога ми. Вече се навърши цяла година, откакто започнах да бутам начинанието. И тъй като това е един хубав крайпътен камък, ще си позволя да ангажирам вниманието ви с няколко думи за него. Continue reading

3 design pattern-а в ruby

Често чувам от люде, които уважавам, че 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 зеалотите отричат дебъгера и съответно или са нещастници и съоветно цялата им философия е тъпа или трябва и ти да почнеш да „отричаш дебъгера“, ако искаш да си част от готината им групичка. Както да го погледнеш, не е на добре.

ICQ и UTF8: Не бъдете индианци

Добре бе, мама му стара. Програмисти сте. Знаете какво е UTF8. Знаете че ми позволява да смесвам български, немски (Grüße), японски (松本行弘), норвежки (færøysk) и иврит (יהושע) в един текст. Разбирате, защо е тесла да има много различни кодировки и какви пречки поставя това пред вас като програмисти и пред повечето хора като потребители. Ако имате малко акъл в главата, силно ви се иска целия свят да ползва една кодировка.

Мо’е ли да ми обясните, тогава, защо не мо’ете си настроите ICQ-то да работи с UTF8? За първи път ли виждате компютър? Не схващате каква е разликата между ляв и десен бутон на мишката ли? Тях мудерни тихнологии са твърди трудни и ни мой са оправите?

Моля ви, не бъдете индианци. Вземете и си оправете проклетите клиенти така, че да ползват UTF8. Помогнете на вашите дружки и колежки. Ако клиента ви не може, просто си намерете друг. Както направихте преди време с Internet Explorer и минахте на Firefox.

А докато направите това, ако ви трябвам ме търсете на GTalk.