пʼятницю, 11 грудня 2009 р.

Нижня межа

Варто провести для себе таку межу, нижче за яку не можна спускатись.. І чітко то усвідомлювати.. Така межа має бути у всьому!

вівторок, 17 листопада 2009 р.

Коктейль для хорошого програміста.

Я хочу написати про три книги, які на мою думку варто прочитати кожному програмісту, хто пише на об'єктно орієнтованих мовах. Ці книги я починав читати юніором, їх заслуга що я перестав ним бути не менша ніж MSDN'у, .NET Reflector'у та іншої технічної літератури, що я перечитав. Рекомендую читати у порядку вказаному у пості.

Досконалий Код. МакконелаСтів Макконелл. Довершений код. Коли читав - майже у кожному розділі зустрічав, що роблю не так, більш того - там описувалось, чому такий код принесе потім проблеми. Саме тоді я почав писати змінні з 5 повних слів у назві☺ (це більше жарт). Після прочитання книги - весь попередній код здавався лайном. Там не написано нічого про техніки програмування - лиш як зробити твій код зрозумілий іншим і тобі через 3 місяці.. А зрозумілий код - легше(дешевше) підтримувати. А якщо звучить слово "дешевше" - ти стаєш цінніший для роботодавця ;)

Рефакторинг. ФаулераМартін Фаулер. Рефакторинг. Книга принесла початкові розуміння про архітектуру класів. Я зрозумів, що саме і як я створюю, і навіщо потрібні прайвет інтернал класи ☺. Після її прочитання - був великий бум рефакторингу мого коду (повторюсь, але знову мій попередній код здавався лайном ☻), а надалі я вже намагався писати так, щоб це не потрібно було рефакторити. Це був крок до дизайну (уявлення що і як може бути) перед початком кодування. Крок до чіткіших методів.. Фактично книга поглибила ті позитивні зміни які приніс "Довершений код". До речі, перші розділи читаються доволі тяжко, так як описано багато пояснень з посилання на патерни про які буде розповідатись далі - не раджу закидати ☺.

Патерни. Банди чотирьохЕріх Гамма, Річард Хелм, Ральф Джонсон, Джон Вліссідес. Паттерни обєктно-орієнтованного проектування. Звісно, я взнав, що деякі підходи, які я використовую - називають паттернами і вони мають круті назви ☺. Але крімтого, мені відкрився світ підходів, про які я навіть не здогадувався і вони здавались спочатку складними - але зрозумівши і застосувавши їх - оцінивши реальні переваги які вони принесли. А саме: спростили структуру коду; розклали чітку відповідальність різних шаматків коду за різну поведінку, зробивши складні речі - простими, гнучким(легко розширяємими) .
Саме тоді код почав виглядати професійним і з'явилось розуміння як можна робити складні речі і не загнутись під багами!
До речі - для кращого запам'ятовування рекомендую після прочитання опису паттерна - уявити власну ситуацію де ти його міг би використати, чи де він використовується у іншому відомому вам програмному забезпеченні.

Звісно - ці книги не зроблять тебе профі - для цього також потрібні суворі технічні знання. Вони лиш нанадуть провайдери твоїх технічних знань на полотно проекту.

понеділок, 16 листопада 2009 р.

5 хв слави.

Минулий тиждень ця весела компанія писала код для стартапів з Microsoft BizSpark Incubation Week for Windows Azure. Це був цікавий досвід - потрібно було за короткий період зрозуміти: що клієнт бажає, що клієнту потрібно і дати вирішення його проблеми - і все це в умовах жорсткого цейтноту і різниці часу у 7 годин ☺. Як видно ми справились не погано, про нас навіть згадали, не тіки згадали але й виклали нашу світлину, на майкрософтівських блогах - тут.

пʼятницю, 13 листопада 2009 р.

Скайп - псевдо невидимість.

Майже всі месенджери мають режим невидимості. І по тому як він працює і скільки багів з ним буває - вказує на нелюбов програмістів до хороших практик і неувагу у дрібницях ☻.
Звертали увагу, що у Скайпі коли ви відправляєте меседж не залогіненому користувачеві (чи коли трабли з мережею) - то напроти недоставленого меседжа з'яляється лоадер (кружечок що "бігає" по колу). А тепер відправте меседж прихованому користувачеві - лоадера немає. Бінго! - Вас викрили пане Невидимка.

пʼятницю, 8 травня 2009 р.

Краса проти надійності.

Часто доводиться ставати перед вибором - перевірка на всі можливі випадки життя vs краса і стрункість коду. Здавалося б усе так просто - ти сам наповнюєш вхідні дані - помилки бути не повинно... та дрібний хробачок гризе.. а ну ти вирішиш розширити функціонал, чи баги фіксатиме інша людина - яка не знає про накладені тобою умовності, чи ти щось випустив?
Додав перевірку на всі випадки життя. Оголена стрункість яка йшла на межі баги зникла.. з'явилось щось інше... дивно, але воно гарне... без стрункості.. краса в надійності...

середу, 22 квітня 2009 р.

Хто найчастіш читає мій блог?

Я сам :), чому так? самозакоханість тут зовсім не причому, відповідь на поверхні - пам'ять не гумова, записую цікаві для себе речі, а в пам'яті залишаються лиш ідеї - деталі втрачаються. Це хороші "схеми", над якими я мізкував, аналізував сильні/слабкі сторони.. Потрібно лиш імплементувати де потрібно.. а у маленькому блозі шукати набагато зручніш ніж у широкому неті ;).

PS: Блогом у даному пості я називаю http://rredcat.blogspot.com/