Forem: Димитър Трифонов (dvt32)

Как self-help ми помогна в софтуерното инженерство

Димитър Трифонов (dvt32) — Sun, 05 Apr 2026 11:59:51 +0000

Изучаването на "self-help" ми помогна много като софтуерен инженер.

Знам, че този термин се свързва с празни мотивационни речи и скъпи събития, от които не научаваш нищо съществено, но всъщност за мен това не е същината на т.нар. "личностно развитие".

Ако задълбаеш в темата, ще откриеш, че всъщност личностното развитие разглежда теми като психология, социални умения, бизнес, продуктивност, развиване на трудова етика и всякакви такива неща.
Иначе казано: self-help те учи на тези soft skills, които всички работодатели търсят в хората, които кандидатстват.

Звучи малко странно, но като се потопиш в тази материя, е все едно "промиваш мозъка си", само че в положителен смисъл. Личностното развитие посява в главата ти манталитета винаги да се стремиш да ставаш по-добър, да си адаптивен, да търсиш предизвикателства, да даваш най-доброто от себе си.

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

Няма да ти трябва например да четеш съвети за интервю от рода на "Не говори отрицателно за минали работодатели!" и след това да наизустяваш отговори, които искат да чуят на HR интервю… Няма да ти трябва, защото ти сам ще разбираш психологията на цялото нещо: ще разбираш какво точно иска работодателят и интервюиращият, а в главата ти ще си мислиш например неща като "Естествено, че няма да говоря отрицателно за минал работодател! Не само, че ще ми попречи на интервюто, но и това си е просто незряла работа. Не съм някой мрънкач… каквото било, било, не държа в себе си лоши чувства, просто извличам уроци и продължавам напред!".

Като програмист е трудно е да се състезаваш само на база технически умения, защото винаги ще има някой, който е почнал да програмира от 4-годишен, докато ти даже не си писал "Hello World" преди първата си година в университета. Обаче изненадващо (или може би не чак толкова изненадващо?) тези хора, които те превъзхождат технически, най-често почти не са работили върху soft skills, защото целият им фокус е бил върху програмирането.

Естествено, че пак ти трябват И технически умения, но развиването на soft skills е сравнително лесен начин да изпъкнеш от тълпата и дори да компенсираш за това, че някой те превъзхожда в техническите умения. И всичко от self-help помага МНОГО с това!

Mindset, който ми помогна да намеря първата си работа като програмист

Димитър Трифонов (dvt32) — Sun, 05 Apr 2026 11:46:20 +0000

"Ако нямаш работа и си търсиш работа, работата ти е да си намериш работа." Готин цитат, който чух от John Sonmez! 😎 Това ми помогна много, за да намеря първата си работа като програмист!

Тоест когато си търсиш работа, идеята е да си го представиш все едно си на 8-часов работен ден и позицията ти е "търсещ си работа". Това означава през тези 8 часа да правиш всичко, което те доближава до намирането на работа: кандидатстване, проучване на пазара, работа по CV, работа по личен brand (най-малкото развиване на GitHub, а в оптималния случай също LinkedIn и даже развиване на блог), упражняване в интервюта, развиване на технически и soft умения (каране на курсове, четене на книги, правене на проекти), ходене по събития за networking или използване на LinkedIn и т.н. Всичко, което по някакъв начин увеличава шансовете ти за успех.

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

Съвети за водене на технически IT интервюта

Димитър Трифонов (dvt32) — Sun, 21 Sep 2025 12:42:12 +0000

(Първо публикувано на May 24, 2025)

След около година почивка, реших отново да се върна към блога си. 😅

Откакто последно писах, имам известен прогрес в кариерата си… дори водих няколко технически интервюта за начални Java Developer позиции! Беше готино и поучително, та реших да споделя някои неща, които научих от това. Постът не е с цел коментиране на кандидатите, а по-скоро идеята е да е полезен на хора, на които им предстои да водят интервюта. 👀

Как започна всичко? На работа ми предложиха да се включа като интервюиращ и поех предизвикателството, защото знаех, че ще ми помогне да стигна следващото ниво в развитието ми като професионален софтуерен инженер.

Първо участвах само като присъстващ в 2–3 интервюта, които де факто бяха водени от по-опитен от мен колега, а аз само вмъквах тук-там някой въпрос, ако се сетя (“shadow interviewing”). В същото време си водих бележки (хем за кандидата, който интервюират, хем и за нещата, които научавам от колегата, който води интервюто). Беше полезно, защото ми помогна да свикна постепенно с напрежението от воденето на интервю, вместо да трябва от нулата да скоча в напълно неизвестното.

Между другото, когато аз самият ходех по интервюта в търсене на работа, също обикновено бяха 2-ма интервюиращи. Тогава си мислех, че по-тихият е по-опитният (и съответно просто наблюдава как протичат нещата, оставяйки по-неопитният да трупа опит), но май по-често е наобратно… 😆 Когато теб те интервюират, си мислиш, че на теб е хвърлена трудната част, а за интервюиращия е лесното, но всъщност не е точно така. Когато започнеш да интервюираш, осъзнаваш, че е тегаво и за двете страни.

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

Беше странно усещане да съм от другата страна в едно техническо интервю и изпитвах impostor syndrome (“Аз да водя интервюто? Та то и аз имам бая пропуски и не знам всички тези неща перфектно, къде съм тръгнал да определям кой става за програмист и кой не!?”). Страхувах се също, че ще срещна и някои кандидати, които са по-добри от мен самия. 😂

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

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

Относно техническите въпроси: всъщност според мен основното им предназначение НЕ Е да определят дали кандидадът е наизустил перфектно отговорите… а по-скоро от тези отговори да се извлече информация относно как мисли по технически теми. Например ако питаш кандидата за някои принципи в софтуерното инженерство и той ти обясни само няколко от тях, обаче го е направил със свои думи и видимо разбира практическото им приложение, то не е голяма работа, че е забравил или дори не разбира други принципи — по-важното е, че се вижда, че човекът мисли и прилага, а това ще е доста полезно, когато работи. Аналогично, ако пък изрецитира описание по учебник на всеки един принцип, но се усеща, че му липсва истинско разбиране на темата, не оставя добро впечатление.

И така, започнах да водя самостоятелно интервюта. За да улесня малко процеса за себе си, започнах да си развивам един документ с технически въпроси и отговори по категории (в моя случай интервюирам за начални Java backend позиции, така че категориите бяха неща като “Java”, “OOP”, “Databases”, “Frameworks” и така нататък). В категориите слагах първо общи въпроси (“Ползвал ли си X?”, “За какво си го ползвал?”), за да добия обща представа за нивото на кандидата (и да не го мъча излишно с някакви конкретни въпроси, които са безсмислени, ако не е ползвал дадена технология). След това следваха и по-конкретни технически въпроси, за да видя доколко точно разбира дадената концепция кандидатът. Както споменах, гледах да имам и някакви отговори, за да не разчитам само на моите собствени несъвършени знания, а и за да мога да съм по-полезен, ако кандидатът иска да научи отговора на някой въпрос. Това ми помогна значително, за да се чувствам по-уверен.

Докато водех интервютата, наблюдавах всъщност и колко време ми отнема да задам въпросите си. Времето е ограничено (в моя случай интервютата бяха около час) и затова трябваше да внимавам да не стане така, че съм задал 100 въпроса за Java, но 0 за бази данни, Spring и т.н. Трябва предварително да си определил кои умения са важни за позицията и в края на интервюто да имаш добра представа за нивото на кандидата във всяка едно от тях. Това означава, че понякога се налагаше да пропусна някой въпрос, да прекъсна кандидата или да насоча въпросите към друга тема.

Според мен далеч по-важно е да зададеш въпрос за всяко важно за позицията умение, отколкото да дълбаеш в едно конкретно, докато не “затапиш” кандидата. Тоест ако човекът знае нещата ДОСТАТЪЧНО добре (например знае основите на Java, OOP, бази данни, Spring), то според мен няма нужда от допълнително мъчение с разни въпроси за конкретни дребни специфични технически неща, които няма да са му чак толкова важни в ежедневната практика, а и бързо може да научи на работа, ако толкова му е необходимо.

Все пак понякога кандидатът ще е притеснен и/или няма да знае какво да отговори, та затова гледах да казвам неща от рода на “Няма проблем, ако не знаеш отговора” (научих го от колегата, с който бях в първите подготвителни интервюта 😂) и просто разговорът да не е прекалено формален, сериозен и все едно е краят на света. Стараех се хем да свърша работата си адекватно и професионално, хем да съм ЧОВЕК и да вляза в положението на кандидата: да му дам feedback, да му дам реалистична представа какво би било на работа при нас и т.н.

След интервюто веднага подготвях писмено мнението ми за представянето на кандидата, защото исках да го направя, докато всичко ми е все още прясно в главата. В противен случай започвам да забравям детайлите и накрая оценката ми няма да е максимално точна и обективна.

И това е общо взето. Обобщено казано: в началото беше трудно и изпитвах тревожност (мисля, че е неизбежно), но след 2–3 интервюта почнах да се чувствам по-спокоен и уверен (освен самия опит, може би най-много ми помогна списъка с въпроси/отговори, който си доразвивах с всяко интервю). След всяко интервю си извличах по някой урок относно какво мога да подобря за следващия път.

Успех! 😎

Научи се кога да СПРЕШ с проучването и търсенето на решения, когато програмираш!

Димитър Трифонов (dvt32) — Sat, 20 Sep 2025 14:39:55 +0000

(Първо публикувано на May 26, 2024)

Забелязвам, че когато се занимаваш с програмиране, развиваш един навик, който като цяло е добър, но може и да ти навреди, ако не внимаваш: това е навикът да задълбаваш ДОСТА в различни проблеми, за да намериш решение за тях. 😅

Най-простият пример: работиш по някаква задача, получаваш някакво съобщение за грешка и почваш да ровиш в нета, за да разбереш как да го отстраниш. В най-добрия случай бързо намираш решение и продължаваш напред, но понякога откриваш, че проблемът е по-сложен от очакваното и не можеш да го разрешиш толкова лесно.

Продължаваш да търсиш и откриваш, че всъщност причината за появилото се съобщение е някаква си друга грешка, която пък е породена от еди-какво си… и така навлизаш все по-дълбоко в “заешката дупка” и накрая или намираш решение (да се надяваме 😂), или започваш да се чувстваш безпомощен, защото нищо не решава проблема ти… 😆

Проучването е полезно, но лошото е, че понякога НЯМА да намериш решение на проблема ти. В някои случаи решение не съществува, в други просто не знаеш как точно да го намериш (не знаеш как точно да зададеш въпроса си, решението не е публично достъпно и т.н.), а понякога “решението” не е истинско отстраняване на проблема, а е просто начин да го управляваш, за да не ти пречи чак толкова…

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

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

Когато проучвам известно време някакъв проблем по програмиране и стигна точката, в която се връщам отново и отново към едни и същи отговори (например пробвам да задам въпроса си по различни начини и все стигам до едни и същи отговори в Google или ChatGPT 😅), то най-вероятно това ще е най-доброто, което ще успея да намеря самостоятелно… и за момента ще трябва да се примиря (или ще ми трябва допълнителна помощ).

Освен това гледам да си задам някакви времеви граници. Нямам някаква стриктна граница (“Ще проучвам това за максимум X часа!”) и общо взето се доверявам на интуицията си, която ми подсказва, когато се мъча прекалено дълго с даден проблем, но освен това ползвам и pomodoro техниката за продуктивност (времеви кутии от по 25 минути фокус върху едно нещо, кратка почивка и повтаряш) и добро време за приключване е в края на някоя от тези сесии, които правя, когато работя.

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

Успех!

Избягвай live coding в презентации (или поне внимавай с него)!

Димитър Трифонов (dvt32) — Sat, 20 Sep 2025 14:29:13 +0000

(Първо публикувано на May 12, 2024)

Харесвам да правя презентации (за неща, които ме вълнуват 😁), а също и да ги наблюдавам. Даже когато ги наблюдавам, често обръщам повече внимание на самото презентиране, а не толкова на съдържанието. 😂 В контекста на презентациите по програмиране, едно нещо, което забелязвам, когато гледам техническа презентация и има live coding част в нея (т.е. презентиращият пише код в реално време и показва резултата от него)… е, че почти винаги нещо се обърква. 😆

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

Дори и да се подготвяш на макс преди презентацията (дори и да си подготвен за уж всеки един сценарий), все нещо неочаквано ще се случи и ще ти прецака демонстрацията поне частично. 😅 Може би ще започнеш да изпълняваш команди и чак по средата ще осъзнаеш, че не е четимо на екрана; може би инструмента, който ползваш, неочаквано ще забие или ще се рестартира и после потенциално ще си загубил всичко, което си правил досега… или пък дори може би нещо с интернет връзката ще се прецака и след това няма да можеш да продължиш напред. Да, някои проблеми могат да се предотвратят, но въпросът е, че, ако не е абсолютно наложително да ползваш live coding, можеш да си спестиш тревогите за всички тези неща, ако просто го избягваш.

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

Това, което е работило добре за мен, е да имам предварително написан код (и просто да го обяснявам) или (ако няма как да избегна ръчното въвеждане) поне да имам всички команди готови за copy-paste, а също и предварително да знам резултата от тях (и ако не мога да ПОКАЖА този резултат по някакъв алтернативен начин, то поне да го ОБЯСНЯ, за да стане ясно на публиката какво точно правя).

