ARPAnet Posted March 28 Share Posted March 28 Сравнително стандартна ситуация честно казано, пък и мейл клиента, офиса, сториджа не са свързани особено с писането на код ОС-а може да се пречка в някои ситуации Но дори от тази гледна точка, трябва да им се признае на Майкрософт, дават ни и WSL и възможността IDE-то им да работи директно в локален контейнер или отдалечена линукс машина. Гъвкави са и се стараят за девовете Колко често се борите с кубето вие ? Не гледате ли основно логове там, а другото е проблем на линуксаджиите ви? Аз съм свеж от Кубекон, та всичко и навсякъде трябва да е под кубе Quote Link to comment Share on other sites More sharing options...
earache Posted March 28 Share Posted March 28 Защо пък да трябва? Това като с микросервизите... всеки почнал да ги прави, заради самата идея. А цената, която се плаща и която е ОГРОМНА откъм сложност, много лесно взимат решението да я платят. Quote Link to comment Share on other sites More sharing options...
ARPAnet Posted March 28 Share Posted March 28 Но личното ми виждане е, че зависи от организацията и какво има, мисля че от доста години вече не сме във фазата "заради самата идея". Ако вече има тийм занимаващ се с кубе и сте си създали необходимата организация, то деплойването на нови апове в/у него всъщност е по-лесно. За мен всичко което правя през последните 6+ години работи на кубе. Деплоймънта даже не е тема на размисъл вече, модела е повтаряем. Споменатият KVM по-горе, кубе настъпва и там с Kubevirt, просто не подхожда на конкретната ми цел. За тези които тепърва ще тръгват по пътя - занимавка си е и като всичко ново си има процес на проби и грешки, учене. Quote Link to comment Share on other sites More sharing options...
Antares Posted March 28 Share Posted March 28 1 hour ago, ARPAnet said: Колко често се борите с кубето вие ? Не гледате ли основно логове там, а другото е проблем на линуксаджиите ви? Аз съм свеж от Кубекон, та всичко и навсякъде трябва да е под кубе Средата и комплекта от продуктите ни са толкова комплексни, че постоянно ни се налага да променяме нещо. Бъзикам се с шефа ми, че по тасковете ми - 80% от работата обикновено е в дигането на средата. И дори и да съм склонен да преувеличавам - в случая не съм далеч от истината Отделно и в момента сме в етап на подмяна на основния ни BE framework, та почти на всяко нещо работим успоредно с две версии. Иначе да - не си вадя хляба с Teams и Outlook, обаче постоянните им проблеми, ужасното неудобство в ползването им (все пак работя отдалечено, та се налага да общувам с колегите) ми създават понякога повече нерви от бъговете. Отделно Windows ми е толкова безумно неудобен за работа, че може би само iOS може да го бие... Quote Link to comment Share on other sites More sharing options...
ARPAnet Posted March 28 Share Posted March 28 1 hour ago, Antares said: Средата и комплекта от продуктите ни са толкова комплексни, че постоянно ни се налага да променяме нещо. Бъзикам се с шефа ми, че по тасковете ми - 80% от работата обикновено е в дигането на средата. И дори и да съм склонен да преувеличавам - в случая не съм далеч от истината Отделно и в момента сме в етап на подмяна на основния ни BE framework, та почти на всяко нещо работим успоредно с две версии. Това е интересно, че правите толкова промени. И все пак, не е ли е по-лесно да пушваш промените автоматично, просто редактирайки деплоймънта на аппа ти/мрежа/сървиси, вместо да се занимаваш с виртуалки за апп сървъри? Не, че и те не подлежат на доста автоматизация де. 2 hours ago, Antares said: Иначе да - не си вадя хляба с Teams и Outlook, обаче постоянните им проблеми, ужасното неудобство в ползването им (все пак работя отдалечено, та се налага да общувам с колегите) ми създават понякога повече нерви от бъговете. Отделно Windows ми е толкова безумно неудобен за работа, че може би само iOS може да го бие... Ясно, отива към въпрос на вкус Quote Link to comment Share on other sites More sharing options...
mIRCata Posted March 28 Share Posted March 28 7 hours ago, earache said: Това като с микросервизите... всеки почнал да ги прави, заради самата идея. А цената, която се плаща и която е ОГРОМНА откъм сложност, много лесно взимат решението да я платят. В нашата корпорация от около година са на тази вълна. Почнали са пренаписват нещата на микросървиси, да разбиват монолитните приложения на отделни услуги, " че да можело да се ползват от Х модула при нужда, вместо да се пише на всякъде". Още се чудя защо просто не са отделни nuget пакети, и да се инсталират в отделните модули и да се ползват така, ами микросървиси. Хич не ми се мисли как ще трябва да се вдига един проект след това, за една и съща функционалност да се вдигнат няколко приложения/контейнери, да се дебъгва нещо, като нещата ще са на 2-3-4-5 места, кое какво е направило, кое какво е отговорило, кога... абе манджа ще е. Но биг шефове и умни глави са го решили, а знаете кой поръчва музиката. И почвам да чувам, че и на нашия продукт му наближава времето и ще го разколачваме. В момента първо ударно се мигрира към .нет8 и да може да върви с контейнери, до лятото трябва да се смени Azure с Google cloud, ще видим. Quote Link to comment Share on other sites More sharing options...
earache Posted March 29 Share Posted March 29 (edited) Идеално. Звучи като прекрасно място за напускане. Впрочем са закъсняли с едно 10 години. Тогава беше така. В момента почват да отрезвяват лека полека след десетилетие неглижиране на бизнес логика и главоболия по микросервизите, без да е кой знае колко нужна цялататая гимнастика. Edited March 29 by earache Quote Link to comment Share on other sites More sharing options...
Antares Posted March 29 Share Posted March 29 Тоз па К'во им е на микросървисите? Чак па да тръгва да напуска, щото фирмата се опитва да вкара нови технологии... Quote Link to comment Share on other sites More sharing options...
ARPAnet Posted March 29 Share Posted March 29 2 hours ago, earache said: Идеално. Звучи като прекрасно място за напускане. Впрочем са закъсняли с едно 10 години. Тогава беше така. В момента почват да отрезвяват лека полека след десетилетие неглижиране на бизнес логика и главоболия по микросервизите, без да е кой знае колко нужна цялататая гимнастика. А какво общо имат микросървисите с неглижирането на бизнес логиката? Quote Link to comment Share on other sites More sharing options...
earache Posted March 29 Share Posted March 29 (edited) Ограничения капацитет на човешкия мозък. Спираш да обръщаш внимание на едното, за сметка на другото. Затова трябва да се внимава колко от т.нар. accidental complexity си създаваш и дали изобщо е нужно. Хах, пишейки това се сетих за един колега от предишната работа, според когото програмисти трябвало да са само хора гении, така че да могат да държат в ума си възможно най-много детайл заедно с "голямата картина". Хора, с едва ли не неограничен капацитет. Напусна, за да става бизнесмен, но се е провалил май. Явно не гъмжи от гении. Edited March 29 by earache Quote Link to comment Share on other sites More sharing options...
DON_CHEFO Posted March 29 Share Posted March 29 Завиждам ви, че разбирате за кво говорите, а в 8ми клас аз се цупех на Паскала и само Тд 5 и NFS 2 ли беше тая с Ел Ниньото. Quote Link to comment Share on other sites More sharing options...
Antares Posted March 29 Share Posted March 29 39 minutes ago, DON_CHEFO said: Завиждам ви, че разбирате за кво говорите, а в 8ми клас аз се цупех на Паскала и само Тд 5 и NFS 2 ли беше тая с Ел Ниньото. И аз в 8ми клас се цупех на Турбо Парцала, а в 11-ти реших, че съм прекалено тъп за да стана програмист, тъй като не разбирах нищо от c++ Но явно все пак съм бил притежател на нужните отклонения, тъй като сега криво-ляво се справям Quote Link to comment Share on other sites More sharing options...
w00x Posted March 29 Share Posted March 29 1 hour ago, DON_CHEFO said: Завиждам ви, че разбирате за кво говорите, а в 8ми клас аз се цупех на Паскала и само Тд 5 и NFS 2 ли беше тая с Ел Ниньото. За годините, през които го повтаряш това, можеше да се научиш 3 пъти. Quote Link to comment Share on other sites More sharing options...
ARPAnet Posted March 29 Share Posted March 29 4 hours ago, earache said: Ограничения капацитет на човешкия мозък. Спираш да обръщаш внимание на едното, за сметка на другото. Затова трябва да се внимава колко от т.нар. accidental complexity си създаваш и дали изобщо е нужно. Хах, пишейки това се сетих за един колега от предишната работа, според когото програмисти трябвало да са само хора гении, така че да могат да държат в ума си възможно най-много детайл заедно с "голямата картина". Хора, с едва ли не неограничен капацитет. Напусна, за да става бизнесмен, но се е провалил май. Явно не гъмжи от гении. Ясно, но това предполага че проблемите от началната миграция не се решават и си ги влачим във времето, напрактика усложнявайки си допълнително живота. С други думи, някой не си е свършил работата. Но такава миграция не носи само усложнения, има си и екстри. Не броя себе си, че нося много шапки, но тийма ми имат някакви много базови знания за кубе, ползват k9s колкото да си погледнат логовете, а са им достъпни и в графана. Тяхната работа започва и свършва в гит, а в Дженкинс поглеждат пак само информативно. Quote Link to comment Share on other sites More sharing options...
chasti Posted March 29 Share Posted March 29 40 minutes ago, Antares said: И аз в 8ми клас се цупех на Турбо Парцала, а в 11-ти реших, че съм прекалено тъп за да стана програмист, тъй като не разбирах нищо от c++ Но явно все пак съм бил притежател на нужните отклонения, тъй като сега криво-ляво се справям При мен е обратното! Винаги съм знаел, че съм предостатъчно умен, но ме е мързяло да мисля Quote Link to comment Share on other sites More sharing options...
earache Posted March 29 Share Posted March 29 54 minutes ago, ARPAnet said: Ясно, но това предполага че проблемите от началната миграция не се решават и си ги влачим във времето, напрактика усложнявайки си допълнително живота. С други думи, някой не си е свършил работата. За кои проблеми по-точно намекваш? И на какво казваш миграция - контейнеризацията ли? Quote Link to comment Share on other sites More sharing options...
ARPAnet Posted March 29 Share Posted March 29 26 minutes ago, earache said: За кои проблеми по-точно намекваш? И на какво казваш миграция - контейнеризацията ли? Разделянето на кода в микросървиси, преминаването към контейнери и кубе (някой може да си хареса номад ). Тази миграция Която в началото ще донесе нови проблеми, докато всичко се нагласи. От където предполагам идва това: 6 hours ago, earache said: Спираш да обръщаш внимание на едното, за сметка на другото. Затова трябва да се внимава колко от т.нар. accidental complexity си създаваш и дали изобщо е нужно. Но след началният период на нагласяване и свикване - не би трябвало кубернета и използването на микросървиси да отнема от вниманието на дева, определено не и в дългосрочен план. Че да говорим, че заради микросървисите изведнъж няма време да се мисли за бизнес логиката. Quote Link to comment Share on other sites More sharing options...
earache Posted March 29 Share Posted March 29 Аха, загрях, да са еба. Ами то затова имаше един туит, не помня от кой беше, "ако кода ти е лайно, добавянето на заявки по мрежата няма да помогне". Но като цяло за какво да си го причиняваш цялото това нещо, дори временно преболедуване, ако нямаш нужда? Под "имам нужда" разбирай "ние сме Амазон, 200 човека екип чоплим по едно и също репо и не върви работата" - тогава разбирам да тръгнеш да го правиш. 4 човек екип, да прави повече от един микросервиз е някво... безсмислено. Quote Link to comment Share on other sites More sharing options...
ARPAnet Posted March 29 Share Posted March 29 1 hour ago, earache said: Ами то затова имаше един туит, не помня от кой беше, "ако кода ти е лайно, добавянето на заявки по мрежата няма да помогне". Няма, но и проблема няма да е мрежата 1 hour ago, earache said: Под "имам нужда" разбирай "ние сме Амазон, 200 човека екип чоплим по едно и също репо и не върви работата" - тогава разбирам да тръгнеш да го правиш. 4 човек екип, да прави повече от един микросервиз е някво... безсмислено. Не само тогава Има си и чисто практически плюсове в микросървисите които са независими от броят хора, - Вътрешни неща като репорти/експорти/инвентари и всякакви подобни задачки могат да се релийзват спокойно по всяко време, без да мисля крайни юзъри. - Уеб интерфейсите и сървисите които се ползват от юзърите за да си вършат работата - там трябва да се предупреждава, съобразяване с време и т.н. Което е досадно. - Тестовете са бързи, не тествам всеки пък "всичко", а конкретният сървис. Докато не счупвам output-а и очакванията на input–а - всичко е наред. - Споменаха се пакети по-горе. Удобни са, но не ги предпочитам за всичко. По-лесно ми е да оправя бъг в сървис и да го релийзна и всичко което го ползва да получи на практика фикса в този момент. Пред това да оправя пакета и да ъпдейтна всички зависими сървиси след това. Но за неща като ORM и подобните, разбира се ползвам пакети. - Структурата на сървисите е сравнително простичка, правейки ги лесни за четене и ориентиране. - Не е плюс конкретно на микросървисите, но АПИтата са задължителни, всичко се включва мрежово. Което прави интеграцията с друг софтуер много лесна. Монолита също може да има АПИ-та и т.н., но там не са задължителни, съответно може и да се пропуснат. Контейнерите носят и други плюсове - Създаването на сателити става много лесно например Дори и без кубе, лесно ми е да отида при вътрешното ИТ например, които по принцип не ме поддържат, да си поискам 2-3 виртуалки и да си вдигна това което искам. А те нека си пачват и правят каквото искат след това, нямам зависимост към техните пакети и среда, стига да не счупят функционално виртуалките. - Вдигането на всичко става много лесно, и работи навсякъде, лаптопи, билд машини. Съответно упражнения като DR също са лесни, знам че моят апп ще се вдигне - Релийзите са лесни, щом работи на моят лаптоп, ще работи и в дев/стаг и прод. Не мисля дали няма различни пакети, версии, странни конфизи и т.н.. - Искаш нова среда за определен feature? Автоматично е, дефинирай си я в гит. - Хоризонталният скейлинг става лесен, а "умирането" става по-трудно. Възстановяването е бързо при контейнерите, доста по-бързо от това на виртуалка. - Ъпдейтването е лесно, за минути съм на новата версия. За сравнение имам апп който работи на няколко хиляди виртуалки в над 100 държави- различни версии на всичко и т.н., и не е контейнер... неприятна история Quote Link to comment Share on other sites More sharing options...
DON_CHEFO Posted March 29 Share Posted March 29 6 hours ago, w00x said: За годините, през които го повтаряш това, можеше да се научиш 3 пъти. Вече съм на вълна пенсия. Нито работа, нито кариера ме интересуват. Не искам и да чуя за нови квалификации и тн(а и нямам и времето) . Искам да си утроя акаунта и да напусна като по филмите... Псувни и средни и пръсти. Quote Link to comment Share on other sites More sharing options...
mIRCata Posted March 29 Share Posted March 29 14 hours ago, earache said: закъсняли с едно 10 години Банкова работа. Скоро имахме писмо да избягваме AI инструменти, помощници и т.н. Вчера дойде имейл за ново обучение по повод точно AIто. Може или да са си сменили мнението или пък съвсем да са решили сега да не се ползват. Ще видя другата седмица. Quote Link to comment Share on other sites More sharing options...
earache Posted April 1 Share Posted April 1 (edited) On 3/29/2024 at 7:41 PM, ARPAnet said: Не само тогава Има си и чисто практически плюсове в микросървисите които са независими от броят хора, Повечето са решими с екстремно програмиране, на цена в пъти по-ниска. On 3/29/2024 at 7:41 PM, ARPAnet said: - Вътрешни неща като репорти/експорти/инвентари и всякакви подобни задачки могат да се релийзват спокойно по всяко време, без да мисля крайни юзъри. Това изглежда свързано с количеството промени във всяка нова версия. Могат да се ограничат максимално със CI/CD (не просто pipeline), после не мислиш никого, не само крайните потребители. On 3/29/2024 at 7:41 PM, ARPAnet said: - Уеб интерфейсите и сървисите които се ползват от юзърите за да си вършат работата - там трябва да се предупреждава, съобразяване с време и т.н. Което е досадно. То и при наличие на микросервизи трябва да ги предупредиш. On 3/29/2024 at 7:41 PM, ARPAnet said: - Тестовете са бързи, не тествам всеки пък "всичко", а конкретният сървис. Докато не счупвам output-а и очакванията на input–а - всичко е наред. Не пречи да се направят subsuites от тестовете, примерно за всеки модул отделен. Също има шанс да са много бавни тестовете, в който случай трябва да се гони точно това - скоростта им. On 3/29/2024 at 7:41 PM, ARPAnet said: - Споменаха се пакети по-горе. Удобни са, но не ги предпочитам за всичко. По-лесно ми е да оправя бъг в сървис и да го релийзна и всичко което го ползва да получи на практика фикса в този момент. Пред това да оправя пакета и да ъпдейтна всички зависими сървиси след това. Но за неща като ORM и подобните, разбира се ползвам пакети. Цената не е оправдана за толкова дребно предимство. On 3/29/2024 at 7:41 PM, ARPAnet said: - Структурата на сървисите е сравнително простичка, правейки ги лесни за четене и ориентиране. Тя и структурата на модулите в монолита може да е простичка. Няма пречка. On 3/29/2024 at 7:41 PM, ARPAnet said: - Не е плюс конкретно на микросървисите, но АПИтата са задължителни, всичко се включва мрежово. Което прави интеграцията с друг софтуер много лесна. Монолита също може да има АПИ-та и т.н., но там не са задължителни, съответно може и да се пропуснат. Когато имаш такова изискване, то е важно само по себе си, макар и да не е функционалност. BDD може да се бутне тука за разработка отвън навътре (от API към ядро). Има и една книга по темата - Growing object oriented software, guided by tests. --- Виж това: Този Сам ги е измислил микросервизите. Фаулър го пита за 3 най-добри причини да разбиеш монолит на микросервизи. Пича отговаря, а Фаулър даже дисва първата причина. --- Офтопик: Охх как се цепеше цитат тука бе? Тия не знаят за principle of least astonishment. Edited April 1 by earache Quote Link to comment Share on other sites More sharing options...
ARPAnet Posted April 1 Share Posted April 1 (edited) On 4/1/2024 at 8:32 AM, earache said: Повечето са решими с екстремно програмиране, на цена в пъти по-ниска. Момента с цената звучи интересно поставен до "екстремно програмиране". Интервюто от линка всъщност дава добър пример с модулите, че перфектно и екстремно могат да са сравнително трудни за налагане в дългосрочен план. Но да, зависи от ситуацията в която се намира човек, цената може да е много различна. Аз съм лесен, не съм мигрирал от монолит към микросървиси, а започнах на чисто. On 4/1/2024 at 8:32 AM, earache said: Това изглежда свързано с количеството промени във всяка нова версия. Могат да се ограничат максимално със CI/CD (не просто pipeline), после не мислиш никого, не само крайните потребители. Change management, релийза си е релийз и важното нещо е дали може да е service affecting или не(поне в моят свят) On 4/1/2024 at 8:32 AM, earache said: То и при наличие на микросервизи трябва да ги предупредиш. Дам, не ми се получи добре оформлението, това беше като противоложен пример на предишния ред. Разделяйки различните функции в отделни сървиси, мога да правя релийзи които не засягат юзърите, а типа релийзи (change) които ги засагят се намаляват и си оляснявам живота от чисто административна гледна точка On 4/1/2024 at 8:32 AM, earache said: Не пречи да се направят subsuites от тестовете, примерно за всеки модул отделен. Също има шанс да са много бавни тестовете, в който случай трябва да се гони точно това - скоростта им. Това че се отделни как помага? Тестовете ръчно ли ги пускате ? Защото за мен се рънват за всеки комит, преди да бъде деплойнат, съответно биха вървели всички. Вероятно пропускам нещо. On 4/1/2024 at 8:32 AM, earache said: Виж това: Хубаво интервю на Сам. Като цяло дават добри аргументи, и двамата. И определено това към което клоним зависи от личния ни опит и софтуера който ни заобикаля. За мен най-честият проблем е, че от даден момент не може да scale up-ваш до безкрай, трябва да можеш и да scale out-ваш, който scale out става доста скъп(от към ресурси) ако копираш всичко Х пъти. От там и предпочитанията ми Цитатите са досадни, особено на телефон Edited April 2 by ARPAnet Quote Link to comment Share on other sites More sharing options...
earache Posted April 2 Share Posted April 2 On 4/1/2024 at 1:54 PM, ARPAnet said: Момента с цената звучи интересно поставен до "екстремно програмиране". Интервюто от линка всъщност дава добър пример с модулите, че перфектно и екстремно могат да са сравнително трудни за налагане в дългосрочен план. Не съм сигурен, че ме разбра. Под екстремно програмиране имах предвид extreme programming (XP) (Continuous Integration - поне веднъж дневно, TDD, Pair programming, tests as spec, tests as doc). On 4/1/2024 at 1:54 PM, ARPAnet said: Change management, релийза си е релийз и важното нещо е дали може да е service affecting или не(поне в моят свят) Няма ли тестове, които да го следят това? Аз така бих процедирал. On 4/1/2024 at 1:54 PM, ARPAnet said: Дам, не ми се получи добре оформлението, това беше като противоложен пример на предишния ред. Разделяйки различните функции в отделни сървиси, мога да правя релийзи които не засягат юзърите, а типа релийзи (change) които ги засагят се намаляват и си оляснявам живота от чисто административна гледна точка Щом ти се занимава, няма те спирам, хаха. Аз им правя тестове, както казах, пинват поведението на API и гърмят, ако нещо е променено. Промените по вътрешните одити следва да не ги чупят тия тестове. On 4/1/2024 at 1:54 PM, ARPAnet said: Това че се отделни как помага? Тестовете ръчно ли ги пускате ? Защото за мен се рънват за всеки комит, преди да бъде деплойнат, съответно биха вървели всички. Вероятно пропускам нещо. Мисля, че пропускаш това, че тестовете се въртят на всеки ctrl+s. Няма проблем да са само част от тестовете (за предпочитане unit, че са най-бързи). Всичките пък се въртят при пуш в trunk. Пак не трябва да са двучасови. 10-15 минути макс за всичките, иначе страдаме от бавни тестове. On 4/1/2024 at 1:54 PM, ARPAnet said: Хубаво интервю на Сам. Като цяло дават добри аргументи, и двамата. Аз бих диснал и 2рия use case, за data partitioning. Не знам защо Фаулър не го изяде и него с парцалите. On 4/1/2024 at 1:54 PM, ARPAnet said: И определено това към което клоним зависи от личния ни опит и софтуера който ни заобикаля. За мен най-честият проблем е, че от даден момент не може да scale up-ваш до безкрай, трябва да можеш и да scale out-ваш, който scale out става доста скъп(от към ресурси) ако копираш всичко Х пъти. От там и предпочитанията ми Ма монолита може да се скалира аут (хоризонтално)... В предишната ми работа така се правеше. Просто ако имаш база, тя става само за вертикално скалиране. Quote Link to comment Share on other sites More sharing options...
ARPAnet Posted April 2 Share Posted April 2 3 minutes ago, earache said: Не съм сигурен, че ме разбра. Под екстремно програмиране имах предвид extreme programming (XP) (Continuous Integration - поне веднъж дневно, TDD, Pair programming, tests as spec, tests as doc). Аха, разбрах М/у другото, наистина ли правите Pair programming–а ? 7 minutes ago, earache said: Няма ли тестове, които да го следят това? Аз така бих процедирал. Change Management като процес за релийз в компанията. Чиста бюрокрация 22 minutes ago, earache said: 10-15 минути макс за всичките, иначе страдаме от бавни тестове. +1 Но понеже в другата тема преди време се даваха примери с тестове вървящи с часове и дни.. 23 minutes ago, earache said: Ма монолита може да се скалира аут (хоризонтално)... В предишната ми работа така се правеше. Просто ако имаш база, тя става само за вертикално скалиране. Може но го копираш целият, вместо само частта която трябва да расте. Съответно имаш едни "дебели" копия с всичко излишно вървящо с тях, и със съответните изисквания за ресурс само за да се вдигнат. Тук трябва да отворя голяма скоба, че следващото е базирано на опита ми като клиент на софтуер. Опита ми показва, че много често scale out-a липсва или е недомислен с неща от типа - ами рънвайте отделни копия и разделете клиентите помежду им (примерно). А много често и отговора е - еми сори, ама ударихте лимита Неща като сателити, когато са необходими - hit and miss е ситуацията, ако държиш всичко да работи и менажира от едно централно място. И заради това се старая за моят софтуер да съм максимално гъвкав и scale out–а за мен да е само промяна на броя реплики, днес са 8 утре са 20. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.