Поглед назад III: Швеция

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

Такава беше днешната дата преди три години. Тогава се преместих в Стокхолм. Станах, събрах си багажа, разходих се из слънчева София и следобед хванах самолет към една по-студена държава. Не знаех езика. Не знаех дали отивам за година или се местя за неопределено дълго. Не знаех, че ще ме промени толкова. Continue reading →

Как работя: Pomodoro Technique

Работните навици са ми проблем. Преди не бяха – нямах нужда от структура в работата. Стигаше ми ясен проблем и ясен краен срок. Сядах пред компютъра и се хвърлях върху него, докато го реша. Обикновено в срок. Напоследък намирам това за по-трудно. Не знам дали загубвам способността да се фокусирам или е просто старческо слабоумие, но работата изисква концентрация, която понякога ми липсва. Съответно съм си изработил система, която да се бори с това. Ще ви разкажа за нея.

Добрите дни в текущата ми работа се делят на два вида – тези в които правя pair programming и тези, в които работя сам. Ще говоря за вторите. Continue reading →

<CTRL-[HWUM]>

Enter и Backspace са ми едни от най-трудните клавиши за натискане. Докато се опитвам да минимизирам употребата на втория, първия е задължителен. Натискам с извиване на китката (без да си местя ръката) за да не изтърва home row-а. Това не е никак здравословно – проблемите ми с ръцете започнаха когато правих това на по-голяма клавиатура.

От известно време нося накитници, които ми държат китките изправени и не ми позволяват това движение. Така се налага да местя цялата ръка. Освен че е досадно, така да изпускам home row-а. За щастие, в повечето среди има решение. Continue reading →

Кратък урок по история

Често има любопитни имена в компютърните неща. Може би знаете vi. Там, например, има следната команда:

s/foo/bar/

Това замества първото срещане на foo с bar в текущия ред. Съществува и по-обща версия – g:

g/something/s/foo/bar/

Това замества foo с bar на редовете, които съдържат something. Демек, g приема шаблон и команда, която прилага на всички редове, в които шаблона съвпада. Ето как може да изтриете редовете, съдържащи something:

g/something/d

Тези неща идват от един още по-архаичен текстов редактор – ed. Там има команда p, извеждаща всички редове, в които шаблона съвпада. Но все пак, ето как да изведете всички редове от текущия файл, съдържащи something:

g/something/p

Впрочем, something е регулярен израз – „regular expression“, често съкращавано като „re“. Общия запис на командата е:

g/re/p

И ето откъде идва името на една от най-използваните shell команди в POSIX света.

Забавно, а?

Структури vs. обекти

Има нещо некомфортно в тезата „всичко е обект“. Ето едно любопитно разсъждение, на което попаднах наскоро (в [Clean Code](http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882), която препоръчвам):

Обектите скриват данните си зад абстракции и предлагат функции, които работят с тях. Структурите предлагат директен достъп до данните и нямат смислени функции. На практика са противоположности.

Изтъркан пример в Ruby:

Continue reading →

TDD №1: Мързел

Това е първият от цикъл постове за [test-driven development и автоматизирано тестване](http://skanev.com/2010/04/30/webtech-tdd-follow-up/).

Има ред причини да пишем тестове – по-лесна поддръжка, документация, дори по-добър сън. Несъмнено сте чували повечето. Но ето една по-рядка – мързел.

Continue reading →

Follow-up на TDD от WebTech

На [P2P](http://wtconferences.com/) говорих за [test-driven development](http://skanev.com/2010/04/25/tdd-webtech/). Бях изненадан от резултата. Предполагах, че ще ме замерят с домати задето предлагам странни – дори радикални – идеи. Вместо това слушателите бяха любопитни. Имаше много въпроси. Мога само да се радвам, че темата ми породи такъв интерес. И да направя малък експеримент.

Continue reading →

Разликата

Научавате за нова практика. Design patterns, mock обекти, Selenium или дори функционален език за програмиране. Около нея се вдига доста шум. Ред опитни хора твърдят, че е добра. Прекарвате няколко дни – дори седмица – в експерименти. Евентуално откривате, че не ви дава обещаната отплата.

Тук може да направите два извода. Единият е тази практика не работи. Другият е прилагам я грешно. Почти без изключения мога да категоризирам всичките си познати колеги в един от двата лагера. Почти без изключения, тези във втория са по-добрите програмисти. В крайна сметка, кое е по-вероятно? Опитните занаятчии в областта да грешат или да прилагате нещо, което едва сте разбрали, грешно? Докато първото се случва понякога, опита ми показва, че второто по-често е вярното.

За това търся проблема първо в себе си. В крайна сметка, [„select“ Isn’t Broken](http://pragprog.com/the-pragmatic-programmer/extracts/tips).

Test-Driven Development на WebTech

Линкове от презентация ми на [WebTech](http://wtconferences.com/):

  • [Слайдове](http://www.slideshare.net/skanev/testdriven-development-refactoring) – само 139
  • [Видеото](http://content.screencast.com/users/unclebobmartin/folders/Default/media/71c7a27d-6fb7-4638-89cc-51b8b37e6c27/PrimeFactorsKata.mov), което исках да пусна
  • [Software Craftsmanship Bulgaria](http://groups.google.com/group/software-craftsmanship-bulgaria) – пощенския списък, който ви препоръчвам

Книги

  • [Test-Driven Development by Example](http://www.amazon.com/dp/0321146530/?tag=hashemian-20) – въведение в TDD
  • [The RSpec Book](http://www.pragprog.com/titles/achbd/the-rspec-book) – нещата в Ruby светът
  • [xUnit Test Patterns](http://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054) – мъдрости за как да пишем тестове, които да помагат, а да не пречат

Надявам се да ви е харесало. Коментари са добре дошли.