Това е просто мое мнение, разбира се… Някои хора може би се справят добре с live coding, но опитът и наблюденията ми до момента показват, че е по-добре да го избягвам, когато презентирам. 😅

Топ 5 урока от работата ми като (Junior) софтуерен инженер

Димитър Трифонов (dvt32) — Sun, 14 Sep 2025 15:14:34 +0000

(Първо публикувано на Aug 20, 2023)

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

Аз самият съм Java Web Developer (като в последно време повече ползвам Kotlin), но всъщност уроците тук не са чак толкова технически, а са по-скоро свързани с това как да мислиш и да се държиш, ако искаш на работа да максимизираш положителните емоции и да минимизираш отрицателните. 😅

Защо си заслужава прочитането? Ами, ако си Junior, мисля, че малко ще улесниш началото в кариерата ти. Ако си Mid/Senior, ще си спомниш някои от основите, които е лесно да забравиш, когато вече си напреднал и фокусът ти е насочен към други неща. А ако въобще не си developer, може да забележиш, че голяма част от написаното всъщност може да бъде приложено и в твоята собствена сфера на работа (тъй като голяма част от тези уроци според мен са универсално полезни). 👀

И така, ето уроците….

—

1. Очаквай да си объркан в началото и се довери на процеса (няма как да се провалиш, ако просто продължаваш да ОПИТВАШ).

В началото ще си объркан и уплашен, но това е НОРМАЛНО и е важно да не го забравяш!

Общо взето в началото всичко ще ти е ново, неизвестно, плашещо, объркващо и всичките нови неща може да ти дойдат твърде много наведнъж. Освен това вероятно ще те е страх от това да не допуснеш някоя тъпа грешка, заради която да те уволнят (😅), ще си твърде учтив и внимателен за всичко, няма да можеш да бъдеш напълно себе си (ще си притеснен и ще се филтрираш), няма да искаш да поемаш рискове и т.н.

Това е нормално. Ключът е да третираш всичко това като нещо временно, което скоро ще отмине и е просто част от процеса. Може да звучи просто, но ако просто разбираш, че всичко това е нормално и че много хора се сблъскват със същото, ще си по-спокоен и ще ти е по-лесно да изтърпиш този труден период в началото.

Ако просто продължаваш да се ОПИТВАШ, с времето ще свикнеш и нещата ще започнат да се подреждат в главата ти. Замисли се за следното: ако се упражняваш в нещо отново и отново, ден след ден, какъв е шансът да се провалиш (при условие, че се учиш от грешките си)? Почти невъзможно е (рано или късно ще схванеш каквото трябва да схванеш). Рано или късно всичко започва да придобива смисъл в главата ти (представи си го като Рубик кубче, което с времето се подрежда). Рано или късно свикваш с работата и не изпитваш силни емоции от това, което правиш (работата се превръща в навик за теб).

Ако гледаш на нещата по този начин, ще минимизираш страха и напрежението, които изпитваш при започване на първата ти работа. Ще знаеш, че успехът ти е въпрос на ВРЕМЕ и ФОКУСИРАН ТРУД (а не на нещо произволно, което е извън твоя контрол), а затова ще се чувстваш по-спокоен и няма да се чувстваш сякаш не правиш нещо както трябва или сякаш има нещо сбъркано с теб.

—

Обаче е важно да не се хващаш с ТВЪРДЕ МНОГО НАВЕДНЪЖ, защото това ще те парализира психически! В оптималния случай ще навлезеш в нещата ПОСТЕПЕННО (и ако си в добра фирма, хората там ще са се погрижили процесът ти на “onboarding” да протече точно така).

Например в началото аз минах през подготвителен проект, който ми показа какво бих правил в истински проект, а това значително намали напрежението, което изпитвах, когато започнах работа по истинския. Освен това имах колеги, които ми помагаха, когато се чувствах загубен в огромния code base, в който трябваше да се потопя след подготовката, и когато не знаех кое какво е и ме беше страх да не допусна някоя сериозна грешка. Това беше МНОГО полезно. Не елиминира напрежението напълно, но значително го намали.

Все пак ако нямаш такова нещо на разположение, според мен трябва в началото сам да си поставиш за ОСНОВНА ЗАДАЧА това да разделиш проекта, по който работиш, на малки смилаеми части. Например си казваш “ОК, днес ще прочета ей тази част от кода и документацията. След това ще продължа по ей тази част…” и повтаряш този процес отново и отново, докато не придобиеш някаква обща представа за това, с което се бориш.

—

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

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

Всъщност аз сега прилагам същите принципи и за други неща свързани с програмирането, които преди ми се струваха невъзможни (например разбирането на някои по-сложни алгоритми). Просто продължавай да се опитваш и постепенно ще схванеш каквото трябва.

2. Работата в екип не е толковa лоша. Можеш да се научиш да работиш в екип и дори да ти харесва (а това всъщност ще те направи по-добър както в работата ти, така и в живота като цяло).

Отново, в началото всичко ти идва много наведнъж и е леко плашещо. Защо? Поради редица причини…

Първо се запознаваш с много хора наведнъж (например на първия ми работен ден в “истински проект” трябваше да се запозная с 15–20 човека на Daily-то, защото тогава бяхме голям екип 😅). Трябва да запомниш имената на всички и по възможност да запомниш всеки с какво се занимава. Трябва и да се представиш пред всички. За някои хора това не е кой знае какво, но за мен беше доста стресиращо.

Освен това се чувстваш сякаш всеки друг знае повече от теб и e по-добър програмист от теб. Усещането е все едно всеки е там от години и е наясно с всичко, а ти си паднал от друга планета и просто не си за това място. До голяма степен това е илюзия, но все пак вътрешно пак няма да ти е комфортно в началото.

Също така най-вероятно ще те е страх да попиташ за помощ, защото не искаш да изглеждаш некомпетентен и не искаш да губиш времето на другите. Понякога пък не знаеш КОГО да питаш. Понякога ти отговарят бавно или неясно. Понякога пък въобще НЯМА кого да питаш в момента.

Отделно изпитваш напрежение и да започнеш да допринасяш стойност към проекта, защото не искаш да изглеждаш като мързеливец, който не прави нищо, или сякаш си някой, който се учи супер бавно и му трябват месеци само за onboarding. Още повече напрежение изпитваш, ако някой те чака да завършиш някоя задача (най-вече ако му е нужно да я приключиш, за да може да продължи напред със своята задача).

—

Обаче, отново, с времето свикваш с работата в екип и ти става по-спокойно отвътре (а и ти харесва повече да работиш така). Защо?

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

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

