Drejtori i Operacioneve të portalit Banki.ru Andrey Nikolsky foli në konferencën e vitit të kaluar në lidhje me shërbimet për jetimët: si të identifikoni një jetim në infrastrukturë, pse shërbimet për jetimët janë të këqija, çfarë të bëni me ta dhe çfarë të bëni nëse asgjë nuk ju ndihmon.
Më poshtë prerjes është një version tekstual i raportit.
Përshëndetje kolegë! Emri im është Andrey, unë drejtoj operacionet në Banki.ru.
Ne kemi shërbime të mëdha, këto janë shërbime të tilla monolitike, ka shërbime në kuptimin më klasik dhe ka shumë të vogla. Në terminologjinë time punëtore-fshatare them se nëse një shërbim është i thjeshtë dhe i vogël, atëherë ai është mikro, e nëse nuk është shumë i thjeshtë dhe i vogël, atëherë është thjesht një shërbim.
Të mirat e shërbimeve
Unë do të kaloj shpejt mbi avantazhet e shërbimeve.
E para është shkallëzimi. Ju mund të bëni shpejt diçka në shërbim dhe të filloni prodhimin. Ju keni marrë trafik, keni klonuar shërbimin. Keni më shumë trafik, e keni klonuar dhe jetoni me të. Ky është një bonus i mirë dhe, në parim, kur filluam, u konsiderua gjëja më e rëndësishme për ne, pse po i bëjmë të gjitha këto.
Së dyti, zhvillimi i izoluar, kur keni disa ekipe zhvillimi, disa zhvillues të ndryshëm në secilin ekip dhe secili ekip zhvillon shërbimin e tij.
Me ekipet ka një nuancë. Zhvilluesit janë të ndryshëm. Dhe ka, për shembull, . E pashë për herë të parë këtë me Maxim Dorofeev. Ndonjëherë njerëzit me flakë dëbore janë në disa ekipe dhe jo në të tjera. Kjo i bën shërbimet e ndryshme të përdorura në të gjithë kompaninë paksa të pabarabarta.
Shikoni foton: ky është një zhvillues i mirë, ai ka duar të mëdha, ai mund të bëjë shumë. Problemi kryesor është se nga vijnë këto duar.
Shërbimet bëjnë të mundur përdorimin e gjuhëve të ndryshme programimi që janë më të përshtatshme për detyra të ndryshme. Disa shërbime janë në Go, disa në Erlang, disa në Ruby, diçka në PHP, diçka në Python. Në përgjithësi, ju mund të zgjeroheni shumë gjerësisht. Këtu ka edhe nuanca.
Arkitektura e orientuar nga shërbimi ka të bëjë kryesisht me devops. Kjo do të thotë, nëse nuk keni automatizim, nuk ka asnjë proces vendosjeje, nëse e konfiguroni manualisht, konfigurimet tuaja mund të ndryshojnë nga shembulli i shërbimit në shembull, dhe ju duhet të shkoni atje për të bërë diçka, atëherë jeni në ferr.
Për shembull, ju keni 20 shërbime dhe duhet të vendosni me dorë, keni 20 konzola dhe njëkohësisht shtypni "enter" si një ninja. Nuk është shumë mirë.
Nëse keni një shërbim pas testimit (nëse ka testim, sigurisht), dhe duhet ta përfundoni me një skedar që të funksionojë në prodhim, kam edhe një lajm të keq për ju.
Nëse mbështeteni në shërbime specifike të Amazon dhe punoni në Rusi, atëherë dy muaj më parë keni pasur gjithashtu "Gjithçka përreth është në zjarr, unë jam mirë, gjithçka është e lezetshme".
Ne përdorim Ansible për të automatizuar vendosjen, Puppet për konvergjencë, Bamboo për të automatizuar vendosjen dhe Confluence për t'i përshkruar disi të gjitha.
Nuk do të ndalem në këtë në detaje, sepse raporti ka të bëjë më shumë me praktikat e ndërveprimit, dhe jo me zbatimin teknik.
Për shembull, ne kemi pasur probleme ku Puppet në server punon me Ruby 2, por disa aplikacione janë shkruar për Ruby 1.8 dhe ato nuk funksionojnë së bashku. Diçka nuk shkon atje. Dhe kur ju duhet të ekzekutoni versione të shumta të Ruby në një makinë, zakonisht filloni të keni probleme.
Për shembull, ne i japim çdo zhvilluesi një platformë në të cilën ka përafërsisht gjithçka që kemi, të gjitha shërbimet që mund të zhvillohen, në mënyrë që ai të ketë një mjedis të izoluar, ta thyejë atë dhe ta ndërtojë si të dojë.
Ndodh që keni nevojë për një paketë të përpiluar posaçërisht me mbështetje për diçka atje. Është mjaft e vështirë. Kam dëgjuar një raport ku imazhi i Docker peshon 45 GB. Në Linux, natyrisht, është më e thjeshtë, gjithçka është më e vogël atje, por megjithatë, nuk do të ketë hapësirë të mjaftueshme.
Epo, ka varësi kontradiktore, kur një pjesë e projektit varet nga një bibliotekë e një versioni, një pjesë tjetër e projektit varet nga një version tjetër dhe bibliotekat nuk instalohen fare së bashku.
Ne kemi faqe dhe shërbime në PHP 5.6, na vjen turp për to, por çfarë mund të bëjmë? Ky është faqja jonë e vetme. Ka faqe dhe shërbime në PHP 7, ka më shumë, nuk na vjen turp prej tyre. Dhe secili zhvillues ka bazën e tij ku ai sheh me kënaqësi.
Nëse shkruani në një kompani në një gjuhë, atëherë tre makina virtuale për zhvillues tingëllojnë normale. Nëse keni gjuhë të ndryshme programimi, atëherë situata përkeqësohet.
Ju keni sajte dhe shërbime në këtë, në këtë, pastaj një faqe tjetër për Go, një sajt për Ruby dhe disa Redis të tjera në anën. Si rezultat, e gjithë kjo kthehet në një fushë të madhe mbështetjeje dhe gjatë gjithë kohës një pjesë e saj mund të thyhet.
Prandaj, ne i zëvendësuam përfitimet e gjuhës së programimit me përdorimin e kornizave të ndryshme, pasi kornizat PHP janë mjaft të ndryshme, ato kanë aftësi të ndryshme, komunitete të ndryshme dhe mbështetje të ndryshme. Dhe mund të shkruani një shërbim në mënyrë që të keni diçka gati për të.
Çdo shërbim ka ekipin e vet
Avantazhi ynë kryesor, i cili është kristalizuar gjatë disa viteve, është se çdo shërbim ka ekipin e tij. Ky është i përshtatshëm për një projekt të madh, ju mund të kurseni kohë në dokumentacion, menaxherët e njohin mirë projektin e tyre.
Ju lehtë mund të paraqisni detyra nga mbështetja. Për shembull, shërbimi i sigurimit u prish. Dhe menjëherë ekipi që merret me sigurimet shkon për ta rregulluar.
Veçoritë e reja po krijohen shpejt, sepse kur keni një shërbim atomik, mund të futni shpejt diçka në të.
Dhe kur prishni shërbimin tuaj, dhe kjo ndodh në mënyrë të pashmangshme, ju nuk keni ndikuar në shërbimet e njerëzve të tjerë dhe zhvilluesit nga ekipet e tjera nuk vijnë tek ju me copa dhe thonë: "Aj-aj, mos e bëj këtë".
Si gjithmonë, ka nuanca. Kemi ekipe të qëndrueshme, drejtuesit janë gozhduar në ekip. Ka dokumente të qarta, menaxherët monitorojnë nga afër gjithçka. Çdo ekip me një menaxher ka disa shërbime, dhe ka një pikë të caktuar të kompetencës.
Nëse skuadrat janë lundruese (ne gjithashtu ndonjëherë e përdorim këtë), ekziston një metodë e mirë e quajtur "harta e yjeve".
Ju keni një listë të shërbimeve dhe njerëzve. Një yll do të thotë që personi është ekspert në këtë shërbim, një libër do të thotë që personi po studion këtë shërbim. Detyra e personit është të ndryshojë broshurën me një yll. Dhe nëse asgjë nuk shkruhet përpara shërbimit, atëherë fillojnë problemet, për të cilat do të flas më tej.
Si shfaqen shërbimet për jetimët?
Problemi i parë, mënyra e parë për të marrë një shërbim jetim në infrastrukturën tuaj është të pushoni nga puna njerëzit. A ka pasur ndonjëherë dikush që një biznes të përmbushë afatet para se të vlerësohen detyrat? Ndonjëherë ndodh që afatet janë të ngushta dhe thjesht nuk ka kohë të mjaftueshme për dokumentacion. “Ne duhet ta dorëzojmë shërbimin në prodhim, pastaj do ta shtojmë atë.”
Nëse ekipi është i vogël, ndodh që ka një zhvillues që shkruan gjithçka, pjesa tjetër janë në krahë. "Unë shkrova arkitekturën bazë, le të shtojmë ndërfaqet." Pastaj në një moment menaxheri, për shembull, largohet. Dhe gjatë kësaj periudhe, kur menaxheri është larguar dhe ende nuk është emëruar një i ri, vetë zhvilluesit vendosin se ku po shkon shërbimi dhe çfarë po ndodh atje. Dhe siç e dimë (le të kthehemi disa rrëshqitje mbrapa), në disa ekipe ka njerëz me flakë dëbore, ndonjëherë një drejtues ekipi me flok bore. Pastaj ai jep dorëheqjen dhe ne marrim një shërbim jetim.
Në të njëjtën kohë, detyrat nga mbështetja dhe nga biznesi nuk zhduken; Nëse ka pasur ndonjë gabim arkitektonik gjatë zhvillimit të shërbimit, ato gjithashtu përfundojnë në prapambetje. Shërbimi po përkeqësohet ngadalë.
Si të identifikoni një jetim?
Kjo listë përshkruan mirë situatën. Kush mësoi diçka për infrastrukturën e tyre?
Rreth punës së dokumentuar: ka një shërbim dhe, në përgjithësi, funksionon, ka një manual me dy faqe se si të punohet me të, por askush nuk e di se si funksionon brenda.
Ose, për shembull, ekziston një lloj shkurtuesi i lidhjes. Për shembull, ne aktualisht kemi tre shkurtues lidhjesh në përdorim për qëllime të ndryshme në shërbime të ndryshme. Këto janë vetëm pasojat.
Tani do të jem kapiteni i të dukshmes. Çfarë duhet bërë? Së pari, ne duhet ta transferojmë shërbimin te një menaxher tjetër, një ekip tjetër. Nëse drejtuesi i ekipit tuaj nuk është larguar ende, atëherë në këtë ekip tjetër, kur kuptoni se shërbimi është si një jetim, duhet të përfshini dikë që kupton të paktën diçka për të.
Gjëja kryesore: duhet t'i keni të shkruara me gjak procedurat e transferimit. Në rastin tonë, unë zakonisht e monitoroj këtë, sepse më duhen të gjitha për të funksionuar. Menaxherët kanë nevojë që ajo të dorëzohet shpejt, dhe ajo që ndodh me të më vonë nuk është më aq e rëndësishme për ta.
Mënyra tjetër për të bërë një jetim është "Ne do ta bëjmë atë me kontraktim të jashtëm, do të jetë më i shpejtë dhe më pas do t'ia dorëzojmë ekipit". Është e qartë se të gjithë kanë disa plane në ekip, një kthesë. Shpesh një klient biznesi mendon se transferuesi do të bëjë të njëjtën gjë si departamenti teknik që ka kompania. Edhe pse motivuesit e tyre janë të ndryshëm. Ka zgjidhje të çuditshme teknologjike dhe zgjidhje të çuditshme algoritmike në outsourcing.
Për shembull, ne kishim një shërbim që kishte Sfinks në vende të ndryshme të papritura. Do t'ju tregoj më vonë se çfarë duhej të bëja.
Transferuesit kanë korniza të vetë-shkruara. Ky është thjesht PHP i zhveshur me copy-paste nga një projekt i mëparshëm, ku mund të gjeni të gjitha llojet e gjërave. Skriptet e vendosjes janë një pengesë e madhe kur ju duhet të përdorni disa skripte komplekse Bash për të ndryshuar disa rreshta në një skedar, dhe këto skripte vendosjeje thirren nga ndonjë skript i tretë. Si rezultat, ju ndryshoni sistemin e vendosjes, zgjidhni diçka tjetër, hipni, por shërbimi juaj nuk funksionon. Sepse aty u desh të vendoseshin edhe 8 lidhje të tjera midis dosjeve të ndryshme. Ose ndodh që një mijë disqe funksionojnë, por njëqind mijë nuk funksionojnë më.
Unë do të vazhdoj të jem kapiten. Pranimi i një shërbimi të jashtëm është një procedurë e detyrueshme. A ka pasur ndonjëherë dikush që të arrijë një shërbim i jashtëm dhe të mos pranohet askund? Ky nuk është aq popullor, natyrisht, si një shërbim jetim, por ende.
Shërbimi duhet të kontrollohet, shërbimi duhet të rishikohet, fjalëkalimet duhet të ndryshohen. Kemi patur një rast kur na kanë dhënë një shërbim, ka një panel administratori "nëse login == 'admin' && password == 'admin'...", është shkruar pikërisht në kod. Ne ulemi dhe mendojmë, dhe njerëzit e shkruajnë këtë në 2018?
Testimi i kapacitetit të ruajtjes është gjithashtu një gjë e nevojshme. Ju duhet të shikoni se çfarë do të ndodhë në njëqind mijë regjistrime, edhe para se ta vini këtë shërbim në prodhim diku.
Nuk duhet të ketë turp të dërgoni një shërbim për përmirësim. Kur thua: “Nuk do ta pranojmë këtë shërbim, kemi 20 detyra, bëjini, pastaj pranojmë”, kjo është normale. Ndërgjegjja juaj nuk duhet të lëndohet nga fakti që po krijoni një menaxher ose që biznesi po shpërdoron para. Më pas biznesi do të shpenzojë më shumë.
Ne patëm një rast kur vendosëm të kontraktonim një projekt pilot.
U dorëzua në kohë dhe ky ishte i vetmi kriter cilësor. Kjo është arsyeja pse ne bëmë një projekt tjetër pilot, i cili nuk ishte më as pilot. Këto shërbime u pranuan dhe përmes mjeteve administrative thanë, ja ku është kodi juaj, ja ekipi, ja menaxheri juaj. Shërbimet në fakt tashmë kanë filluar të fitojnë. Në të njëjtën kohë, në fakt, ata janë ende jetimë, askush nuk e kupton se si punojnë dhe menaxherët bëjnë çmos për të mohuar detyrat e tyre.
Ekziston një koncept tjetër i madh - zhvillimi gueril. Kur një departament, zakonisht departamenti i marketingut, dëshiron të testojë një hipotezë dhe urdhëron të gjithë shërbimin e jashtme. Trafiku fillon të derdhet në të, mbyllin dokumentet, firmosin dokumentet me kontraktorin, hyjnë në punë dhe thonë: "Djema, ne kemi një shërbim këtu, tashmë ka trafik, na sjell para, ta pranojmë". Ne ishim si, "Oppa, si mund të jetë kjo."
Dhe një mënyrë tjetër për të marrë një shërbim jetim: kur një ekip papritmas mbingarkohet, menaxhmenti thotë: "Ta transferojmë shërbimin e këtij ekipi te një ekip tjetër, ai ka një ngarkesë më të vogël." Dhe më pas do ta transferojmë te një ekip i tretë dhe do të ndryshojmë menaxherin. Dhe në fund kemi sërish një jetim.
Cili është problemi me jetimët?
Kush nuk e di, kjo është luftanija Wasa e ngritur në Suedi, e famshme për faktin se u mbyt 5 minuta pas nisjes. Dhe mbreti i Suedisë, nga rruga, nuk ekzekutoi askënd për këtë. Është ndërtuar nga dy breza inxhinierësh që nuk dinin të ndërtonin anije të tilla. Efekt natyral.
Anija mund të ishte fundosur, meqë ra fjala, shumë më keq, për shembull, kur mbreti tashmë po hipte mbi të diku në një stuhi. Dhe kështu, ai u mbyt menjëherë, sipas Agile është mirë të dështosh herët.
Nëse dështojmë herët, zakonisht nuk ka probleme. Për shembull, gjatë pranimit u dërgua për rishikim. Por nëse dështojmë tashmë në prodhim, kur investohen para, atëherë mund të ketë probleme. Pasojat, siç quhen në biznes.
Pse shërbimet për jetimët janë të rrezikshme:
- Shërbimi mund të prishet papritmas.
- Shërbimi kërkon shumë kohë për t'u riparuar ose nuk riparohet fare.
- Problemet e sigurisë.
- Probleme me përmirësimet dhe përditësimet.
- Nëse një shërbim i rëndësishëm prishet, reputacioni i kompanisë vuan.
Çfarë duhet bërë me shërbimet për jetimët?
Do të përsëris çfarë të bëj përsëri. Së pari, duhet të ketë dokumentacion. 7 vjet në Banki.ru më mësuan se testuesit nuk duhet të marrin fjalën e zhvilluesve dhe operacionet nuk duhet të marrin fjalën e të gjithëve. Duhet të kontrollojmë.
Së dyti, është e nevojshme të shkruhet diagrame ndërveprimi, sepse ndodh që shërbimet që nuk priten shumë mirë përmbajnë varësi për të cilat askush nuk tha. Për shembull, zhvilluesit e instaluan shërbimin në çelësin e tyre për disa Yandex.Maps ose Dadata. Të ka mbaruar kufiri i lirë, gjithçka është prishur dhe nuk e di fare se çfarë ka ndodhur. Të gjitha raketat e tilla duhet të përshkruhen: shërbimi përdor Dadata, SMS, diçka tjetër.
Së treti, puna me borxhin teknik. Kur bëni disa paterica ose pranoni një shërbim dhe thoni se diçka duhet bërë, duhet të siguroheni që ajo është bërë. Sepse atëherë mund të rezultojë se vrima e vogël nuk është aq e vogël, dhe ju do të bini përmes saj.
Me detyra arkitekturore, ne patëm një histori për Sfinksin. Një nga shërbimet përdorte Sphinx për të hyrë në lista. Vetëm një listë e faqezuar, por ajo ri-indeksohej çdo natë. Ajo ishte mbledhur nga dy indekse: një i madh indeksohej çdo natë, dhe kishte gjithashtu një indeks të vogël që vidhte në të. Çdo ditë, me një probabilitet 50% për të bombarduar ose jo, indeksi rrëzohej gjatë llogaritjes dhe lajmet tona pushuan së përditësuari në faqen kryesore. Fillimisht u deshën 5 minuta që indeksi të riindeksohej, më pas indeksi u rrit dhe në një moment filloi të duheshin 40 minuta për të riindeksuar. Kur e ndërpremë këtë, morëm një psherëtimë të lehtësuar, sepse ishte e qartë se do të kalonte edhe pak kohë dhe indeksi ynë do të riindeksohej me kohë të plotë. Ky do të jetë një dështim për portalin tonë, nuk ka asnjë lajm për tetë orë - kaq, biznesi është ndalur.
Plani për të punuar me një shërbim jetim
Në fakt, kjo është shumë e vështirë për t'u bërë, sepse devops ka të bëjë me komunikimin. Ju dëshironi të jeni në marrëdhënie të mira me kolegët tuaj dhe kur i goditni kolegët dhe menaxherët tuaj mbi kokë me rregullore, ata mund të kenë ndjenja kontradiktore ndaj atyre njerëzve që e bëjnë këtë.
Përveç të gjitha këtyre pikave, ka edhe një gjë tjetër të rëndësishme: njerëz të veçantë duhet të jenë përgjegjës për çdo shërbim specifik, për çdo seksion specifik të procedurës së vendosjes. Kur nuk ka njerëz dhe duhet të tërheqësh disa njerëz të tjerë për të studiuar gjithë këtë çështje, bëhet e vështirë.
Nëse e gjithë kjo nuk ju ndihmoi, dhe shërbimi juaj jetim është ende jetim, askush nuk dëshiron ta marrë përsipër, dokumentacioni nuk është i shkruar, ekipi që u thirr në këtë shërbim refuzon të bëjë asgjë, ekziston një mënyrë e thjeshtë - për të ribërë çdo gjë.
Domethënë, ju i merrni përsëri kërkesat për shërbimin dhe shkruani një shërbim të ri, më mirë, në një platformë më të mirë, pa zgjidhje të çuditshme teknologjike. Dhe ju migroni në të në betejë.
Ne patëm një situatë kur morëm një shërbim në Yii 1 dhe kuptuam se nuk mund ta zhvillonim më tej, sepse na mbaruan zhvilluesit që mund të shkruanin mirë në Yii 1. Të gjithë zhvilluesit shkruajnë mirë në Symfony XNUMX. Çfarë duhet bërë? Ne ndamë kohë, ndamë një ekip, ndamë një menaxher, rishkruam projektin dhe kaluam pa probleme trafikun në të.
Pas kësaj, shërbimi i vjetër mund të fshihet. Kjo është procedura ime e preferuar, kur ju duhet të merrni dhe pastroni disa shërbime nga sistemi i menaxhimit të konfigurimit dhe më pas kaloni dhe shikoni që të gjitha makinat në prodhim janë çaktivizuar, në mënyrë që zhvilluesit të mos kenë asnjë gjurmë. Depoja mbetet në Git.
Kjo është gjithçka për të cilën doja të flisja, jam gati të diskutoj, tema është holivar, shumë kanë notuar në të.
Sllajdet thoshin se ju unifikuat gjuhët. Një shembull ishte ndryshimi i madhësisë së fotografive. A është vërtet e nevojshme të kufizohet rreptësisht në një gjuhë? Sepse ndryshimi i madhësisë së imazhit në PHP, mirë, mund të bëhet në Golang.
Në fakt, është fakultative, si të gjitha praktikat. Ndoshta, në disa raste, është edhe e padëshirueshme. Por ju duhet të kuptoni se nëse keni një departament teknik në një kompani prej 50 personash, 45 prej tyre janë specialistë të PHP-së, 3 të tjerë janë devops që njohin Python, Ansible, Puppet dhe diçka të tillë, dhe vetëm njëri prej tyre shkruan në disa. një lloj gjuhe, një shërbim për ndryshimin e madhësisë së imazhit, atëherë kur ai largohet, ekspertiza shkon me të. Dhe në të njëjtën kohë, do t'ju duhet të kërkoni një zhvillues specifik të tregut që e njeh këtë gjuhë, veçanërisht nëse është e rrallë. Kjo është, nga pikëpamja organizative, kjo është problematike. Nga pikëpamja devops, nuk do t'ju duhet vetëm të klononi disa grupe të gatshme librash që përdorni për të vendosur shërbime, por do t'ju duhet t'i shkruani ato përsëri.
Aktualisht po ndërtojmë një shërbim në Node.js dhe kjo do të jetë vetëm një platformë afër për çdo zhvillues me një gjuhë të veçantë. Por ne u ulëm dhe menduam se loja ia vlente qiriri. Kjo është një pyetje që ju duhet të uleni dhe të mendoni.
Si i monitoroni shërbimet tuaja? Si i mbledhni dhe monitoroni regjistrat?
Ne mbledhim trungje në Elasticsearch dhe i vendosim në Kibana dhe varësisht nëse bëhet fjalë për mjedise prodhimi apo testimi, aty përdoren kolektorë të ndryshëm. Diku Dravanxhi, diku tjetër diçka tjetër, nuk më kujtohet. Dhe ka ende disa vende në disa shërbime ku ne instalojmë Telegrafin dhe xhirojmë diku tjetër veçmas.
Si të jetoni me Puppet dhe Ansible në të njëjtin mjedis?
Në fakt, tani kemi dy mjedise, njëra është Puppet, tjetra është Ansible. Ne po punojmë për hibridizimin e tyre. Ansible është një kornizë e mirë për konfigurimin fillestar, Puppet është një kornizë e keqe për konfigurimin fillestar sepse kërkon punë praktike drejtpërdrejt në platformë dhe Puppet siguron konvergjencë të konfigurimit. Kjo do të thotë që platforma e mban veten në një gjendje të përditësuar dhe në mënyrë që makina e ansibilizuar të mbahet e përditësuar, ju duhet të përdorni librat e lojërave në të gjatë gjithë kohës me një frekuencë të caktuar. Ky është ndryshimi.
Si e ruani përputhshmërinë? A keni konfigurime si në Ansible ashtu edhe në Puppet?
Kjo është dhimbja jonë e madhe, ne ruajmë pajtueshmërinë me duart tona dhe mendojmë se si të kalojmë nga e gjithë kjo diku tani. Rezulton se Puppet nxjerr paketa dhe ruan disa lidhje atje, dhe Ansible, për shembull, nxjerr kodin dhe rregullon konfigurimet më të fundit të aplikacionit atje.
Prezantimi kishte të bënte me versione të ndryshme të Ruby. Çfarë zgjidhjeje?
Këtë e kemi hasur në një vend dhe duhet ta mbajmë në kokë gjatë gjithë kohës. Thjesht fikëm pjesën që funksiononte në Ruby që ishte e papajtueshme me aplikacionet dhe e mbajtëm të ndarë.
Konferenca e këtij viti do të zhvillohet më 7 dhjetor në Technopolis. Do të pranojmë aplikime për raporte deri më 11 nëntor. ne nëse dëshironi të flisni.
Regjistrimi për pjesëmarrësit është i hapur, bashkohuni me ne!
Burimi: www.habr.com