IDE...less

В огромна част от случаите готовите IDE-та са кофти идея. Ако човек иска да пише на един единствен език цял живот и да не напуска IDE-то създадено да обслужва тоя език, няма да усети неудобство от това. Но повечето хора, които искат да се занимават с програмиране, обикновено имат интерес да се учат постоянно и не искат да ползват само един език. Разумният вариант за такива хора би бил да спрат да ползват класическите IDE-та. Това обаче като че ли не се случва винаги. Даже по-често май не се случва хич. Самият аз доста късно стигнах до извода, че ако искам да съм програмист трябва да се откажа от "комфорта" на някое стандартно IDE и да се науча да ползвам нещата, които повечето хора описват като "hardcore"(т'ва са глупости). Често(предвид малкото време изминало от както съмна това мнение) съм се изкушавал да казвам, че IDE-тата са глупост, която пречи повече, отколкото помага. Но започвам да се замислям, че всъщност те имат нещо много хубаво в себе си, фактът, че създават навици, позволяват ти да вкараш в "мускулната" си памет много важни повтаряеми действия. Аз например сейввам това, което пиша грубо по веднъж на минута, правя го без да мисля(както и почти всичко друго в живота ми, но това е друга бира). Неща като компилиране/стартиране на написания код могат да се превърнат в елементарно действие, което правите без да се замисляте, прескачайки нивото на абстракция свързано с натискане на копчета от клавиатурата. Мозъкът казва "искам да го пусна" и ръцете ви правят нещо, което съзнателно не контролирате, няма го момента с "искам да го пусна, за това ще натисна Ctrl+S и после лявата ми ръка ще се отмести 5 сантиметра нагоре по клавиатурата до F5, за да го пусна", защото всичко след първата запетайка в това изказване не е релевантно, а е само досадна подробност. Това, което ме подтикна преди година и нещо да се науча да ползвам vim и като цяло да свикна да работя възможно най-много в командния ред, беше твърдото ми убеждение, че това е правилният и дори единствен начин да разбера как наистина работят нещата, които ползвам. Все още смятам, че съм прав в това си разбиране. За досадните домашни/проекти в началото на обучението ми в университета, ползвах Visual Studio. Основната причина за това беше незнанието, че съществува алтернатива, за която има разумни аргументи, че си заслужава. Никой никога в няколкото години до тогава, в които ми е било преподавано програмиране под различни форми не ми беше казал, че мога да не ползвам такова IDE и да постигам същите резултати, без да се налага да страдам от това по някакъв начин. И днес виждам хора разбиращи от писане на код(което е все пак малко по-различно то програмиране), които не знаят каква точно е разликата между текстов редактор и компилатор. Такъв тип куриози се получават точно поради тая причина. Факт е че за езици като C# и Java например, схемата с независими текстов редактор и компилатор, вместо IDE, води до болезнени резултати. Дали това не е проблем на езиците обаче?

*В крайна сметка с времето се убеждавам в правотата си, да се откажа от класическите IDE-та. На няколкото курса посветени на конкретни езици, които съм посещавал в университета важна част е изборът на среда. За много хора това е стресиращо. Ако до днес си писал на C++ ползвайки Visual Studio и сега трябва да ползваш Eclipse за Java или пък PyCharm за Python, това може да се окаже проблем. Необходимостта да се адаптираш към съвсем нов вид workflow често е стресиращо, особено ако си поставен пред срокове(било то сесия, или проект във фирмата, където работиш). Допирните точки в поведението на различните среди за разработка, включително такива за един и същи език, могат да бъдат драстично различни, а в живия живот рядко си програмист на езика X, активно ти се налага да ползваш поне два. Две различни среди за разработка, с различни shortcut-и, дори ако щете различни оцветявания на кода(това също може да е дразнещо, дори не е необходимо да сте крайно педантични) могат да пречат сериозно на това колко програмирате и колко се борите с инструментите си. Това е може би основната причина да смятам, че съм открил по-добрия workflow, такъв който позволява пълна независимост от езика/фреймуърка, който ползвам, като ми дава редица благинки и глезотии. Силата в отказването от големите enterprise решения за програмиране идва най-вече от decouple-ването на задачите. Ако средата за разработка A има страшно яки възможности що се отнася до писане на код, цветови схеми, code compleation и прочее, но пък ползва кофти компилатор/интерпретатор за езика, значи не ми върши добра работа. От друга страна, ако средата B ползва страхотен компилатор/интерпретатор, но откъм редактиране на текст е сравнима с cat очевидно също не е добър избор. Ако се отърси човек от желанието да ползва тежък enterprise, това му позволява да сглоби най-добрата среда за себе си съвсем сам и то без особена трудност. Няма да се лъжем, първите няколко седмици във vim бяха тежки, нещо тривиално като да разбера, а после и свикна с мисълта, че ctrl+s заключва терминала бяха леко фрустриращи, но за кратко. След един не толкова дълъг период обаче, нещата потръгват изумително лесно. След като човек схване основите на инструмента, който си е избрал от там нататък започва да вижда възможности навсякъде. Факт е, че vim(за разлика от emacs) не е толкова функционален out-of-the-box. Но ако човек смята да му отдели повече от две седмици, това не би трябвало да го притеснява. Смея да твърдя, че в момента с vim за езиците, които ползвам най-често мога да правя далеч повече неща за далеч по-малко време от колкото немалко кодери с дълъг опит, ползващи да речем Eclipse или PyCharm, а далеч не смятам, че съм твърде опитен и можещ вимаджия, познавам не един и двама далеч по-изкусни в тая работа от мен. Vim те задължава да разбираш поне концепцията на нещата, които ползваш и това те прави много по-добър. Разбира се, че можеш да изпонасваляш на поразия една сюрия плъгини и да накараш vim не просто да е по-функционален от което и да е IDE, ами и завидно по-ресурсоемък. Ако си падаш по тия неща може и просто да отвориш github и да наточиш vim файловете на някой виден(или пък не) вимаджия и да си стопиш главата при положение, че не ти е ясно що са то регистри и буфери, каква е разликата между команда и функция и прочее дребни неща, които обаче е важно да знаеш, за да можеш да прецениш какво искаш от редактора си всъщност.

Не дълго след като се захванах да ползвам vim сериозно установих, че един shell рядко е достатъчен. След кратко лутане и опит да ползвам gnu screen(едно от камъчетата, които ем научиха да подхождам с резерви към нещата, чиито имена започват с 'gnu') стигнах до tmux. Честно казано бях очарован. Отне ми няколко дена да свикна съвсем и да започна да го ползвам активно. От самото начало ми се виждаше безумно да ползвам табовете на гномския терминал, не знам защо. Простичките неща като pane-ове, прозорци и отделни сесии в tmuz доста бързо ми станаха наобходимост.

Това води до ред полезни неща. Човек започва по-добре да разбира и осъзнава какъв е процесът на създаване на някакво приложение, разбира къде свършва писането на кода и започва компилирането/интерпретирането, разбира много добре идеята за т'ва що е то input/output и прочее. И целият този процес е много забавен и интересен(поне на ми е силно забавен и интересен), през цялото време има възможност да надгражда и променя средата си според разбиранията си и това какво му е удобно, има възможността да бърка епично и след това да се плясва шумно по челото разбирайки какво е направил и осъзнавайки много по-добре концепции, които биха му убегнали като някакъв дребен детайл, за който някой друг се е погрижил вместо него.

Всичко това е свързано с низ от дребни удобства, които комбинирани се оказват далеч по-приятни и полезни от това, което може да получи човек от един продукт асмеблиран и конфигуриран то някой друг с цел да се хареса на всеки. Сесиите в tmux(мисля, че същата функционалност има и в screen) както и възможността те да се пазят активни, дори когато няма вързан клиент към тях дават редица удобства. Фактът, че мога да остава tmux-а в офиса отворен с три прозореца за vim, django сървър и един за гнерални bash нужди и след това от произволно място да вържа един ssh до машината в офиса и да се закача към същата tmux сесия, с всичките ми необходими файлове отворени във vim, работещия сървър и на практика целия контекст, който съм оставил няколко часа по-рано тръгвайки от работа, това е невероятно удобство.

В крайна сметка простичката комбинация от tmux и vim се оказва изключително мощна "среда за разработка", зависеща разбира се от още ред други неща като ctags, ack-grep, git, които обаче не изискват особено конфигурация от своя страна, а интеграцията им в "IDE"-то ми е работа на операционната ми система.

Друго крайно приятно следствие от един такъв setup, е времето необходимо да си осигуря комфорт на нова машина/операционна система. Инсталирането на 5-6 програми, като всичките са в хранилищата на всяка смислена unix-подобна дистрибуция, последвано от клониране на github repo-то с vim конфигурацията ми и набавяне на tmux конфигурацията ми(която сега се досещам, че е крайно глупаво от моя страна да нямам под формата на gist). Всичко това се случва в рамките на 20-30 минути в условията на разумна интернет връзка и неща, които да ме разсейват, за да се забавя повече от необходимото. За сравнение, последния път когато инсталирах VS2010(OH GOD WHY...) процесът на сваляне, инсталиране и подкарване ми отне малко над час. И разбира се не е маловажен и факта, че ако не дай си боже някой ден дебеловратите чичковци успеят да прокарат поредния наследник на SOPA/ACTA, моите инструменти са напълно легани без да съм дал и стотинка за тях.

И тъй като всеки луд е с номера си, а според общоприетите стандарти на обществото, повечето програмисти не са еталон за нормалност и психическо здраве, този подход въщност не е обвързан с почти нищо, освен една много обща абстракция, която обаче е лесна за реализиране. Ако човек смята модалните редактори за изобретение на Сатанаил, може да ползва emacs, SciTe, Kate, Sublime, даже екстри като Yi и прочее, възможностите са ефективно безкрайни. Ако си падате по тия неща може да смените tmux със screen, или пък просто да ползвате табовете на любимия си терминален емулатор. Ако имате религиозен проблем с ползването на unix системи, нещата, от които има смисъл в widnows контекст работят безупречно и там(tmux и screen не знам за какво бихте ги ползвали, предвид колко commandline ориентиран е widnows), въпреки че според мен с изключение на windows-специфичните неща, програмирането в unix-like среди е далеч по-приятно, забавно и обучително, от колкото в нещо друго.

Multi-user

Знам аз от доста време, че Unix-ите попринцип имат като предимство т'ва, че са multi-user операционни системи. Честно казано т'ва ми звучеше като много яко предимство... ако мислим за седемдесетте години на 20-ти век. В крайна сметка всяка сериозна операционна истема в последните 10-15 години под една или друга форма е ориентирана към многопотребителност(ако тая дума я няма в българския речник, вече й е време!).
В последно време много ми се иска да мога да посвършвам няк'ва работа от лаптопа ми на произволни места, позлвайки компютъра ми в офиса. Последната седмица най-много ме тресеше тая треска, щото с почването на учебната година, времето което мога да прекарвам на работното ми място намаля драстично, цифром и словом баш 2(два) пъти.
До сега използвах грозни трикове, които чат-пат сработваха. Тук тунелче, там тунелче, ssh -X, викам си стига ми да мога да си attach-на сесията на tmux-а и да пусна един браузър от там с forward-натия X. Фактите обаче показаха, че т'ва макар и да работи не е супер удобно. Все още съм далеч от възможността да отговарям на "ш'ти го пратя по Skype" с "Е мързи ме с'я да пускам X..."(реален разговор, който скоро ми цитираха). Т'ва иде да рече, че колкото и комфортно да се чувствам на върха на един bash->tmux->vim workstack, винаги мога да стана поне малко по-ефективен ако разполагам с някоя и друга глезотийка на графичната среда, която особено ако биде често необходима благинка, направо се превръща в необходимост.
Днес съдбата ми се усмихна и открих прекрасно решение на проблема си. Както обикновено се случва що се отнася до всичко it-ориентирано това което човек си мисли за свое велико откритие, обикновнео е измислено създаддено че даже и добре документирано от някой друг, преди 10*n години.
Днешният ми малък "EUREKA!" момент, беше свързан с xinit. Опцията да си пусне човек втори Xserver локално е едно безумно удобство, което усещам, че в близко бъдеще ш'а почна да възприемам като сериозна необходимост.
Чак се вдъхнових да опиша как съм го постигнал, та току-виж помогнало някому някога
Цялата магия е нежно събрана в тоя тънък ред:

#> xinit -- :1 vtn

Като резултат на терминал n(до който можете да стигнете с Ctrl+Alt+Fn) се пуска нов Xserver, съвсем гол само с един терминал в него, ник'ви десктоп среди, ник'ви window manager-и.
Ето кратко описание на простичкия ми use-case в случая:
Имам си локален gnome, който върви на терминал 8(сигурно съм трепал gdm-то по някое време, че да не е на седем, а на осем). Отивам на tty1(едва ли има смисъл, но дa отбележа, че нема значение кой точно tty ш'си харесате) и от там с

#>xinit -- :1 vt7

пускам един Xserver на седми терминал, в който съответно върви един графичен терминал. В тоя графичен терминал съм логнат като root, така че от там, предвид че искам да се вържа към машината на хост baba.baba.baba.baba като dqdo всичко нужно е

sudo -u erkunev ssh -X dqdo@baba.baba.baba.baba

(sudo -u erkunev го слагам там, само от параноя, не съм убеден в необходимостта и полезността му). След успешния логин в отдалечената машина всичко необходимо е

gnome-session

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

Надявам се това невероятно откритие на топлата вода поне на един човек да е било полезно и поне на още няколко - интересно/забавно.

Homemade crash course

През изминалата седмица бях на интервю за работа. Първото ми такова за работа, с която раелно искам да се занимавам, а не просто нещо за изкарване на пари или запълване на ваканции с нещо по-полезно от редица безполезни неща.
По тоя повод ми се наложи да направя нещо, което не си бях представял, че ще ми се случи. Както обикновено става в IT сферата интервюто си имаше леко препитване на място и 'домашно'. Въпросното домашно не беше върху кой знае колко инетресен проблем(ако някой има интерес може да разгледа какво сътворих в крайна сметка тук). Това което едновременно ме наплаши и ентусиазира беше изискването да пиша на Perl.
Обичам да се смятам за човек, сериозно взискателен що се отнася до собствените ми постижения. В съответствие с т'ва доста бих държал показвайки код на човек, който не ме познава по никакъв начин, да иде реч за красив и добре написан, обмислен код. С малко повече старание това може да постигне всеки, когато му се даде да ползва познат език. Аз обаче през живота си не бях писал и ред Perl до тая седмица. Преди около месец нещо авантюристично в мен пожела да подхвана някоя книжка за тоя език. Опитът ми да се пообуча удари на няколко камъка.
* Първият от тях беше огромната ми грешка да започна да чета "Minimal Perl"... Ако някога се замислите дали да не пробвате тая книга, ударете се през ръцете три пъти, а ако даже имате хартиено копие изгорете го. Имам един познат, който е горд с факта, че може да пише на C на всеки възможен език за програмиране. Даже разполагаше с онагледяващ тоя факт код писан на Prolog, което беше впечатляващо. Това, което се опита да ме научи тая книга беше това. Как да пишеш на Perl както пишеш на C, как да пишеш на Perl както пишеш на bash, как да пишеш на Perl както пишеш на <insert random somewhat popular programming language name here>. А пък е хубаво човек като се учи да пише на езика X, не просто да пише неща, които да минават през интерпретарора/компилатора на дадения език, а да следва някакви норми, идеи и специфични конструкции/похвати характерни за тоя език.
* Perl е разнообразен. Имам предвид УЖАСНО разнообразен. Има много начини да се направи едно и също нещо. От болезнено вербозни и досадно подробни до криптични и напомнящи древни религиозни писания използвани за призоваване на разни тъмни сили. Това може да създаде страшно много главоболия на човек, който е прохождащ в него. Според мен най-ефективният начин за учене на език(ако не разполагаш с опитен човек, който да те въведе и разходи из тоя език) е след малко теория и описания на някакви основни конструкции и идиоми характерни за езика, човек да почне да гледа много примери и по еволуционно доказания метод на мимикрията и копирачеството да навлезе в нещата. Когато синтактивно(и не само) имаш 78 различни начина да итерираш през елементите на един hash това затруднява малко частта с гледането на примерен код.
* Езикът не изглежда никак привлекателен на пръв поглед. Каквото и да си говорим $, @, %, # не са сред символите, които ми доставят естетическо удоволствие.
Поставен обаче пред задачата правя-струвам за една седмица да има какво да покажа си седнах на глутеус максимуса и се хванах да чета. Това беше отправната ми точка. Самия туториал е написан с идеята да се чете включително и от хора с приблизително нулево разбиране от програмиране, вътре има обяснения на това какво е функция, какво е ркурсия, какво е ООП и прочее. Това до някаква степен е удобно, защото вижайки идеята на автора за някаква концепция(дори и такава, която ми е напълно ясна) мога по-лесно да вникна в обяснението му на имплементацията на тая концепция в езика. Много диагонално минах и през Programming Perl на O'Reilly, която смятам да прочета по-внимателно в близко бъдеще.
Изживях огромен стрес при сблъскването с реализацията нa ООП в Perl. Честно казано все още не съм сигурен, че разбирам какво се случва, още по-малко защо се случва и как аджеба работи цялото нещо. Успях да посвикна с идеята за модули и референции, които получават някакви благословии свише... Въпреки че и в момента се усмихвам при идеята, че vim оцветява думата bless като запазена.
Оказва се, че много относително очевидни неща не са толкова добре обяснени и подчертани, колкото би ми се искало. Досаден и бих казал срамен за мен самия факт е че ми отне около едно денонощие докато разбера, че ключовете в един hash могат да бъдат само стрингове и Perl интерпретатора прави необходимите преобразования вместо мен, тихичко и послушно без изобщода ми казва.
В крайна сметка научих нещо интересно: Кратките срокове за привидно сложни неща(учене на език, с който сте тотално незапознати) действат благотворно върху мобилизацията и способността за учене. Предполагам все пак трябва да бъдат практикувани в някакви резумни граници, отвъд които човек би започнал да си причинява стрес. :)

CodeRetreat @ initLab

В кратце казано ш'а опомена, че т'ва беше доста забавно, а смятам и полезно.

По-пространно казано днес бях на CodeRetreat в initLab. Идеята беше простичка, по двойки на итерации(врътки/сесии/пасове) от по 45 минути се разцъкваше писане на Game Of Life, като основната цел беше не завървен проект, а активно ползване на TDD.

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

Като цяло обаче и в петте врътки, в които участвах ми беше забавно и интересно. Понаучих това онова, видях и чух разни интересни идеи както за Game Of Life така и относно TDD. Като цяло се отърках в едно значително по-високо ниво developer-и и колкото и да не съм бил очарователен в представянето си се радвам на така стеклите се обстоятелства.

Определено бих препоръчал всеки, на когото се отдаде възможност да присъства на нещо подобно да се възползва от нея. 45-те минути при добре поставен и ясен проблем са перфектен период от време, в който да се стигне до същината на проблема, да се реши някаква сериозна важна част от него и през това време да успеете да откраднете нещо малко от партньора си, било то идея за имплементация, подход към тестването, хитрост в ползването на IDE-то и прочее.

Заслужаваше си, хареса ми, много съм доволен, че присъствах и се надявам, че ще имам възможност да повторя. Специално ш'а поуча малко Scala за случая :D

"Free" as in "For all"

Може и да изглежда смешно да пиша няк'ви дълбоки мисли за отворения софтуер. Фен съм му, разбира се, при това голям, но опитът ми е доста оскъден, предимно потребителски. След края на сесията мисля да впрегна чичо гугъл в търсене на нещо, към което да мога да допринасям, всяка идея съм готов да посрещна радушно и да обмисля обстойно. :)
Идеята ми е да си кажа защо ми е на сърце отвореното кодене. Един голям довод на хората, които не го харесват е че зад колективната отговорност се крие колективна безотговорност. Това е така в огромна част от случаите, но тук е някак си неприложима максима. Колективната отговорност е параван зад който да се скрият хора принудени да носят някаква отговорнст за нещо. Дали причината ш'а е, че така могат да изкарат някой лев или поради някакъв друг вид задължение, често пъти зад обществата от неперсонифицирани отговорни лица всъщност седят предимно незаинтересовани и безотговорни люде.
При отворения софтуер е точно обратното обаче. И в това няма магия, даже е излючително логично и естествено. Всеки впрегнал се в редиците на някой opensource проект гое направил, не за да изкарва пари или да покрие някоя своя отговорност към някого. Всеки ангажиран в подобно начинание го прави не по задължение, а заради някакво вътрешно желание. Никой не прави любимите си неща през пръсти, това с пълна сила важи за програмистите. Отвореният код в тоя (леко разпилян) ред на мисли е една изключително сериозна гаранция за качество.
Съвремието ни предлага хубави примери. В последно време се захванах по-активно да чета обяви за работа, че ме хвана срам на моите години в трудовата ми книжка да няма нищо смислено. Открих, че има сериозно търсене ан хора запознати с Linux. И не иде реч за администратори, хора които да поддържат сървъри и прочее типично Linux-ски поприща от край време. Немалко фирми търсят хора, които са готови да вършат ежедневната си работа използвайки Linux на десктоп машината си. Т.е. IT фирмите в България започват да тръгват по тоя път, макар и бавно и страхливо. Друг факт е, че повечето от най-популярните смартфони в момента използват една отворена платформа надстроена върху линукс ядро. Все по-сериозно на мобилния пазар се ползват open source операционни системи.
'Сичко добре, но съм убеден, че много малко хора биха били съгласни да вярват на добрите намерения на някого, защото да приемете, че отворения код гарантира качество заради ентусиазма и добронамереността на творящите го си е точно това. Обаче тук идва и моментът, че освен желанието и честолюбието, което подтиква всеки занимаващ се с отворен код да пише не просто работещи неща, а добре работещи неща, го има и елемнтът на показност.
Ако пишете нещо, което ще бъде компилирано, обфускирано, криптирано и намазано с майонеза за цвят, вианги можете да си позволите тук-там да кръшнете от правия път. Стига да работи, какво като е грозно... Факт е, че повечето програмисти не гледат с добро око на клиентите и при всяка удобна възможност биха свършили работата си по мързеливия, грозен начин... ама колкото да работи. Никой няма да види кода в крайна сметка, само те ще си го знаят.
Open source ентусиастите нямат това 'удобство'. Те пишат за удоволствие, за да научат нещо ново, за да са полезни. Но всичко, което напишат може да бъде видяно, анализирано и оценено от всеки. Докато затвореният код създава монолитни изпълними последователности от байтове, то отвореният се възприема много повече като учебен материял, като показно, ако щете като фуклявщина на написалия го, че даже защо не и като вид изкуство. По общо разбиране програмирането е индустрия, обикновено виждано като по-близко до начина на работа на поточната линия. Хората занимаващи се с отворен код обаче(може би понякога на ръба на менталното здраве :D) виждат работата си от части и като изкуство. И както никой уважаващ себе си художник не би изложил в галерия своя картина, ако я смята за грозна или безидейна, така и никой уважаващ себе си програмист не би показал пред света свой код, ако не е сигурен, че той е добър. И в двете опоменати преди малко поприща разбира се 'добър' е много сложно за дефиниране понятие, но това не умаловажава факта, че когато показваш на света цялата си работа, а не само някои странични ефекти от нея това те кара да се впрегнеш повече в нея.
Човек може да научи много от open source обществото и като философия и в чисто буквалния смисъл като общодостъпна информация и огромен запас от показни на всякакви тематики. Приложения с отворен код има в абсолютно всяка сфера, в която има и затворени такива, готови не само за изпозване, но и за изучаване, разширяване и подобряване.

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

Now what... (опит за пролог... в литературния смисъл на думата!)

Няколко месеца вече ме мъчи една голяма дилема, дали от грандомания, дали от желание за развитие и комуникация със сходно мислещи(и предимно надежда за откриване на по-добре мислещи, от които да открадна някоя умна мисъл) много ми се искаше да почна блог на кодинг тематика.
Като цяло все още мисля, че човек трябва да има повечко опит, за да се захване с т'ва, но пък аз се считам за природно интелигентен човек и току-виж се оказало, че и с минималня си опит мога да скалъпя нещо що-годе прилично, което да има ползотворен ефект над някого и да е полезно за човечеството поне малко.

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