Постепенно научаваш, че да питаш за помощ не е толкова лошо и често може да ти спести много време и главоболия (вместо 5 дена да си блъскаш главата в стената и да се чудиш “Как да направя това, мамка му!?”, можеш да отделиш 5 минути, за да попиташ “Как да направя това?”, а след това да получиш отговор и да продължиш напред. Във връзка с това, един често срещан въпрос е “КОГА да попитам за помощ?”. Моето правило е следното: първо влагам някакви усилия, за да се справя сам, а когато отвътре се почувствам сякаш НАИСТИНА съм се опитал (т.е. отнесъл съм се сериозно към задачата и съм направил каквото мога), но все още не се получава, то тогава отивам да търся помощ (без значение за какъв проблем става въпрос). Като една леко странична бележка, това мисля, че е и най-добрият подход, ако искаш да получиш помощ от хора по форуми за програмиране и сайтове като StackOverflow (хората ще са много по-склонни да ти помогнат, ако видят, че вече си вложил някакви усилия преди това, а не просто чакаш някой да ти свърши работата, защото си мързел).

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

Става ти и по-комфортно да изразяваш мнение, да поемаш повече рискове в работата и др.

Справянето с работата в екип е непрекъснат процес. Ще продължиш да допускаш грешки в това, но с времето и практиката ще станеш по-добър.

—

Какво трябва да направиш от практическа гледна точка? Отново просто трябва да се довериш на процеса (да имаш сляпа вяра, че с времето работата в екип ще ти стане по-лесна).

Освен това може да пробваш да добавиш и “социални предизвикателства”. Това може да звучи тъпо или странно, но за мен беше доста полезно. Тъй като ми беше трудно да изразявам мнение в различни срещи, да искам помощ и като цяло да съм този, който се свърза с друг колега, за да иска нещо от него, започнах да си поставям малки предизвикателства, чрез които да свикна с тази част от процеса на работа. Например си поставих предизвикателството поне 1 път да изразя мнение по някакъв въпрос в дадена среща. Или пък да питам поне 1 път за нещо, което не ми е ясно. Така, малко по малко и стъпка по стъпка, стана по-естествено да се свързвам с колеги за различни неща (тъй като си доказах, че не е чак толкова лошо).

—

Работата в екип ти помага да развиеш някои умения, които намират приложение както в работата, така и в живота като цяло.

Първо: научаваш се да се сближаваш с хората. Особено ако си интроверт като мен (доста често срещано при програмистите като цяло), е доста вероятно да си свикнал да си правиш всичко сам. Може би това не е задължително лошо нещо, но все пак след известно време става малко скучно и самотно, ако правиш абсолютно ВСИЧКО сам. Работейки с други хора, правиш работата и живота си малко по-забавни и вълнуващи, а дори и по-лесни (ако познаваш и харесваш хората от екипа ти, очевидно работата с тях става по-лесна и приятна). Да, разбира се, че понякога не е точно така (понякога просто не се разбираш с хората от екипа ти), но дори и в този случай поне имаш възможността да се упражняваш в комуникацията с такива “трудни” хора.

А как става това сближаване на практика? Мисля, че неформалните срещи са добър начин. Например периодично имахме някои срещи като “team lunch” или “coffee break”, в които просто си говорехме за произволни неща. Тези срещи не бяха задължителни, но аз исках да присъствам, защото ми дадоха възможност да опозная другите от екипа като ХОРА (а не само като програмисти, product owner-и и така нататък). Също се стараех да присъствам и на всички team buildings, поради същата причина. А ако имаш тази възможност, мисля, че най-добрият начин всъщност е да ходиш до офиса по-често. Аз лично не съм го правил много (твърде много ми харесва да работя от вкъщи 😅), но все пак забелязвам, че хората, които го правят, получават някои ползи, които аз не: по-популярни са, имат повече приятели на работа и т.н.

Второ: научаваш се да не се привързваш твърде много към хората, с които работиш (и свикваш с промяната като цяло). В живота всичко е временно (включително и самият живот 😅), а работата с други хора ти напомня този факт отново и отново. Не знам защо, но когато започнах работа, си мислех, че с хората, с които работя тогава, ще бъдат същите хора, с които ще работя и години по-късно. Обаче всъщност какво става? Хората идват и си отиват: сменят проекти, работа… като цяло просто следват собствените си интереси (а така и трябва, разбира се). Промяната е неизбежна и трябва да свикнеш с това (и да можеш да се адаптираш), а чрез работата в екип научаваш този урок отново и отново.

Трето: ставаш по-добър професионалист. По-конкретно:

Научаваш се да правиш компромиси и да разбираш гледната точка на другите (както гласи книгата “The 7 Habits of Highly Effective People” на Stephen Covey -> “Seek first to understand, then to be understood.”)
Научаваш се да бъдеш по-добър учител и лидер (например поемайки ролята на ментор, вземайки решения в проекта и т.н.)
Научаваш се да се справяш с кода на другите (например в pair programming сесии; когато правиш pull request ревюта и т.н.)

3. Стреми се да правиш всичко максимално КАЧЕСТВЕНО!

Може и да ти се размине това да правиш само минимума на работа, но НЕ Е В ТВОЙ ИНТЕРЕС! Има един цитат, който гласи “Начинът, по който правиш едно нещо, е начинът, по който правиш ВСИЧКО!”. Тоест ако свикнеш “да си оставяш ръцете” на работа, ще започнеш да го правиш и във всичко друго, с което се захванеш. Важно е да осъзнаеш, че влагането на минимални усилия е рецепта за посредственост (и ако искаш повече от посредствени резултати, ще трябва да вложиш повече усилия от посредствения човек). Това като цяло е моята “философия за успех” (която научих от света на личностното развитие).

Дори и не всеки път хората да оценяват труда ти, пак се стреми да дадеш най-доброто от себе си, защото в дългосрочен план това е в твоя полза! С времето ще се превърнеш в един от най-ценните разработчици в екипа ти, без значение къде допринасяш (без значение в кой проект и в коя фирма). Защо? Защото повечето хора са мързеливи и правят само минимума (това е в човешката природа), така че ако ти вложиш само малко повечко усилия от другите, ще ти е лесно да изпъкнеш по положителен начин.

Каквото и да правиш, опитай се да го направиш ДОБРЕ.

Например от гледна точка на КОДА, който пишеш, това означава да пишеш КАЧЕСТВЕН код: прост, четим (разбираем), лесен за поддръжка, добре документиран и така нататък (общо взето код, който следва принципите от книги като “Clean Code” и “Code Complete”). Не прави само минимума (например да оставиш неформатиран код, да използваш неясни имена на променливите ти, да няма документация, няма тестове и т.н.).

Ако пък правиш ПРЕЗЕНТАЦИЯ (или пишеш блог пост 😅), прави я като на първо място мислиш за АУДИТОРИЯТА си (това, което ще е полезно на хората, които ще те слушат). Например направи презентацията проста, забавна, разбираема, релевантна, накрая дай линкове към самата презентация или записа й. Не прави само минимума (например да представяш по скучен начин; да говориш с предположението, че всички разбират терминологията, която използваш; слайдовете ти да са само стени от текст и т.н.).

А ако пък пишеш ДОКУМЕНТАЦИЯ (на кода, който пишеш; при създаване на Jira ticket; при описване на нещо в Confluence и др.), недей да пишеш само нещо “колкото да има там” и което е твърде неясно и само ти си го разбираш. Напиши го достатъчно ясно и подробно (все едно ще го чете някой, който все още няма никакво понятие за това, което документираш).

Когато създаваш PULL REQUESTS: не го прави набързичко, колкото да ти се махне от главата. Първо бъди сигурен, че build-ът на проекта минава успешно; няма оставен кофти форматиран код; няма останали парченца код, които си сложил само за debug-ване, но си забравил да махнеш накрая; няма закоментирани парчета код, които си забравил изтриеш (или за които е трябвало да добавиш допълнителен коментар, който описва защо този код временно не се ползва); ясно е какво точно добавя или променя твоят PR (написано е в описанието му и е изразено чрез имената на твоите commits през git).

Ако пък правиш ревю на чужд PR, недей да го правиш набързичко (освен ако промените не са съвсем малки), т.е. да хвърлиш един бърз поглед, да кажеш “Изглежда добре! и да го одобриш. Недей и да го игнорираш, защото не ти се занимава да разбереш какви точно са промените по кода. Вместо това пробвай кода на твоята машина, виж кое как е, а накрая остави полезен коментар с обратна връзка под PR-а (сега тази обратна връзка ще е много по-полезна, защото си вложил усилия НАИСТИНА да разбереш PR-a и логиката зад промените направени от автора му).

Както се казва: “Дяволът е в детайлите.” Обръщай внимание на малките неща, които повечето хора игнорират или не забелязват.

—

Разбира се, работата НИКОГА няма да е свършена перфектно, но ВСЕ ПАК се стреми за отличие! Направи най-доброто, което можеш, с ресурсите (време, енергия, hardware, software и т.н.), които имаш на разположение. Целта тук е да си изградиш навика да правиш нещата ОТЛИЧНО (като истински майстор в занаята си), без значение с какво си се захванал. Освен това, така ще изградиш РЕПУТАЦИЯТА на някой, който винаги прави нещата добре (качествено). Каквато и роля да играеш в определен етап от кариерата ти (програмист, оратор, ментор и т.н.), опитай се да бъдеш възможно най-добър в нея. Така ще станеш истински шампион (на работа, а и в живота като цяло).

4. В същото време пък (парадоксално) НЕ СЕ ТРЕВОЖИ ЧАК ТОЛКОВА МНОГО! Това е ПРОСТО код!

Да, стреми се за качество, но в същото време не приемай всичко чак толкова на сериозно! Това е просто работа и не е целия ти живот (надявам се 😅)! В края на деня не забравяй, че това е просто работа, просто код и дори нещо да се обърка, най-често не е краят на света.

Лесно е да се вкараш във филма и да започнеш да мислиш, че софтуерното инженерство е голяма работа и е най-важното нещо на света. Да, в известен смисъл наистина е важно, но в повечето случаи не е чак на ниво “живот и смърт” по важност.

Например може да започнеш да мислиш “Олеле, АРХИТЕКТУРАТА на приложението! Толкова е важна и ако приложението не е перфектно проектирано, всичко е прецакано!” Обективно погледнато най-вероятно разработваш просто поредното неоригинално CRUD приложение, а не нещо революционно и невиждано досега. Да, естествено, че е хубаво да помислиш за архитектурата, но самото ти приложение не е ЧАК толкова важно и затова дори и да не е перфектно проектирано, планетата няма да експлодира.

Или пък “Кодът ТРЯБВА да бъде оптимизиран, за да може приложението ни да е 0.01% по-бързо!” Няма нужда кодът да е перфектно оптимизиран, за да изпълни задачата, която ти е поставена (важното е да е ДОСТАТЪЧНО добър). В много случаи може да оптимизираш кода и в по-късен етап, така че не е чак толкова важно, ако не всичко е напълно изгладено от самото начало на разработката.

Или “На ей тази важна позиция съм на работа и всичко, което правя по проекта, е изключително важно!” Дали НАИСТИНА е изключително важно? Дали планетата ще експлодира, ако например напуснеш работата си? Не, ще бъдеш заместен и екипът ти ще измисли как да продължи и без теб. Не се вземай твърде на сериозно.

Като едно допълнение, хареса ми и един съвет, който чух от Alex Yochev на една конференция. Той беше казал просто “Don’t overthink things!” и мисля, че контекстът беше вземането на технически решения в проекта, по който работиш. Тоест недей да вземаш нещата чак толкова на сериозно или да търсиш перфектното решение за всеки технически проблем. Не е нужно всичко да е перфектно, важното е просто да вземеш решение, което ти се струва “достатъчно добро”, а по-нататък може да смениш подхода, ако има нужда.

—

Също така е важно да не се привързваш емоционално към кода, който пишеш! Кодът ти не определя стойността ти като човек.

Например ти правят ревю на PR-а и ти почваш да спориш “Ама ако използваме generics тук ще е много по-добре и ще избегнем повтаряне на код! Няма да позволя моето име да бъде свързано с по-нисша имплементация!” На кой му пука? Просто направи компромис и продължи напред. Не е краят на света, а и можеш просто да рефакторираш по-късно. В много случаи просто не си заслужава да спориш относно неща свързани с кода ти. Не се впрягай за дреболии и просто продължи напред.

Все пак, разбира се, използвай здравия си разум. Ако вярваш, че дадена промяна е наистина важна, сподели аргументите си с екипа и направи каквото можеш, за да бъде въведена в проекта. Въпросът е, че дори да не стане на твоето и точно както си искал, адаптирай се и продължи напред, вместо да плачеш и да мрънкаш.

5. Трябва сам да поддържаш мотивацията си жива, за да продължиш да харесваш работата си.

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

Затова трябва сам да поддържаш жива страстта си за софтуерното инженерство чрез добавяне на РАЗНООБРАЗИЕ и НОВИ ПРЕДИЗВИКАТЕЛСТВА! Мисля, че има 2 начина да постигнеш това: чрез “breadth” (широчина) и “depth” (дълбочина), като двете думички може да са ви познати (от алгоритмите BFS и DFS).

“Breadth” в този контекст е например да смениш проекта, по който работиш, или изцяло да смениш работата си. “Depth” би било да работиш по различни части от сегашния ти проект (например ако си backend developer, би означавало да работиш по нещо свързано с frontend, DevOps, непознати части от backend-а на проекта и т.н.) или да поемеш по-голяма отговорност на сегашната ти работа.

Досега съм използвал предимно вторият подход (“depth”), защото ми харесва проектът, в който съм, и харесвам работата си като цяло. Все пак ето някои примери за това как въвеждам “breadth” и “depth” на работа.

За “breadth”:

1) Карам online курсове за различни технологии и инструменти в програмирането, а дори и за soft skills теми (за технически курсове харесвам Udemy, а за нетехнически Pluralsight, но и в YouTube има доста добри курсове и от двата типа).
2) Чета технически книги. Сега гледам да изчета класиките, но мисля, че дори и някои книги, които НЕ СА директно за програмиране (но по някакъв начин са свързани със софтуерното инженерство), могат да са полезни (например наскоро завърших една свързана с формирането на софтуерните изисквания — готиното е, че ти дава поглед върху някаква най-вероятно непозната за теб част от процеса на разработката, ако си developer и си свикнал в по-голямата част от времето да си фокусиран върху реализацията на вече оформените изисквания).
3) Слушам речи на експерти в областта на софтуерното инженерство. Например периодично гледам презентации от различни Java/Spring конференции, а понякога просто си пускам Uncle Bob, за да си припомня някои основни принципи.

Ползата от тези неща е, че ти помагат да разшириш повърхностните си знания за различни части от софтуерното инженерство (и така е по-лесно да поддържаш интереса си жив). Може и да не ползваш всяка една технология или идея, за която си научил от горните източници, но поне ще знаеш, че съществува и когато се чудиш как да решиш някой проблем, в главата ти по-често ще изплува идеята “Хм, може да пробвам онова, за което прочетох онзи ден!”.

За “depth”:

1) Опитвам да работя върху непознати за мен части от проекта ни. Например понякога пробвам някои малки frontend задачи (или поне пробвам да задълбая във frontend кода, за да свърша backend задачата си по-добре). Също така се опитах да понауча малко и за deployment инструменти, DevOps и др. Предизвиквам се като се опитвам да разбера на по-дълбоко ниво различните части от проекта, по който работя (дори и частите, които не съм ЗАДЪЛЖЕН да познавам). Така поддържам интереса си към проекта жив.
2) Опитвам се да поема повече отговорност в работата ми. Например периодично правя презентации за различни неща, които съм научил в кариерата си (дори този пост първоначално беше под формата на презентация). Не съм задължен да ги правя, но ми харесва, а и вкарва разнообразие в работата ми. Поех и ролята на ментор, което беше интересно и ново за мен изживяване.

Като цяло такива разнообразни предизвикателства поддържат работата интересна за мен. Формулата мисля, че общо взето е следната: ако няма никакво предизвикателство, изпитваш СКУКА; ако предизвикателството е твърде голямо, изпитваш ТРЕВОЖНОСТ (или се ядосваш); ако е постепенно увеличаващо се предизвикателство (което отговаря на сегашните ти умения), изпитваш ВЪЛНЕНИЕ (зараден си с ентусиазъм да продължиш напред).

—

Имай предвид, че тази “depth” идея може да бъде приложена и в КОНКРЕТНИ ЗАДАЧИ.

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

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

Схващаш идеята: винаги търси начини да се предизвикваш.

—

И последно: като страничен ефект от правенето на тези неща на работа, получаваш повече НАГРАДИ: повече уважение от колегите ти, повече повишения и възможности. Освен това поддържаш уменията си и винаги растеш като софтуерен инженер. Като цяло според мен ще спечелиш много, ако започнеш да използваш този начин на мислене на работа, а и в живота като цяло.

БОНУС: Ето още един последен урок, който научих сравнително наскоро. Все още e “work in progress”, тъй като аз самият се опитвам да го приложа и да го разбера на по-дълбоко ниво. 😅

6) Стреми се да се превърнеш в ЛИДЕР (ако искаш да стигнеш елитно ниво)

В един момент ще стигнеш точка, в която имаш малко повече знания от някои от колегите ти (тоест няма ти да си най-неопитния). Може да използваш тези насъбрани знания и опит като начална точка за това да се превърнеш в ЛИДЕР!

Защо това е важно? Защото ако през цялото време се фокусираш върху “микро задачи” (например да имплементираш дадена функционалност, да оправиш някакъв бъг, да изпълниш някакъв произволен Jira ticket тихичко и самостоятелно), ще си “ОК” софтуерен инженер, но няма да стигнеш елитно ниво и няма да си сред най-ценните разработчици в екипа ти.

Най-ценните софтуерни инженери са именно ЛИДЕРИТЕ. Това са хората, които вършат “макро задачите” (например да направят проекта по-бърз, да разрешат критично важни проблеми на PROD и т.н.), т.е. те поемат повече отговорност и също така помагат на колегите си да станат по-добри.

Да, очевидно отнема известно време да стигнеш това ниво (няма как от днес за утре да преминеш от Junior към Senior), но все пак мисля, че можеш да започнеш да се придвижваш в правилната посока още от сега! Ето някои идеи за започване (дори и сега да си Junior):

помагай на другите (помагай с техния onboarding, бъди ментор, помагай за свършването на задачите на другите, кажи им къде могат да намерят помощ за разрешаването на проблемите им и т.н.)
сподели идея/мнение за важни решения в проекта ти (технически решения, решения свързани с процеса на работа и др.) [btw, важното не е дали другите ще приемат идеите ти, а просто да свикнеш да участваш във важните решения и да започнеш да мислиш на “макро” ниво]
направи малко повече от това, което другите очакват от теб (например напиши някакъв guide за да улесниш колегите си с нещо, оправи някакъв забравен и игнориран от всички bug, предложи да представиш нещо полезно за другите: някаква имплементирана функционалност или нещо полезно, които си намерил и може да улесни работата на другите).

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

Обобщение:

Очаквай да си объркан в началото и се довери на процеса (няма как да се провалиш, ако просто продължаваш да ОПИТВАШ).
Работата в екип не е толковa лоша. Можеш да се научиш да работиш в екип и дори да ти харесва (а това всъщност ще те направи по-добър както в работата ти, така и в живота като цяло).
Стреми се да правиш всичко максимално КАЧЕСТВЕНО!
В същото време пък (парадоксално) НЕ СЕ ТРЕВОЖИ ЧАК ТОЛКОВА МНОГО! Това е ПРОСТО код!
Трябва сам да поддържаш мотивацията си жива, за да продължиш да харесваш работата си.
Стреми се да се превърнеш в ЛИДЕР (ако искаш да стигнеш елитно ниво)

Това е засега. Успех! 😎

20 урока от първите ми няколко месеца работа като програмист

Димитър Трифонов (dvt32) — Sat, 13 Sep 2025 18:27:14 +0000

(Първо публикувано на Dec 4, 2022)

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

Включени са някои уроци за придобиване на технически знания, развиване на добри навици в работата ти, справяне със задачи/предизвикателства, интервюта, презентации и т.н.

Списъкът:

Винаги можеш да задълбаеш още повече в различните технологии и техните тънкости (винаги има нещо ново, дори и да е малко, което можеш да научиш или да разбереш по-добре).
Това да имаш задача/проект, по който работиш, е незаменим инструмент за учене (особено за технически неща в софтуерното инженерство).
Трябва да се научиш да управляваш времето си на работа ефективно, за да постигнеш максимална продуктивност (аз използвам Pomodoro техниката).
Обръщай внимание на малките неща (спазвай конвенции и добри практики за код, commits, pull requests, Jira задачи и т.н.)
Не се страхувай да потърсиш помощ (спестява време)! Моето правило: ако съм вложил усилия за известно време и не мога да се справя с някоя задача, търся помощ, без значение какъв е проблемът.
Документирай свършената си работа (за по-добри estimates в бъдеще и за по-голяма увереност в работата ти)!
Разбивай големите задачи на по-малки задачи (и не само в Jira), за да е по-лесна работата ти и да отлагаш по-малко!
По-добре е да ОБЕЩАЕШ МАЛКО и след това да НАДХВЪРЛИШ очакванията, отколкото да обещаеш много и накрая нищо да не е свършено. Така има по-малко напрежение върху теб и свършената работа е по-качествена.
Опитът е най-важното! ТРЯБВА да допуснеш грешки СЕГА, за да може да направиш нещата както трябва ПО-КЪСНО (приложимо за точност в estimates, писане на код и др.)
Техническите интервюта са нещо ПОЛЕЗНО за теб! Вместо да имаш манталитета “Сега трябва да се докажа на интервюиращия!”, пробвай “Просто ще споделя знанията, които имам, и ще разбера какво все още не знам, за да го науча след интервюто!”
Напълно ОК е да не знаеш нещо по време на интервю! ВСЕКИ забравя неща и НИКОЙ не знае всичко (дори опитни инженери). Не означава, че си ужасен програмист и трябва да се откажеш.
Просто запиши пропуските, които си имал по време на интервюто, и РАБОТИ върху тях след това. С времето информацията ще се запамети в главата ти (от цялото това повторение и затвърждаване на теорията, от работа по проекти и т.н.)
Техническите демонстрации/презентации всъщност ти помагат много да развиеш добри soft skills (научаваш се да изразяваш идеите си по интересен/разбираем начин, да влияеш на хората, да намираш технически решения в реално време, когато нещо в демонстрацията леко се обърка 😅).
Фокусирай се върху това, което е интересно на ПУБЛИКАТА ти (когато хората чуят/видят нещо, което възприемат като полезно за техния собствен живот, обръщат повече внимание на казаното от теб и те възприемат по-положително).
Направи презентациите си забавни са слушане (ако съдържанието е представено по скучен начин, хората най-често няма да вземат присърце това, което им споделяш).
Тествай всичко и се подготви обстойно преди презентацията (подготви кода, средата си), за да избегнеш случаи, в които нещо се счупва по средата на презентацията, екранът не се вижда поради някаква причина и т.н.
Проблем: “Отнема ми много време изцяло да завърша някоя задача, дори да е малка!”
Решение:
- Подходи с очакването, че завършването на всяка задача ще отнеме повече време, отколкото предполагаш преди започване на работата по нея.
- Имай предвид и факта, че не всичко зависи от теб (например ревютата на PR-ите ти, проблеми с интернета/тока/външни системи и т.н.)
- Знай, че има голям шанс по някое време да срещнеш проблеми, които ще те блокират или забавят значително (например някакъв странен неразрешим бъг, оправяне на проблеми по PR-ите ти)
- Накрая планирай като имаш тези неща на ум и просто направи най-доброто, което можеш.
Проблем: “Някакъв неочакван бъг ме спира от това да продължа напред и не знам как да се справя!”
Решение:
- Питай някой за помощ (ментор и/или Google 😁) и се опитайте да разрешите проблема заедно.
- Ако не стане, отбележи някъде, че този бъг/проблем съществува и продължи напред с нещо друго за момента.
Проблем “Има много неща, които все още не знам (как работи X технология, какво е Y идея в програмирането и как да я приложа)!”
Решение:
- Проучвай и се учи всеки ден (бавно и стъпка по стъпка). Не само когато ТРЯБВА да го направиш (защото задачата ти го изисква), а буквално през цялото време като хоби (за да поддържаш уменията си и да растеш).
- С времето (чрез повторение и трупане на опит) всичко ще започне да придобива смисъл в главата ти (трябва да имаш вяра в процеса).
Проблем: “Трудно е да работиш, когато зависиш от работата на други хора и/или от тяхната оценка!”
Решение:
- Постоянно работи върху социалните си умения (точно както работиш и върху техническите си умения).
- С времето ще станеш по-добър в това да комуникираш идеите си ефективно (и така по-лесно ще получиш това, което искаш от другите).
- След време този проблем няма да те дразни чак толкова и всъщност ще е ПО-ДОБРЕ, че има някой, който да те подкрепя и да ти дава обратна връзка, за да можеш да растеш.

Въведение в Kotlin (за Java програмисти)

Димитър Трифонов (dvt32) — Mon, 08 Sep 2025 12:49:24 +0000

(Първо публикувано на Sep 17, 2022)

През последните няколко месеца на работа ползвах езика за програмиране Kotlin и реших да споделя какво научих за него и как може да ти бъде полезен, ако си Java програмист. 😎

Kotlin всъщност е доста свързан с Java. Даже в днешно време все повече и повече екипи избират да ползват него вместо Java в различни софтуерни проекти (причините за това ще обясня надолу). Ако искаш да станеш по-динамичен програмист (като в същото време не излизаш от “Java сферата”), според мен си заслужава да го научиш. 😉

Сега ще разгледаме:

Какво е Kotlin (и как може да ти помогне)
Защо не трябва да се плашиш от Kotlin
Как да използваш Kotlin (някои основни и готини възможности на езика)
Как да продължиш от тук нататък (полезни ресурси и съвети)

—

1. Какво е Kotlin (и как може да ти помогне)

Kotlin е език за програмиране, който работи на JVM (Java виртуалната машина). Проектиран е от JetBrains, които най-вероятно са ти познати от това, че са създали средата за разработка IntelliJ IDEA (която вероятно и ползваш за разработка на Java приложения). Имайки това предвид, сигурно може да се досетиш, че всъщност ползвайки Kotlin няма да се отдалечиш твърде много от вече познатите ти неща от Java.

Най-често Kotlin се използва за разработване на Android приложения (Google го предпочитат пред Java). Обаче всъщност езикът намира все по-голямо приложение и в web програмирането, най-вече в backend частта. Изненадващо може да се ползва дори за frontend, а даже и за desktop приложения!

Kotlin има “оперативна съвместимост” (interoperability) с Java. Технически казано, Kotlin генерира Java-съвместим bytecode. Това означава, че сравнително лесно можеш да преобразуваш Java код в Kotlin (и обратно), а също така може да ползваш Kotlin библиотеки в Java проектите си.

Обаче по-важното: може да използваш Java код (не бъркай със синтаксис 😅) в Kotlin приложенията си! Това означава, че все още може да ползваш вече познатите ти Java библиотеки, frameworks, build инструменти и т.н.

—

A как точно може да ти помогне Kotlin?

Основните технически ползи са, че пишеш по-малко (и по-прост) код, а в същото време все още може да ползваш това, което Java ти предоставя.

Личните ползи за теб са, че научаваш нов модерен език за програмиране, а в същото време растеш като Java програмист (дори и да пишеш на Kotlin): надолу ще обясня какво имам предвид под това.

2. Защо не трябва да се плашиш от Kotlin

В човешката природа е да се страхуваме от неизвестното и да искаме да си продължим както сме си карали досега. Ако си свикнал с Java, най-вероятно не ти се минава на друг език за програмиране. И аз бях така… Спомням си, че имах мисли от рода на:

а) “Ъъъ, не знам дали ще успея да науча цял нов език, ДОКАТО съм на работа и докато трябва да допринасям в проекта… 😯”.

Представи си все още да нямаш никакъв професионален опит (тепърва започваш първата си работа) и ти казват, че ще започнеш да работиш по проект написан на Java. Започваш, но накрая се оказва, че трябва да превключиш на друг език за програмиране, който ти е напълно непознат. Точно такъв беше случаят ми. Едно е да имаш време, в което бавно и спокойно можеш да научиш някоя нова технология (или език), друго е да трябва да побързаш, защото се очаква от теб да започнеш да допринасяш в проекта.

б) “Не искам да се отдалечавам от Java… искам да придобия опит като Java програмист, а не като Kotlin програмист!”

Ако си решил да специализираш с Java, едва ли имаш интерес да минаваш към друг език. Инвестирал си бая време в изучаване на Java и искаш да си конкурентоспособен като Java програмист, a сега ти казват “Айде научи това и забрави за Java-та!”? Най-вероятно няма да искаш да го направиш.

в) “Страхувам се, че ще забравя Java и ще съм зле, когато спра да ползвам Kotlin… 😱“

Колкото и да си добър в някой език или технология за програмиране, ако не ги използваш известно време, малко или много ги забравяш и/или вече не знаеш за всичките нововъведения в тях. Ако си се занимавал дълго време с Java, не искаш всичкият ти труд да е бил напразно, а не искаш и след това да си изостанал и да не знаеш какви са новите функционалности в JDK (или пък да забравиш старите).

—

Разбирам всичко това. Обаче, след като ползвах Kotlin за няколко месеца, мога да кажа, че определено си заслужаваше научаването му.

Ето няколко причини защо…

2.1. Научаването на Kotlin (като Java програмист) беше сравнително бързо и лесно

Първо трябва да спомена, че аз самият съм на ниво Junior, така че не бих казал, че дори и в Java съм експерт! 😅 Все пак ми бяха нужни само около 2–3 кратки “crash” курса в YouTube и около 2–3 седмици практика, експериментиране, четене и проучване, за да започна да се чувствам комфортно с основите на Kotlin. Имайки това предвид, ако си с повече опит, може да го научиш и по-бързо от мен!

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

(Два полезни ресурса са този безплатен crash курс в YouTube (линк има най-отдолу) и документацията на Kotlin.)

2.2. Използването на Kotlin (като Java програмист) също е сравнително лесно (и удобно!)

Както споменах горе, основната полза е, че пишеш по-малко код (виж картинката отдолу за малък preview на това).

Синтаксисът е малко по-различен от този на Java, но пак не е особено труден за разбиране и ползване (след като си се упражнявал малко в него).

Има много налична документация и примери, които може да използваш, когато забиеш някъде (а понякога дори някое намерено Java решение може да ти помогне, защото преобразуването на Java в Kotlin е сравнително просто).

Интересното е, че след известно време даже не искаш да се връщаш към Java, защото Kotlin прави имплементирането на нови функционалности доста по-просто. 😅

2.3. Всъщност не “забравяш” Java (поне според моя личен опит)

Забелязвам, че всъщност не се чувствам “ръждясал”, когато превключвам към Java. Например през свободното си време понякога решавам алгоритмични задачи в сайтове като LeetCode (за да поддържам уменията си), а там използвам Java. И това, което наблюдавам, е, че дори през повечето време да ползвам Kotlin, връщането към Java не е болезнено. 😅

Обикновено когато превключа към нов език за програмиране, малко или много започвам да забравям част от синтаксиса и имената на някои често използвани класове/методи в предишния език… Например си спомням, че в университета имахме някои курсове със C++, а други бяха с Java. Ако се бях хванал да пиша предимно на C++, забравях Java, а ако бях фокусиран върху Java, позабравях възможностите на C++.

Когато ползвах Kotlin, обаче, не изпитвах това явление често, защото голяма част от кода, който пишеш на Kotlin, e свързан с Java.

2.4. Растеш като Java програмист (макар и да пишеш на Kotlin)

Защо? Защото все още си оставаш в “Java сферата”:

а) Използваш същото IDE (най-вероятно).

Като се има предвид, че Kotlin e творение на JetBrains, съответно и поддръжката на IntelliJ за Kotlin e чудесна. Също така, както споменах вече, можеш и лесно да конвертираш Java код в Kotlin и наобратно (надолу ще покажа как става). Все пак да, минус е, че ако си с Eclipse или някое друго IDE, най-вероятно ще ти е по-трудно да програмираш на Kotlin. Обаче при всички случаи ще задълбаеш в някои вече познати ти инструменти или поне инструменти, които се ползват и за Java програмиране.

б) Използваш същите frameworks, библиотеки, build инструменти и т.н.

Можеш да ползваш познати от Java технологии като Spring, Maven, Hibernate, JUnit и други. Ако трябва да съм напълно честен, открих, че някои библиотеки не работят на 100% с Kotlin (доколкото си спомням, имаше някакви проблеми с MapStruct и Lombok), но дори и в тези случаи съществува заместител или поне някакъв начин да получиш резултата, който искаш.

в) Все още четеш Java код често (докато преглеждаш кода на някоя библиотека и докато търсиш различни решения в StackOverflow)

Тъй като често ще използваш Java код в Kotlin приложенията си, най-вероятно също ще ЧЕТЕШ такъв код периодично. Може например да погледнеш как е имплементирана някоя част от Java библиотеката, която използваш. Или пък може би получаваш някаква грешка и откриваш Java решения в StackOverflow, които след това нагаждаш за твоя случай, за да можеш да продължиш напред… Както и да го погледнеш, почти сигурно е, че ако пишеш на Kotlin, няма да избягаш напълно от Java.

Като цяло възприемам научаването на Kotlin сякаш просто РАЗШИРЯВАШ знанията си в Java сферата. Не е като да минеш на C# например, защото там трябва да използваш различен framework, различни инструменти и т.н. Вместо това е просто като да научиш някоя нова технология свързана с Java.

3. Как да използваш Kotlin (основи на езика и готини възможности)

Имай предвид, че най-добрият начин да научиш Kotlin е да ЕКСПЕРИМЕНТИРАШ с него. Колкото повече се упражняваш, толкова повече всичко започва да придобива смисъл в главата ти и започваш да го разбираш (само да четеш и да гледаш клипове няма да е достатъчно).

Идеята на този раздел е просто да ти покаже една част от това, което Kotlin предлага (и потенциално да те “зариби” да го пробваш 😅).

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

3.1. Основи на езика

3.1.1. Променливи (variables)

Ако в Java използваме например final int / int или final String / String, то в Kotlin използваме val и var. Тези две ключови думички ще ги срещаш отново и отново в Kotlin кода, който четеш и пишеш.

Също забележи, че няма нужда от точка и запетая (;) в края на някой израз (expression). Може и да сложиш, но най-често се избягва.

Освен това е важно да се отбележи, че в Kotlin нямаме примитивни типове както в Java (int, long, char и т.н.).

Може да видиш също, че за разлика от Java, типът на променливите се изписва след тяхното име (често изписването на типа всъщност може да бъде пропуснато изцяло, благодарение на т.нар. “type inference”, но за това ще спомена малко по-надолу).

—

3.1.2. Функции (functions)

Функциите в Kotlin наподобяват тези в Java, но имат някои особености.

Пример за една елементарна функция е sum(). Всяка функция започва с ключовата дума fun. Параметрите са разделени със запетайка, а след това се изписва какво се очаква да върне функцията (в случая Int). Самото връщане на резултата става по същия начин както в Java (с return).

Интересна особеност са void функциите, които в Kotlin всъщност също връщат стойност (от тип Unit), но при тях може и да не пишеш изрично какъв е очакваният return type.

Една друга подробност е, че Kotlin предоставя свои варианти на често използвани функции в Java. Пак можеш да използваш и съществуващите Java функции, но обикновено Kotlin вариантът е предпочитан (например виж в горния пример как можеш да извеждаш текст в конзолата).

—

3.1.3. Масиви, списъци и т.н.(arrays, lists, etc.)

В Kotlin инициализирането на масиви, списъци и така нататък, е малко по-различно.

Ако например в Java използваме new int[] {} за инициализация на масив от цели числа, то в Kotlin използваме специален метод intArrayOf(), в който можем да подадем колкото искаме елементи. Подобни методи има и за символи, символни низове, byte и т.н. Ако искаш да инициализираш масив от някой твой тип, използваш arrayOf<MyType>().

Друга малка подробност е, че в Kotlin полето за размера на масива се казва size, a не length както в Java.

Интересно е, че също така може да достъпваш и поставяш стойности на елементи от масива чрез get() и set() методи. Пак е предпочитано да използваш доброто старо директно достъпване по индекс (arr[0], arr[1] = 5), но все пак имаш възможността да използваш и другия начин.

При списъците (а и при другите структури от данни) ситуацията е много сходна. Отново използваме специални методи за инициализация. listOf() ни дава read-only списък, a mutableListOf() такъв, който можем да модифицираме (видът на списъка е този, който Kotlin дава по подразбиране: към днешна дата това е ArrayList; можем и изрично да поискаме ArrayList чрез arrayListOf() или даже чрез ArrayList()).

Любопитно е, че при списъците можем да използваме достъпване по индекс и не ни се налага да ползваме get() и set(). Всъщност в Kotlin това е и предпочитаният начин за достъпване и манипулиране на стойности на елементи в списъци (т.е. по-добре използвай myList[0] и myList[1] = 123, дори и да не боравиш с масив 😅).

—

3.1.4. Класове, getters & setters, конструктори и т.н. (classes, getters & setters, constructors, etc.)

В Kotlin е нужно да добавим ключовата дума open, ако искаме някой наш клас да бъде наследим. И докато в Java използваме extends (а при интерфейсите implements), в Kotlin използваме просто :.

Друга интересна особеност е, че в Kotlin автоматично получаваме getter & setter за нашите член-променливи. А когато достъпваме някоя член-променлива, всъщност не я достъпваме директно, а използваме нейния автоматично генериран getter.

На практика става така, че ако имаме член-променлива number, няма да използваме нещо като getNumber() и setNumber(int number), a просто ще я достъпим с number и ще й присвоим стойност с number = 123.

Ако имаш нужда, можеш да промениш съдържанието на getter/setter за дадена променлива, както е показано горе (изглежда малко странно, но самият начин на ползване е прост: просто пишеш какво трябва да върне getter-ът и каква стойност да постави setter-ът). 😅

Освен автоматично генерирани getters & setters, Kotlin има възможност да предостави и автоматично генериран конструктор с дадени параметри. Просто се изброяват параметрите при декларацията на класа (забележи, че в горния пример number и str са извън тялото на класа), а след това имаме генериран конструктор, чрез който можем да направим инициализацията.

Забележи също, че в Kotlin не използваме new при създаване на обекти.

Една малка особеност е, че в Kotlin синтаксисът при използването на инстанция на анонимен клас е малко по-различен, а също и начинът по-който правим override на някой метод.

Например в Java, когато искаме да използваме собствен Comparator за сортиране на масив, използваме new Comparator<MyType>() { }, като в тялото override-ваме метода, който сравнява два елемента, и поставяме @Override анотация над него.

В Kotlin е малко по-различно и използваме object : Comparator<MyType> { } (използваме анонимен “object”), a в тялото използваме ключова дума override вместо анотация.

В Kotlin не използваме ключова дума static (както в Java). Вместо това всеки клас може да има свой companion object, в който се добавят статични полета и методи. И както се вижда в примера горе, имаме различни начини, по които можем да достъпим след това този специален обект и полетата/методите му.

Другият начин да имаме статични полета е да използваме object (обяснено надолу).

В Kotlin модификаторите за достъп са малко по-различни от тези в Java.

По подразбиране всичко в Kotlin e public (т.е. ако няма модификатор за достъп, полето/методът ни ще бъде публично достъпен). При private и protected няма нищо особено.

Интересното е модификаторът internal на Kotlin. Това е нещо като Kotlin версията на package-private в Java, но не точно. Като цяло Kotlin не придава голямо значение на пакетите, в които са класовете ти. Това, което е маркирано с internal, е видимо само в същия Kotlin “модул” (група от файлове, които се компилират заедно; пример за такава група е един Maven модул в проект с множество модули).

—

3.1.5. “when”, “is” и други

В Kotlin не ползваме switch, а вместо това when. Структурата на when е доста сходна, но в същото време доста по-гъвкава. Примерите горе говорят сами за себе си.

На мен лично най-много ми харесва възможността да изброяваш различни булеви изрази и да определяш какво да се случва, когато някой от тях е true (много по-компактно от if-else 😅).

Oще някои (дребни?) неща:

В Kotlin използваме is вместо instanceof, когато искаме да проверим дали типът на някой обект е този, който очакваме.
Използваме as за explicit casting (според мен е по-приятно за четене така, отколкото с множеството скоби в Java 😅).
В Java имаме Object, а в Kotlin еквивалентът е Any.
Нямаме ternary оператор за разлика от Java, но пък има алтернатива, която (според гледната точка) може да се каже, че е по-добра и по-гъвкава (ще я обясня надолу).
Нямаме и “класически” for цикъл в Kotlin, но отново има алтернатива, която според мен е доста добра (и тя е обяснена надолу).

—

3.2. Готини възможности на Kotlin

Тук ще ви споделя някои от любимите ми възможности на Kotlin (подредени в случаен ред 😅).

3.2.1. String templates (шаблони за символни низове)

Това е малка готина функционалност, която може и да ти е позната, ако си ползвал TypeScript. 😅

Просто не ти се налага да правиш тъмни магии с printf(), да добавяш символи за нов ред или да правиш досадни конкатенации. Kotlin ти дава голяма гъвкавост в оформянето на символните низове, които създаваш.

—

3.2.2. Type inference (автоматично определяне на типа на променлива)

Досега най-често примерите горе все включваха типа на дадена променлива (например val i: Int = 5). Oбаче готиното е, че всъщност най-често можеш да го пропуснеш, тъй като компилаторът може да го извлече автоматично от стойността, която си задал.

Например горе i ще е Int, j ще е Long, str ще е String, a list ще е ArrayList<Int>. Това е един от начините, по които кодът, който пишеш на Kotlin, става значително по-кратък.

—

3.2.3. Ranges (диапазони)

Както споменах, в Kotlin нямаме класически for цикъл, но имаме нещо като for-each в Java (for (el : elements) { … }), а ако искаме да достъпваме по индекс в цикъла, използваме възможността за диапазони в Kotlin.

Някои интересни особености са, че когато използваме например 1..4, това означава, че итерираме от 1 до 4 включително. Ако искаме да изключим 4, използваме until. Другото интересно е, че until и downTo не са ключови думи, а пример за т.нар. “infix функции” (обяснено надолу).

Харесва ми, че тези диапазони дават доста голяма гъвкавост (a дори можеш да извикваш и методи, с които да получиш нещо конкретно, което те интересува за диапазона — например сумата от елементите в него, средно аритметичното и т.н.).

—

3.2.4. По-лесно обхождане (и инициализация) на Map

Това е нещо дребничко, но на мен лично много ми харесва. 😆

При обхождане на Map, вместо да се занимаваш с достъпване на map.entrySet() и след това извличане на ключ/стойност, можеш просто да ги подадеш в цикъла и след това да ги достъпиш директно.

Забележи също, че и инициализацията на таблицата е значително по-просто (с наличието на mapOf() метод и Pair клас).

—

3.2.5. Data класове

Това е една от най-любимите ми възможности на Kotlin. Общо взето тези “data” класове ти дават наготово toString(), hashCode(), equals() и конструктор с параметри.

В Java би ти се налагало да ги добавяш ръчно (дори и да са генерирани от IDE-то, което ползваш) или да ползваш Lombok, a това често е неудобно. Все пак, в полза на Java, наскоро открих, че и там вече се предлага нещо такова чрез т.нар. Java “records” (проблемът е, че тази функционалност идва чак от Java 14 нататък, a понякога не е толкова просто да вдигнеш версията на Java в проекта си). 😅

Типично за Kotlin, имаш и добра гъвкавост по отношение на това, което ИСКАШ да ползаш от тези data класове (например имаш възможността да не включваш определени полета в автоматично генерираните методи и в конструктора).

Друг готин бонус е copy() методът, който получаваш, ако създадеш data клас. Този метод ти позволява лесно да създадеш нов обект, който е почти същия като друг (лесно можеш да нанесеш някаква малка промяна, а всичко друго си остава както си е било).

—

3.2.6. Object declarations & “top-level” функции

Друга готина възможност на Kotlin са т.нар. “object declarations”, които ни предоставят нещо като имплементация на Singleton шаблона. Общо взето все едно създаваме обикновен клас, но използваме ключова дума object, a всичко в тялото на този “object” е статично.

Още едно малко готино нещо: можеш да имаш функции, които не принадлежат на никой клас (т.нар. “top-level functions”). След това можеш да използваш тези функции в класовете си.

—

3.2.7. Null safety

Това е може би една от най-съществените възможности на Kotlin: можеш да имаш полета, които не позволяват null стойност (и компилаторът те спира, ако се опиташ да им поставиш такава стойност).

В резултат се налага доста по-рядко да правиш ръчни проверки за null стойност и съответно доста по-рядко се налага да се бориш с NullPointerException.

—

3.2.8. Extension функции

Ако някога ти се е искало String (или който и да е клас) да има определен метод, вече можеш сам да си го създадеш чрез т.нар. “еxtension” функции. По този начин можеш да добавяш нова функционалност в клас, без да ти се налага да го наследяваш.

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

—

3.2.9. Именувани параметри & стойности по подразбиране
(named parameters & default values)

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

Доста удобна функционалност. 😅👍

—

3.2.10. Kotlin изрази (“If-else”, “return”, “when”, “try-catch”, “throw”)

В Kotlin почти всичко е израз. В резултат на това можеш да правиш интересни неща като:

val str = if (num > 10) “hello” else “world” (споменах, че нямаме ternary оператор, а това е алтернативата, която Kotlin предлага)
val numCopy = anotherNum ?: return и val myStr = myNum ?: throw Exception(“Something went wrong…”)
val a = when (something) { … } и val number = try { … } catch (e: Exception) { … }
return if (something) “hello” else “world”

С подобни изрази можеш да намалиш редовете код значително (макар и в началото да е малко трудно за четене 👀). За мен лично писането на код така е много по-удобно (макар в началото да е малко странно и неестествено).

—

3.2.11. Single-expression функции

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

Ако използваш функционално програмиране, това можа да е полезно, защото обикновено там имаме една голяма верига от извиквания на методи.

—

3.2.12. По-прости lambdas & функционално програмиране

Накратко: Kotlin значително опростява ползването на ламбди и функционално програмиране (примерите горе го илюстрират).

Докато в Java често такъв код става сравнително труден за писане и четене, в Kotlin обикновено кодът е по-кратък и по-разбираем (разбирам, че е субективно, но поне това е моето мнение 😅).

Kotlin ти предоставя и някои полезни функции, които улесняват извършването на някои често срещани операции (като например сортиране на списък и променяне на стойност на полета в обект).

—

3.2.13. Гъвкави имена за полета & функции

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

—

3.2.14. “Infix” функции (без точка и скоби)

Infix функциите са функции, които се използват между две променливи. Това понякога прави кода по-лесен за четене и писане, защото се доближава до начина, по който хората комуникираме. Най-простият пример е събирането на 2 числа или пък поставяне на диапазон във for цикъл.

Честно казано най-вероятно няма да ти се наложи да ползваш тази функционалност на Kotlin много, но все пак е още една интересна възможност на езика. 😉

—

3.2.15. Преобразуване на Java код в Kotlin (и обратно) [IntelliJ IDEA]

Преобразуването на Java код в Kotlin (в IntelliJ IDEA) e изключително лесно: просто постави Java код в Kotlin файл, а след това IDE-то ще те попита дали искаш да го конвертираш в Kotlin код. Можеш да преобразуваш и Kotlin в Java като следваш показания горе път в IntelliJ.

Имай предвид, че конвертирането не е перфектно (особено от Kotlin в Java), но все пак е полезно в началотo, когато се опитваш да разбереш как работи Kotlin (по-нататък едва ли ще ти трябва). 😎

—

4. Как да продължиш от тук нататък (полезни ресурси и съвети)

Ето и някои ресурси/идеи, които ми бяха полезни. Може да ги използваш като допълнение на този пост.

4.1. Гледай (за да схванеш основите):

https://youtu.be/5flXf8nuq60 (Kotlin Crash Course by Philipp Lackner)
https://youtu.be/pXdY1B-KVJg (Kotlin Crash Course for Java Developers by Coding Master)
https://youtu.be/7EVXypZDOos (Kotlin for Java Programmers by Venkat Subramaniam)

4.2. Прочети (за по-дълбоко разбиране на нещата):

https://kotlinlang.org/docs/home.html (документация на Kotlin)
… и потърси в Google, ако някоя специфична част от Kotlin не ти е ясна. 😉

4.3. Упражнявай се (за да можеш спокойно да използваш наученото):

Прегледай Kotlin кода в проектите, по които работите (ако има такива).
Опитай се да преобразуваш Java код в Kotlin (и наобратно).
Създай си малък Kotlin проект и експериментирай с него.

—

Това е засега. Успех и have fun! 😎

Използвай силата на “flow”, за да не усещаш как минава времето, когато програмираш (дори и на работа)!

Димитър Трифонов (dvt32) — Sun, 07 Sep 2025 14:13:00 +0000

(Първо публикувано на Jul 23, 2022)

Едно много интересно явление от психологията (което всъщност е много релевантно и в работата/програмирането) е т.нар. “flow”.

Благодарение на това смея да кажа, че почти никога не изпитвам “скука” на работа и всъщност съм доста благодарен за това, че работя като програмист, защото програмирането е сравнително лесен начин да постигнеш този “flow”. Реших да ви споделя някои неща за него, които може да са ви интересни и/или полезни. 😎

“Flow” общо взето е състоянието, в което си погълнат от дейността, която извършваш. Не усещаш как минава времето, не си парализиран от мисли за себе си или за това, което мислят другите за теб. Не мислиш за миналото/бъдещето и т.н. Просто си тук в настоящето и се чувстваш сякаш имаш пълен контрол в това, което правиш.

Според психолога, който е открил това явление (Михай Чиксентмихай), хората сме най-щастливи именно когато умът ни работи активно върху някаква задача, която ни носи развитие и следователно вътрешно удовлетворение. Може да сте го изпитвали, когато играете някоя игра, свирите на инструмент, танцувате, спортувате, решавате тежка умствена задача, погълнати сте от разговора с някой нов интересен човек… или когато програмирате! 😅

Как да навлезеш в т.нар. “flow”? Процесът е прост (но не задължително лесен). Нужни са 4 неща:

Задача, която отговаря на уменията ти (не е нито прекалено трудна, нито прекалено лесна)
Ясна цел от задачата (трябва да знаеш към какво ТОЧНО се стремиш, защото неясните цели водят до неясни резултати)
Обратна връзка от задачата (трябва ти начин да разбереш дали се доближаваш до завършването на задачата)
Концентрация (не трябва да се разсейваш със странични дейности, иначе няма как да навлезеш във flow)

Пример: да играеш шах. Имаш някакви умения (в случая познаваш правилата на шаха) и играеш с опонент, който е долу-горе на твоето ниво (ако е много по-слаб, ще ти е скучно, а ако е много по-добър, ще се сдухаш и откажеш). Целта ти е ясна: да победиш. Имаш обратна връзка: виждаш кои фигури си спечелил, кои си загубил, наблюдаваш царя на дъската и вътрешно усещаш дали се приближаваш към победата. Фокусиран си само върху играта. Играейки с тези условия налице, ще бъдеш погълнат от играта и няма да усетиш как времето минава.

По същия начин работят нещата и в контекста на програмирането:

1. Първо имаш някакви умения.

Например запознат си с основните принципи на програмирането, познаваш някой език за програмиране, също така някой framework и т.н.

2. Второ имаш някаква ясна задача, която отговаря на уменията ти.

Например да имплементираш някоя нова функционалност в проекта, по който работиш. Обаче задачата не е твърде лесна, нито твърде трудна — знаеш какво точно трябва да свършиш, знаеш КАК да го свършиш и това е предизвикателно, но не чак до такава степен, че чак да се парализираш.

3. Получаваш обратна връзка.

Тестваш написания код и виждаш дали това, което си свършил, работи. Ще видиш какво казват компилаторът, unit тестовете ти, REST заявките ти, а и самото приложение (така ясно виждаш дали нещата са станали както искаш). Дори и да получиш съобщение за грешка, това ти дава насока как да продължиш напред.

4. Концентриран си.

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

А какво да правиш, когато задачата е твърде лесна или твърде трудна? Споменатото горе звучи супер, но е оптимална ситуация. На практика често задачите на работа са или твърде лесни/прости/монотонни (например рефакторирай 1000 неща в кода) или трудни/неясни (например “имплементирай ей тази функционалност, обаче в Jira ticket-a няма подробности и само един човек знае как точно ще стане това, което се опитваме да направим”).

Когато е задачата е твърде лесна (или може би по-скоро твърде ПРОСТА, за да ангажира ума ти дълбоко), аз обикновено редувам работата по нея с нещо странично. Малко работя по скучната задача, малко превключвам към нещо друго свързано с програмиране: някой курс/книга/видео или дори друга задача от backlog-a. Така работата по първоначалната задача става малко по-поносимо и малко по малко се приближавам към завършването й. 😅

Ако задачата е твърде трудна/сложна/неясна, приоритет ми става раздробяването й на малки части и изясняване на макс всичко по нея, което не ми е ясно. Ако дори и след това пак ми се струва малко “too much”, редувам работата по нея с нещо по-простичко. Така, отново, малко по малко се движа напред към завършването й.

Това е засега. Може да прочетете още за това явление в книгата “Поток” на Михай Чиксентмихай (на английски “Flow” на Mihaly Csikszentmihalyi). Успех! 😎

Участвай в състезания за програмиране (олимпиади, hackathons и други)!

Димитър Трифонов (dvt32) — Sun, 07 Sep 2025 14:09:37 +0000

(Първо публикувано на Jul 10, 2022)

Мисля, че когато си студент и учиш софтуерно инженерство (или “компютърни науки”, “информатика” и т.н.), един от най-лесните и подценени начини да изпъкнеш по положителен начин (както пред преподавателите ти, така и по-нататък, когато си търсиш стаж или работа)… е да участваш в различни състезания свързани с програмиране! 😎

Спомням си, че в университета всички преподаватели споменаваха и се опитваха да ни убедят да се запишем за X олимпиада, Y hackathon, Z състезание, но почти никой студент не искаше да участва. Сякаш единствените хора, които искаха да участват, бяха тези, които преди студентските си години имаха някакъв опит с такива състезания и знаеха, че ще се справят и тук. 😅

Един от основните проблеми (според мен) беше, че макар да ни предлагаха да участваме в различни състезания, никой не ни обясни ЗАЩО участването всъщност е в наша полза. Моята гледна точка тогава беше “Не стига, че трябва да ходя на лекции/упражнения всеки ден и да уча за изпити, а сега ми предлагат да идвам събота на някаква тъпа олимпиада? Какъв е смисълът?” За щастие имах добри ментори онлайн, които ми помогнаха да забележа колко заблудено виждах нещата тогава.

ОК, защо е полезно да участваш? Просто е: когато участваш по състезания, след това получаваш много НАГРАДИ, а най-често даже не се изисква да си от първенците в даденото състезание!

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

Сигурно ще те наградят след самото състезание, а по-късно ПАК ще те наградят, когато университетът изброява студентите, които са имали отличия през семестъра (извън оценките им по различните дисциплини). Ако пък си на някое по-сериозно състезание като hackathon, може някоя фирма даже да спонсорира проекта ти (или пък да те вземе на работа)! 😅

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

Друг тип награда е просто самото постижение и уважението, което получаваш благодарение на него. Както споменах в началото, участването в състезание по програмиране е лесен начин да изпъкнеш от тълпата, защото ПОЧТИ НИКОЙ не участва! А всъщност фактът, че почти никой не участва, прави и спечелването по-лесно (например аз не бях чак толкова добър в олимпиадите по програмиране, но тъй като нямах голяма конкуренция в университета, беше сравнително лесно да хвана някое от първите места с минимална подготовка).

Ако ти участваш, дори и да не спечелиш, пак получаваш бонус точки и изглеждаш добре в очите на другите, защото комуникираш, че си някой, който е сериозен и постоянно търси начини и действа, за да стане по-добър (така също ще имаш и нещо като опит, който можеш да добавиш в CV-то си и чрез който можеш да покажеш, че си сериозен кандидат, когато търсиш стаж или първата си работа).

А ако спечелиш, това вече е невероятно и преподавателите (а потенциално и работодателите) ще те познават и уважават повече. Спомням си дори, че един път ме хванаха да преписвам на изпит и щях да загазя доста, но понеже преди това имах репутация на някой, който се отнася сериозно към програмирането, участва по състезания и т.н., ми се размина доста леко.

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

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

Важно е да се отбележи, че на техническите интервюта почти винаги ти дават въпроси/задачи за алгоритми, а тези алгоритми ги упражняваш постоянно, ако ходиш по олимпиади.

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

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

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

Ако сега си студент, не се чуди и се пробвай на някое състезание, а най-вероятно след известно време ще си благодариш за това решение. Успех! 😎

Моят YouTube канал за софтуерно инженерство и soft skills

Димитър Трифонов (dvt32) — Sun, 07 Sep 2025 14:07:06 +0000

(Първо публикувано на May 14, 2022)

Започнах си YouTube канал, в който ще споделям различни неща, които съм научил по пътя си в софтуерното инженерство и са ми помогнали (най-вече на български, но понякога може би и на английски). 😎

https://www.youtube.com/channel/UCgZLUt9_D3j2Q40wm26P5gA

Съдържанието ще включва най-вече неща свързани с кариера и soft skills, но понякога може да включвам и по-техническо съдържание.

Check it out!

Въведение в Docker (на български)

Димитър Трифонов (dvt32) — Sat, 06 Sep 2025 11:52:07 +0000

(Първо публикувано на Apr 9, 2022)

Реших да пробвам нещо малко по-различно. Ще се опитам да обясня как работят някои от най-добрите и интересни (поне според мен 😅) технологии, които съм ползвал до този момент като софтуерен инженер.

Да, най-често технологиите си имат официална документация, която можеш да прочетеш, но забелязвам, че там нещата в доста случаи не са обяснени достатъчно просто, за да ги разбереш от първо прочитане (на мен лично често ми е нужно да прочета обяснение от поне 3–4 места, за да схвана за какво иде реч). Затова ще се опитам да обясня нещата по максимално прост начин.

А защо на български? Защото ми се струва, че няма достатъчно публично достъпни, безплатни, съвременни и качествени ТЕКСТОВИ материали за програмиране на БЪЛГАРСКИ… Вече за щастие има доста клипове на български за програмиране, но като ТЕКСТ не намирам много. Има някои книги, някои повърхностни статии в Wikipedia и тук-там някой blog пост като този… но като цяло писаните материали на български мисля, че не са много. 😅

В университета срещнах някои по-обстойни текстови материали на български (като онлайн лекции и учебници), но бяха вътрешни за университета, често неактуални и/или платени. Да, вярно, че английският се счита за “официален” език в света на програмирането (и навярно без да имаш някакво поне средно добро владеене на английски, трудно ще се оправиш в програмирането)… обаче това според мен не означава, че трябва изцяло да се отказваме от допринасянето за увеличаването на съдържанието, което е достъпно и на български език.

Както и да е… първата технология, която ще разгледам, е Docker. 😎

===

1. Какво е Docker (и как ти помага)

Docker e инструмент, който (най-просто казано) улеснява ПАКЕТИРАНЕТО, ДОСТАВЯНЕТО и ИЗПЪЛНЕНИЕТО на приложенията, които разработваш.

Под “пакетиране” имам предвид, че чрез Docker можеш лесно да поставиш на едно място всичко, от което приложението ти се нуждае, за да работи правилно. След това става лесно приложението ти да бъде изтеглено и подкарано от потребителя (без главоболия за него). На този потребител му трябва само Docker инсталиран, а всичко свързано с приложението ти ще бъде “доставено” и изпълнено през Docker.

Най-вероятно знаеш, че когато създаваш софтуер, имаш фази като “дизайн”, “тестване”, “поддръжка”, “deployment” (вкарване в употреба на приложението, което си разработил) и т.н. Docker ще ти помогне най-вече в тази “deployment” фаза, но може да ти помогне и в разработката (а даже понякога и в тестването на приложението). 😎

—

Може да го кажем и по друг начин: Docker ти помага да разрешиш проблема “На моята машина работи!” (на твоята машина всичко си работи добре, но незнайно защо, на някоя друга машина не работи).

Едно приложение има доста части. Frontend компоненти, backend компоненти, база данни, сървъри, библиотеки, зависимости и т.н. Когато имаш толкова много части, понякога става трудно да подкараш приложението на различни платформи (различен хардуер, различен софтуер, различна конфигурация на средата, в която го подкарваш, и др.). Docker те улеснява именно в подкарването на приложението ти на друга машина.

(Много компоненти, много нещо…)

Понякога може да прочетеш разни инструкции от рода на:

“ОК, за да тръгне приложението, първо инсталирай SQL Server, a след това го стартирай, създай база данни с това име и създай потребител с ей това име (с администраторски права). Ако си на Windows, също инсталирай и конфигурирай това и това, защото иначе няма да работи. След това инсталирай този сървър, пусни го и накрая конфигурирай тези 100 други неща… и след това БИ ТРЯБВАЛО да работи…”

Ако си developer, вероятно ще изпълниш инструкциите, но малко ще се подразниш от неудобния процес. Обаче ако си ПОТРЕБИТЕЛ (някой без някакви дълбоки технически познания), такива инструкции са недопустими и въобще не би се занимавал, освен ако не си пробвал всякакви други алтернативи преди това.

А най-готината част е, когато следваш инструкциите перфектно и накрая ПАК се появяват съобщения за грешки и софтуерът не работи както трябва… 😅

Нещо такова ми се беше случило и на работа. Трябваше да настроя средата си, за да мога да работя по проекта. За целта ми трябваше SQL Server и затова аз го изтеглих (май беше >1.0GB), инсталирах, настройвах… даже трябваше и специален инструмент за връзка към базата данни да инсталирам и конфигурирам.

А в крайна сметка открих, че в проекта има специален файл, чрез който през Docker автоматично се изтегля и изпълнява всичко нужно, за да работи SQL Server както ми трябва на мен. И на практика нямаше нужда да минавам през всичко това в началото (трябваше ми просто да сложа Docker и да изпълня файла с инструкциите в проекта).

2. Как работи Docker?

За да разбереш как работи Docker, нека да вземем няколко примера.

В транспортната индустрия се чудили какъв е най-добрият начин за пренасяне на различни предмети. Тези предмети имат различен размер, форма, изисквания (например някои от тях са по-чупливи). Стигнали до решението да използват т.нар. “контейнери”. Тоест поставят предметите в една кутия, изпращат кутията (без значение дали по въздух, вода и т.н.) и накрая получателят просто отваря кутията и може да използва предметите в нея. Docker работи на същия принцип.

Друг пример: дискетите за игри на 8-битови конзоли като NES/Famicom (още наричани “телевизионна игра” 😅) от миналото. Дискетата съдържа всичко, което ти трябва, за да може играта просто да тръгне, когато я сложиш в конзолата. Може да дадеш дискетата на някой твой приятел, а ако той има конзолата, също може да си пусне играта без проблем. В този пример дискетата е “контейнерът”, а конзолата играе ролята на Docker.

Още един пример (специално за Java разработчици 😅): един JAR файл. Този файл съдържа всичките класове на Java приложението ти. За да стартираш приложението, трябва просто да имаш Java инсталирана на машината си. В този пример JAR файлът е “контейнерът”, а Java (JRE) играе ролята на Docker.

Последно, нека да видим как тази идея работи в самия Docker…

В Docker имаме контейнери (Docker containers), които съдържат всичките неща (компоненти, библиотеки, сървъри, бази данни и т.н.), от които приложението ни се нуждае, за да работи. Стартираме тези контейнери и приложението ни директно работи. Така приложението ни може да работи навсякъде където е инсталиран Docker.

А ето как работи целият процес на практика:

1) За да имаме пуснат контейнер с приложението ни, първо трябва да създадем т.нар. Docker “имидж” (Docker image). Един имидж съдържа всичките библиотеки, компоненти и така нататък, които използва приложението ни. Тези имиджи могат да се съхраняват в онлайн хранилища (repositories) като Docker Hub. От там можеш да изтеглиш имиджи (или да ги “pull-неш” 😅) и да ги използваш в контейнерите, които си създаваш. Docker също предлага управляване на версиите на имиджите (подобно на Git, можеш да публикуваш промени по тях или иначе казано да “commit-ваш”).

(Скрийншот от Docker Hub (интерфейсът може и да се измени, но принципът на работа си остава един и същ 😎))

2) За да създадеш имидж, трябва да създадеш файл с името “Dockerfile” (без разширение е). Този “Dockerfile” представлява прост текстов файл, в който описваме стъпките за създаването на имиджа ни. След това пускаме build през Docker и имиджът ни е създаден.

Представи си го така: Dockerfile e РЕЦЕПТАТА, а имиджът е СГОТВЕНАТА ХРАНА след следването на стъпките в тази рецепта. 😉

(Примерно съдържание на един Dockerfile)

3) Накрая стартираме Docker контейнер от имиджа, който сме създали преди това. Контейнерът е СТАРТИРАНА ИНСТАНЦИЯ на нашия имидж. Когато стартираш контейнер, приложението ти работи и можеш да го използваш. Също така можеш да спреш контейнера и да го пуснеш пак по-късно

Представи си го така (пример от програмирането): ако Docker имиджът е КЛАС, то контейнерът е ИНСТАНЦИЯ на този клас. 😎

(Примерни контейнери, които включват различни компоненти.)

3. Архитектура на Docker

На този етап може да се чудиш “Това не е ли същото като да пусна виртуална машина?” или “Защо просто не използвам виртуална машина?”. За да отговорим на тези въпроси, трябва първо да разберем вътрешната структура на Docker. A за да разберем нея, трябва да разберем разликите между термините “виртуализация” (virtualization) и “контейнеризация” (containerization).

Първо имаме ВИРТУАЛИЗАЦИЯ, която се използва във виртуалните машини (VM):

Имаме Host OS (операционна система “домакин”), което е операционната система, която използваме, за да стартираме VM.
Имаме Hypervisor, който представлява емулатор, който ни позволява да стартираме виртуални машини с различна операционна система (Guest OS или операционна система “гост”).
Когато стартираме VM, Guest OS-ът не използва компонентите (файловете, приложенията и така нататък), които се намират на Host OS-a.

След това имаме КОНТЕЙНЕРИЗАЦИЯ, която използваме в Docker:

Host OS-ът е операционната система, която използваме, за стартиране на контейнери.
Вместо Hypervisor и VM с Guest OS, използваме Container Engine, който използва компонентите на Host OS-a ни, за да стартира нашите приложения (заедно със зависимостите им) в контейнери.

(ВИРТУАЛИЗАЦИЯ (отляво) и КОНТЕЙНЕРИЗАЦИЯ (отдясно))

Когато използваме ВИРТУАЛИЗАЦИЯ, размерът на заделените ресурси (пространство, памет) за виртуалните машини е фиксиран и не се променя според специфичните изисквания на нашето приложение. Има доста overhead (тоест излишно хабим ресурси, за да подкараме приложението си).

Когато използваме КОНТЕЙНЕРИЗАЦИЯ, размерът на заделените ресурси НЕ Е фиксиран и може да се промени според нуждите на приложението ни. Контейнеризацията е лека (не товари много от гледна точка на ресурси) и бърза. Поради тази причина Docker e доста по-подходящ за нашите цели.

—

Все пак трябва да се отбележи, че Docker НЕ Е магическо решение за съвместимост! Например ако се опитваш да пуснеш Windows приложение през Docker на Linux, ще трябва първо да добавиш виртуална машина с Windows, за да се получат нещата. Ако се опитваш да стартираш Linux приложение под Windows, същото важи (хубавото е, че Docker предоставя вградена Linux виртуална машина, която може да използваш; даже още по-добре, може да използваш новата технология WSL2 на Microsoft).

Една много готина възможност на контейнеризацията и Docker e т.нар. “изолация”. Това означава, че всяко приложение работи в собствен контейнер и не влияе на други Docker приложения/контейнери или на компонентите на Host OS-a. В резултат на това, дори когато неминуемо трябва да използваш виртуална машина, няма да ти се налага да създаваш отделна такава за всяко приложение, което стартираш.

—

Docker има “клиент-сървър” архитектура. Клиентът е Docker CLI, а сървърът се нарича Docker Daemon. Този Daemon получава инструкции от CLI под формата на команди в конзолата или REST API заявки. Ако си спомняш от написаното горе, в контейнеризацията имахме “Container Engine”. E, при Docker това е Docker Engine, който съдържа CLI и Daemon. Една интересна особеност е, че Docker клиентът и сървъра могат да са на една машина, но могат да бъдат и на различни такива.

4. Задълбаване в Docker

Ако си developer, най-вероятно ще ти е достатъчно да знаеш за споменатите вече имиджи, контейнери и общата архитектура на Docker. Обаче ако искаш да задълбаеш в Docker за забавление (или ако искаш да поемеш по “DevOps” пътя), ето още малко информация за някои по-сложни концепции, които ще ти помогнат да стигнеш следващото ниво. 😉

Ще разгледаме набързо Docker Volumes, Docker Compose и Docker Swarm Mode.

4.1. Docker Volumes

Когато създаваш Docker контейнери, често тези контейнери ще съдържат някакви данни (например имаш контейнер за база данни).

Тези данни се съхраняват във виртуална файлова система (Virtual File System или накратко “VFS”), която е вътре в самия контейнер.

Обаче ако изтриеш контейнера, данните ти също се изтриват, а това очевидно не е добре. Механизмът на Docker Volumes ти предоставя решение именно за този проблем.

Ето как работи механизмът:

Твоят Host OS си има своя файлова система (Host File System или наркратко “HFS”). Този “HFS” съдържа всичките папки и файлове, които имаш на компютъра си.
Свързваме папка от HFS с VFS (или казано по-точно, “mount”-ваме HFS папката във VFS). Така, когато имаме някакви файлови промени на VFS, тези промени автоматично се добавят и на HFS-a (същото важи и наобратно).
Данните ти си остават налични и ползваеми, дори и да изтриеш контейнера, на който са били.

Също така можеш да СПОДЕЛЯШ данни между контейнери като свържеш папка от HFS с множество контейнери.

Обобщено казано, Docker Volumes e функция на Docker, която се използва за отделяне на данни генерирани в контейнер и за споделяне на тези данни с други контейнери.

А как да използваш Docker Volumes? Просто изпълняваш Docker команди (които ще видиш по-надолу 😉).

—

4.2. Docker Compose

Вече научихме, че с Docker стартираме контейнери, които съдържат компонентите на приложенията ни. Обаче понякога един контейнер има нужда да комуникира с ДРУГ контейнер (както например в софтуерното инженерство имаме microservices, т.е. малки приложения, които комуникират помежду си и заедно постигат някаква обща цел).

Docker Compose е инструмент, който ни позволява лесно да стартираме приложения, които се състоят от множество контейнери, които работят заедно.

Също така Docker Compose е доста полезен за настройване на локална среда за разработка (точно това използвах и в проекта, който споменах в началото горе 😁).

Ето как да го използваме:

Създаваме текстов (YAML) файл наречен “docker-compose.yml”
Във файла дефинираме “services” на нашето приложение, използвайки специален синтаксис.
Може да си представиш тези “services” като различни части на приложението ти. За всеки service описваш какво трябва да се случи, когато цялото приложение стартира.
Изпълняваме командата “docker-compose up”, за да стартираме приложението ни, което се състои от множество контейнери (и изпълняваме “docker-compose down”, за да го спрем).

(Съдържание на примерен “docker-compose.yaml” файл (Wordpress и база данни, която използва))

—

4.3. Docker Swarm Mode

Следващото ниво е различни Docker машини да комуникират помежду си.

Docker Swarm Mode e механизъм за управляване на група от машини (наричана “cluster”), които използват Docker и работят заедно (а тази група се нарича “swarm”).

Това е инструмент за управляване на контейнери (“container orchestration” инструмент, подобен на Kubernetes) и по-точно инструмент за управляване на МНОГО контейнери. 😅 Той улеснява правенето на неща с контейнери в по-голям мащаб (като наблюдаване на “здравето” на контейнерите ни, актуализации на контейнерите, сигурност, разпределение на ресурси, връщане към стара версия, deployment, scheduling и т.н.).

Ето как работи:

Всеки swarm се състои от “nodes” (машини, на които работи Docker и които са част от cluster-a).
Има 2 типа:
— A) “manager node” (мениджър) — машина, която казва на “worker nodes” какво да правят и следи прогреса им по различните задачи (т.е. тази машина управлява нашия swarm).
— B) “worker nodes” (работници) — машини, които стартират контейнери на нашето приложение; те получават инструкции от manager node-a и му докладват за статуса на задачите.
Изпращаме “services” на manager node-a.
Тези services са дефиниции на това, което искаме да постигнем (т.е. кои Docker имиджи да използваме и какво да правим с тях след това).
Manager node-ът изпраща “tasks” (задачи) на worker node-овете, а те ги изпълняват.
Тези tasks са самите стъпки за постигане на това, което сме дефинирали в нашите services (т.е. това са Docker контейнерите и командите, които трябва да се изпълнят в тези контейнери).

(Забележи, че и мениджърът може да има задачи, защото по подразбиране той също е и работник. 👀)

А как да използваш Docker Swarm Mode на практика? Отново, просто изпълняваш някои Docker команди (някои от тях са споменати надолу 😉).

5. Практически примери

Нека да видим:
5.1) Някои основни команди в Docker
5.2) Как да използваме имиджи
5.3) Kaк да използваме контейнери
5.4) Как да използваме “Dockerfile”
5.5) Как да използваме volumes
5.6) Бърз поглед към Docker Compose & Docker Swarm Mode
5.7) Бърз поглед към Docker Desktop, Docker под Windows (с WSL2) и Podman

5.1. Някои основни команди в Docker

docker

Всяка команда в Docker започва с docker. Ако напишеш само docker и изпълниш командата (в CMD/PowerShell или каквото ползваш като терминал), ще видиш списък с възможните изпълними команди в Docker.

docker version

Показва коя е инсталираната версия на Docker и информация за някои компоненти, които се използват от Docker.

docker -v (или docker --version)

Показва само версията на инсталирания Docker.

docker info

Показва системна информация свързана с Docker

docker images --help

Като добавим --help в края на някоя команда, можем да видим за какво и как се използва тя.

docker system df

Показва колко на брой имиджа, контейнера и т.н. имаме (както и размера им).

—

5.2. Как да използваме имиджи

За най-простия пример можем да изпълним просто docker run hello-world. С тази команда директно стартираме контейнер от имиджа “hello-world”. Понеже все още нямаме този имидж, Docker първо го търси локално, а след това го изтегля от Docker Hub и стартира контейнер от него. Накрая виждаме съобщение от самия контейнер, който успешно е бил пуснат.

Ако искаме да видим всички имиджи, които имаме изтеглени в момента, можем да изпълним командата docker images. Там се вижда размера на всеки имидж, версия и т.н.

Ако желаем да изтеглим някой специфичен имидж, просто изпълняваме docker pull my-image (където “my-image” e името на имиджа, който искаме да изтеглим). Например ако искаме да изтеглим имиджа на Ubuntu, изпълняваме docker pull ubuntu. Ако искаме да изтеглим специфична версия на този имидж, изпълняваме docker pull ubuntu:18.04 (двоеточие и версия, за която сме видели в Docker Hub страницата, че съществува).

Обикновено всеки имидж си има някакъв специфичен начин, по който се изпълнява след това, за да може контейнерът да работи както очакваме. Например за Ubuntu командата е docker run -it ubuntu (в случая казваме да се стартира контейнер от Ubuntu имиджа в интерактивен режим, за да можем да въвеждаме команди след това).

Ако искаме да изтрием някой имидж, просто изпълняваме docker rmi image-name. Ако съществува контейнер, който ползва този имидж, тази команда няма да проработи и ще трябва да изпълним docker rmi -f image-name (алтернативно можем първо да махнем контейнера и след това отново да изпълним първата команда за изтриване на имидж).

—

5.3. Kaк да използваме контейнери

Две полезни команди са docker ps (показва стартираните контейнери в момента) и docker ps -a (показва всички контейнери, които имаме).

Стартирането на контейнер става както вече споменахме (използваме docker run my-image). По подразбиране получаваме случайно име на контейнера, а затова можем сами да си зададем име, ако желаем, с docker run --name my-container my-image (където “my-container” e името, което сме избрали: отделните думи обикновено ги разграничаваме с тире или долна черта).

Ако сме спряли контейнера, можем по-късно да го пуснем отново чрез docker start my-container. Ако искаме да спрем контейнера, използваме docker stop my-container (за “грациозно” спиране, тоест контролирано такова, подобно на спиране на програма през “Exit” или “X” бутона й) или docker kill my-ubuntu (за рязко спиране, подобно на това да спреш някоя програма през Task Manager на Windows 😅).

Ако например си изпълнявал командите с примера за Ubuntu, може да забележиш, че макар с docker start да стартираш контейнера отново, не влизаш в самия контейнер и не можеш да правиш неща вътре в него… Затова трябва да използваш docker attach my-ubuntu-container, за да се “прикачиш” към контейнера и да влезеш в него (алтернативно можеш да изпълниш и docker exec -it my-ubuntu-container bash, което ще изпълни командата “bash” в Ubuntu контейнера и отново ще стигнеш точката, в която се зарежда терминала).

Можеш също така да паузираш някой контейнер. Ако например си отворил Ubuntu контейнера (заредил си терминала и можеш да въвеждаш команди там), а след това в нов прозорец изпълниш docker pause my-ubuntu-container и накрая се върнеш към отворения контейнер, ще забележиш, че в терминала не виждаш въведени букви, защото контейнерът е в пауза. Ако махнеш паузата с docker unpause my-ubuntu-container, буквите ще се покажат и отново ще можеш да изпълняваш команди в контейнера.

Изтриването на контейнер става с docker rm my-container. С docker stats my-container можем да видим полезна статистика за контейнера ни.

—

5.4. Как да използваме “Dockerfile”

Dockerfile, както споменахме, е просто текстов файл с инструкции за изграждане на имидж. Този файл използва специален синтаксис, който можеш да видиш тук: https://docs.docker.com/engine/reference/builder

Съдържанието на един изключително прост такъв файл може да изглежда ето така:

FROM ubuntu
RUN apt-get update
CMD [“echo”, “Hello from my new image!”]

Какво се случва? С FROM поставяме началната точка за имиджа ни. Започваме от вече съществуващия имидж “ubuntu” (ако искаме да започнем от нулата, можем да използваме специалния имидж “scratch”) и след това чрез RUN казваме “Изпълни ей тази команда, докато се build-ва моя нов имидж!”, а чрез CMD казваме “Изпълни ей тази команда с ей тази стойност, когато стартирам контейнер с новосъздадения ми имидж!”.

Самото създаване на имиджа става чрез командата docker build -t my-image:1.0 . (посочваме име и версия на имиджа ни, а с точката казваме, че Dockerfile се намира в текущата ни директория). След това можем да стартираме контейнер от имиджа ни по вече познатия ни начин с docker run.

—

5.5. Как да използваме volumes

Командите свързани с Docker Volumes започват с docker volume (изпълнявайки тази команда може да видим какво реално можем да правим с тези volumes). Можем лесно да създадем volume чрез docker volume create my-vol (където “my-vol” е името на нашия volume), a след това да получим информация за този volume чрез docker volume inspect my-vol. Можем да видим и списък с всичките налични volumes чрез docker volume ls.

Когато изпълним командата за получаване на информация за даден volume, най-интересната част е “Mountpoint”, която ни показва директорията, в която на нашия HFS се пазят данните на този volume (трябва да се отбележи, че на Windows директорията се различава от това, което изписва Docker; директорията всъщност е \\wsl$\docker-desktop-data\version-pack-data\community\docker\volumes\).

А сега как да използваме този volume? Лесно. Просто стартираме контейнер по вече познатия ни начин с docker run, но подаваме -v аргумент (или --volume). Ето един пример с BusyBox:

docker run --name my-busybox -it -v my-vol:/app busybox

Забележи частта my-vol:/app, чрез която свързваме директория от HFS с директория от VFS. Първо подаваме директорията на HFS (в случая просто подаваме името на нашия volume, но може да подадем и някава директория като /path/on/host), a след : подаваме директория от VFS (в случая това е папката app, която съществува вътре в BusyBox контейнера).

Ако си стартирал контейнера, може да отидеш в app папката (като изпълниш cd app вътре в контейнера) и да създадеш един прост текстов файл там (чрез echo "Hello World!" >> hello-world.txt). Изпълни и ls след това, за да се убедиш, че файлът е бил създаден. Накрая излез от контейнера чрез командата exit и отвори HFS директорията на твоя volume (тази, която получихме горе чрез docker volume inspect). Какво ще видиш там? Именно файла, който току-що създаде в контейнера! Готино, нали? 😁

А сега пробвай следното: изтрий контейнера, който създаде (изпълни docker rm my-busybox), и стартирай нов по същия начин (например docker run --name my-new-busybox -it -v my-vol:/app busybox). Отиди отново в app папката чрез cd app и какво ще откриеш? Файлът, който създаде по-рано (hello-world.txt), все още си е там! Това е така, защото ние изтрихме първия контейнер, но нашият volume все още си съществува и съответно данните в него също (и тези данни могат да бъдат преизползвани в нов контейнер).

Ако стартираме още един такъв контейнер (docker run --name my-last-busybox -it -v my-vol:/app busybox) и повторим горната процедура, ще забележиш, че и третият контейнер има достъп до данните в нашия volume. По този начин можем да споделяме данни между нашите контейнери.

Вече имаме постигната синхронизация между HFS и VFS. Пробвай например да преименуваш файла в HFS директорията: ще откриеш, че след това е преименуван и вътре в контейнерите, които го ползват. Аналогично можеш да му правиш промени вътре в контейнерите и след това тези промени ще бъдат отразени в HFS директорията.

Ако изтрием последните два контейнера (чрез docker rm my-new-busybox и docker rm my-last-busybox), данните си остават налични. Чак когато изтрием самия volume (чрез docker volume rm my-vol), данните също ще изчезнат и след това няма да можем да ги използваме в бъдещи контейнери.

—

5.6. Бърз поглед към Docker Compose & Docker Swarm Mode

5.6.1. Docker Compose

Този инструмент, както споменах, може да е доста полезен за настройване на среда за разработка. И както вече загатнахме горе, просто създаваш един файл наречен docker-compose.yaml и в него описваш какво и как искаш да се стартира. Използва се YAML (повече за структурата на файла може да прочетете тук: https://docs.docker.com/compose)

Ето още един примерен файл:

Какво се случва? Общо взето казваме, че искаме да стартираме SQL Server база данни и Mailhog (инструмент за тестване на email изпращане). Казваме кои портове ще използваме, кои имиджи точно ни трябват и т.н. Сега можем да изпълним този файл и да си ползваме настроеното, без да се налага да правим други неща ръчно. Стартираме и можем например да достъпим Mailhog през http://localhost:8025 и да се свържем към базата данни през нашето приложение.

Самото стартиране става чрез изпълняването на командата docker-compose up (в директорията където се намира файла), а спирането става с docker-compose down.

5.6.2. Docker Swarm Mode

Docker Swarm Mode командите започват с docker swarm (и изпълнявайки тази команда ще видиш списък с нещата, които можеш да правиш с този Swarm Mode).

Първата команда, която най-вероятно ще използваш, е docker swarm init, чрез която инициализираш swarm и машината, която е изпълнила командата, се превръща в manager node. След като изпълниш командата ще видиш, че Docker ти изписва как друга машина може да се присъедини като worker (чрез командата docker swarm join) или като manager (чрез docker swarm join-token manager) в новосъздадения swarm.

След това можеш да създаваш services чрез docker service create и да получиш информация за даден service чрез docker service inspect.

Ако искаш да задълбаеш в Docker Swarm Mode, може да следваш урока в сайта на Docker: https://docs.docker.com/engine/swarm/swarm-tutorial/

—

5.7. Бърз поглед към Docker Desktop, Docker под Windows (с WSL2) и Podman

Docker предоставя графичен инструмент наречен Docker Desktop, който прави лесно управляването на контейнерите, които имаме (с него не ни се налага да изпълняваме никакви команди ръчно). Минусът е, че отскоро този инструмент не е безплатен за enterprise приложения (но ако просто си правиш някое твое лично проектче, можеш да си го ползваш без проблем). 😅 Повече за Docker Desktop тук: https://www.docker.com/products/docker-desktop

Заради това, че Docker започнаха да искат пари от фирми, които го ползват за собствените си приложения, сега все по-често хората преминават към Podman. Podman e като заместител на Docker и работи по същия начин (командите са същите, просто не използваме docker, a podman, т.е. например podman ps, podman images и така нататък). Повече за Podman тук: https://podman.io/

Под Windows интересното е, че Docker може или да използва вградена Linux виртуална машина, или новата WSL2 технология на Microsoft, която се счита за по-добрия избор. Струва си да се прочете малко и за това, защото WSL2 като цяло прави подкарването на Linux приложения от Windows значително по-лесно (макар все още да има дразнещи бъгове). Освен това подкарването на Podman под Windows разчита на WSL2. Повече за WSL2 тук: https://docs.microsoft.com/en-us/windows/wsl/about

===

Това е! Дано е било полезно и ако имате някакви въпроси или забележите някоя неточност, напишете коментар. 😉