Өткен жылғы конференцияда Banki.ru порталының операциялық директоры Андрей Никольский сөз сөйледі жетімдер қызметтері туралы: инфрақұрылымдағы жетім баланы қалай анықтауға болады, жетім қызметтер неге нашар, олармен не істеу керек және ештеңе көмектеспесе не істеу керек.
Қиманың астында есептің мәтіндік нұсқасы берілген.
Сәлем әріптестер! Менің атым Андрей, мен Banki.ru-да операцияларды басқарамын.
Бізде үлкен қызметтер бар, бұл монолитті қызметтер, классикалық мағынада қызметтер бар, ал өте шағын қызметтер бар. Мен жұмысшы-шаруа терминологиямда, егер қызмет қарапайым және шағын болса, онда ол микро, ал өте қарапайым және шағын болмаса, бұл жай ғана қызмет деп айтамын.
Қызметтердің артықшылығы
Мен қызметтердің артықшылықтарын тез арада қарастырамын.
Біріншісі - масштабтау. Сервисте жылдам бірдеңе жасап, өндірісті бастауға болады. Сіз трафик алдыңыз, қызметті клондаңыз. Сізде көбірек трафик бар, сіз оны клондадыңыз және онымен өмір сүрдіңіз. Бұл жақсы бонус, және, негізінен, біз бастаған кезде бұл біз үшін ең маңызды нәрсе деп саналды, біз мұның бәрін не үшін жасап жатырмыз.
Екіншіден, оқшауланған әзірлеу, егер сізде бірнеше әзірлеушілер тобы болса, әр командада бірнеше түрлі әзірлеушілер және әр команда өз қызметін әзірлейді.
Командаларда бір нюанс бар. Әзірлеушілер әртүрлі. Және бар, мысалы, . Мен мұны алғаш рет Максим Дорофеевтен көрдім. Кейде қар бүршіктері кейбір командаларда болады, ал басқаларында болмайды. Бұл компанияда қолданылатын әртүрлі қызметтерді біршама біркелкі етеді.
Суретке қараңыз: бұл жақсы әзірлеуші, оның қолы үлкен, ол көп нәрсені істей алады. Басты мәселе - бұл қолдар қайдан келеді.
Қызметтер әртүрлі тапсырмалар үшін қолайлы әр түрлі бағдарламалау тілдерін пайдалануға мүмкіндік береді. Кейбір қызмет Go-де, кейбіреулері Erlang-да, кейбіреулері Ruby-де, бірдеңе PHP-де, бірдеңе Python-да. Жалпы, сіз өте кең ауқымды кеңейте аласыз. Мұнда да нюанстар бар.
Сервиске бағытталған архитектура ең алдымен devops туралы. Яғни, егер сізде автоматтандыру болмаса, орналастыру процесі жоқ, егер сіз оны қолмен конфигурацияласаңыз, конфигурацияларыңыз қызмет данасына ауысуы мүмкін және бірдеңе істеу үшін сол жерге баруыңыз керек, онда сіз тозақтасыз.
Мысалы, сізде 20 қызмет бар және сізде қолмен орналастыру керек, сізде 20 консоль бар және сіз ниндзя сияқты «enter» пернесін бір уақытта басыңыз. Бұл өте жақсы емес.
Егер сізде тестілеуден кейін қызмет болса (әрине тестілеу бар болса) және сіз оны өндірісте жұмыс істейтіндей етіп файлмен аяқтауыңыз керек болса, менің де сізге жаман жаңалығым бар.
Егер сіз белгілі бір Amazon қызметтеріне сенсеңіз және Ресейде жұмыс істесеңіз, екі ай бұрын сізде «Айналаның бәрі жанып жатыр, менде бәрі жақсы, бәрі тамаша».
Біз орналастыруды автоматтандыру үшін Ansible, конвергенция үшін қуыршақ, орналастыруды автоматтандыру үшін Bamboo және бәрін сипаттау үшін Confluence пайдаланамыз.
Мен бұл туралы егжей-тегжейлі тоқталмаймын, өйткені есеп техникалық іске асыру туралы емес, өзара әрекеттесу тәжірибесі туралы көбірек.
Мысалы, бізде сервердегі қуыршақ Ruby 2-мен жұмыс істейтін проблемалар болды, бірақ кейбір қолданбалар Ruby 1.8 үшін жазылған және олар бірге жұмыс істемейді. Бірдеңе дұрыс емес. Ruby бағдарламасының бірнеше нұсқасын бір құрылғыда іске қосу қажет болғанда, сізде әдетте проблемалар туындай бастайды.
Мысалы, біз әрбір әзірлеушіге бізде бар нәрсенің барлығы, әзірлеуге болатын барлық қызметтер бар платформаны береміз, сонда оның оқшауланған ортасы бар, ол оны бұзып, оны қалағандай жасай алады.
Онда бір нәрсеге қолдау көрсететін арнайы құрастырылған пакет қажет болады. Бұл өте қиын. Мен Docker кескінінің салмағы 45 ГБ болатын есепті тыңдадым. Linux-та, әрине, қарапайымырақ, бәрі кішірек, бірақ бәрібір орын жеткіліксіз.
Қарама-қайшы тәуелділіктер бар, егер жобаның бір бөлігі бір нұсқаның кітапханасына, жобаның басқа бөлігі басқа нұсқаға тәуелді болса және кітапханалар мүлдем бірге орнатылмайды.
Бізде PHP 5.6-да сайттар мен қызметтер бар, біз олардан ұяламыз, бірақ біз не істей аламыз? Бұл біздің бір сайтымыз. PHP 7-де сайттар мен сервистер бар, олар көп, біз олардан ұялмаймыз. Әр әзірлеушінің өзі қуана көретін өз базасы бар.
Егер сіз компанияда бір тілде жазсаңыз, әр әзірлеушіге үш виртуалды машина қалыпты естіледі. Егер сізде әртүрлі бағдарламалау тілдері болса, жағдай нашарлайды.
Сізде бұл туралы сайттар мен қызметтер бар, содан кейін Go үшін басқа сайт, Ruby үшін бір сайт және жағында басқа Redis бар. Нәтижесінде, мұның бәрі қолдау үшін үлкен өріске айналады және барлық уақытта оның бір бөлігі үзілуі мүмкін.
Сондықтан, біз бағдарламалау тілінің артықшылықтарын әртүрлі фреймворктерді қолданумен ауыстырдық, өйткені PHP фреймворктері мүлдем басқа, олардың мүмкіндіктері әртүрлі, қауымдастықтары және қолдауы әртүрлі. Сіз оған дайын бірдеңе болуы үшін қызметті жаза аласыз.
Әр қызметтің өз командасы бар
Бірнеше жыл бойы кристалданған басты артықшылығымыз – әр қызметтің өз командасы бар. Бұл үлкен жоба үшін ыңғайлы, құжаттамаға уақытты үнемдеуге болады, менеджерлер өз жобасын жақсы біледі.
Тапсырмаларды қолдау қызметінен оңай жіберуге болады. Мысалы, сақтандыру қызметі істен шықты. Ал дереу сақтандырумен айналысатын топ оны жөндеуге кетеді.
Жаңа мүмкіндіктер тез жасалуда, өйткені сізде бір атомдық қызмет болғанда, оған бірдеңені тез бұра аласыз.
Сіз қызметіңізді бұзған кезде және бұл сөзсіз орын алса, сіз басқа адамдардың қызметтеріне әсер етпедіңіз және басқа командалардың әзірлеушілері сізге битпен жүгіріп келіп: «Ай-ай, олай істеме» демейді.
Әдеттегідей, нюанстар бар. Бізде тұрақты командалар бар, командаға менеджерлер бекітілген. Нақты құжаттар бар, басшылар барлығын жіті қадағалайды. Менеджері бар әр команданың бірнеше қызметтері бар және белгілі бір құзыреттілік нүктесі бар.
Егер командалар қалқып тұрса (біз оны кейде қолданамыз), «жұлдызды карта» деп аталатын жақсы әдіс бар.
Сізде қызметтер мен адамдар тізімі бар. Жұлдызша адамның осы қызметтің маманы екенін, кітап адамның осы қызметті оқып жатқанын білдіреді. Адамның міндеті - кітапшаны жұлдызшаға ауыстыру. Егер қызмет алдында ештеңе жазылмаса, онда мен одан әрі айтатын мәселелер басталады.
Жетімдік қызметтер қалай пайда болады?
Бірінші мәселе, сіздің инфрақұрылымыңыздағы жетім қызметтерді алудың бірінші жолы - адамдарды жұмыстан шығару. Тапсырмалар бағаланбай тұрып, кез келген біреудің бизнесі белгіленген мерзімге сәйкес келді ме? Кейде мерзімдер тығыз және құжаттамаға уақыт жетпей қалады. «Біз қызметті өндіріске беруіміз керек, содан кейін оны қосамыз».
Егер команда кішкентай болса, барлығын жазатын бір әзірлеуші болады, қалғандары қанатында. «Мен негізгі архитектураны жаздым, интерфейстерді қосамыз». Содан кейін бір сәтте менеджер, мысалы, кетеді. Осы кезеңде, менеджер кетіп, жаңасы әлі тағайындалмаған кезде, әзірлеушілер қызметтің қайда баратынын және онда не болып жатқанын өздері шешеді. Біз білетіндей (бірнеше слайдқа оралайық), кейбір командаларда снежинка адамдары, кейде снежинка тобының жетекшісі болады. Сосын ол жұмыстан кетеді, ал біз жетімдер қызметін аламыз.
Сонымен қатар, қолдау мен бизнестің міндеттері жойылмайды, олар артта қалады. Сервисті әзірлеу барысында қандай да бір архитектуралық қателер орын алса, олар да артта қалады. Қызмет баяу нашарлап барады.
Жетім баланы қалай анықтауға болады?
Бұл тізім жағдайды жақсы сипаттайды. Олардың инфрақұрылымы туралы кім білді?
Құжатталған жұмыс туралы: қызмет бар және тұтастай алғанда, ол жұмыс істейді, онымен жұмыс істеу туралы екі беттік нұсқаулық бар, бірақ оның ішінде оның қалай жұмыс істейтінін ешкім білмейді.
Немесе, мысалы, сілтеме қысқартқыштың қандай да бір түрі бар. Мысалы, бізде қазіргі уақытта әртүрлі қызметтерде әртүрлі мақсаттарда қолданылатын үш сілтеме қысқартқышы бар. Бұл тек салдары.
Енді мен анықтың капитаны боламын. Не істеу керек? Біріншіден, біз қызметті басқа менеджерге, басқа командаға беруіміз керек. Егер сіздің топ жетекшіңіз әлі жұмыстан кетпесе, онда бұл басқа командада қызмет жетім сияқты екенін түсінген кезде, сіз бұл туралы кем дегенде бір нәрсені түсінетін адамды қосуыңыз керек.
Ең бастысы: трансфер процедуралары қанмен жазылған болуы керек. Біздің жағдайда мен мұны әдетте бақылаймын, өйткені маған бәрі жұмыс істеуі керек. Менеджерлер оны тез жеткізуді қажет етеді, ал кейінірек не болатыны олар үшін маңызды емес.
Жетім жасаудың келесі жолы - «Біз оны аутсорсингпен жасаймыз, ол тезірек болады, содан кейін оны командаға тапсырамыз». Әркімнің ұжымда біраз жоспары, кезегі бар екені анық. Көбінесе іскер тұтынушы аутсорсинг компанияның техникалық бөлімімен бірдей нәрсені жасайды деп ойлайды. Олардың мотиваторлары әртүрлі болғанымен. Аутсорсингте біртүрлі технологиялық шешімдер мен таңқаларлық алгоритмдік шешімдер бар.
Мысалы, бізде әртүрлі күтпеген жерлерде сфинкс болған қызмет болды. Мен не істеуім керек екенін кейінірек айтамын.
Аутсорсерлерде өздігінен жазылған шеңберлер бар. Бұл алдыңғы жобадан көшіру-қою мүмкіндігі бар қарапайым PHP, мұнда сіз барлық нәрселерді таба аласыз. Кейбір файлдағы бірнеше жолды өзгерту үшін кейбір күрделі Bash сценарийлерін пайдалану қажет болғанда орналастыру сценарийлері үлкен кемшілік болып табылады және бұл орналастыру сценарийлері кейбір үшінші сценарий арқылы шақырылады. Нәтижесінде сіз орналастыру жүйесін өзгертесіз, басқа нәрсені таңдайсыз, секіресіз, бірақ сіздің қызметіңіз жұмыс істемейді. Өйткені ол жерде әртүрлі қалталар арасында тағы 8 сілтеме қою керек болды. Немесе мың жазба жұмыс істейді, бірақ жүз мың жұмыс істемейді.
Мен капитан қызметін жалғастырамын. Аутсорсингтік қызметті қабылдау міндетті рәсім болып табылады. Кез келген адам аутсорсингтік қызметке келіп, еш жерде қабылданбады ма? Бұл, әрине, жетімдер қызметі сияқты танымал емес, бірақ бәрібір.
Қызметті тексеру керек, қызметті қарау керек, құпия сөздерді өзгерту керек. Олар бізге қызмет көрсеткен кезде бізде «логин == 'admin' && құпия сөз == 'admin'...» басқару панелі бар, ол кодта дәл жазылған. Біз отырамыз және ойлаймыз, ал адамдар мұны 2018 жылы жазады ма?
Сақтау сыйымдылығын тексеру де қажет нәрсе. Сіз бұл қызметті бір жерде өндіріске енгізбес бұрын, жүз мың жазбада не болатынын қарауыңыз керек.
Қызметті жақсартуға жіберу ұят болмауы керек. Сіз: «Біз бұл қызметті қабылдамаймыз, бізде 20 тапсырма бар, оларды орындаңыз, содан кейін қабылдаймыз», - бұл қалыпты жағдай. Сіздің ар-ұжданыңыз сіздің менеджер орнатып жатқаныңыз немесе бизнестің ақшаны ысырап ететіндігінен зардап шекпеуі керек. Сонда бизнес көбірек ақша жұмсайды.
Бізде пилоттық жобаны аутсорсингке алуды ұйғарған жағдай болды.
Ол уақытында жеткізілді және бұл тек сапа критерийі болды. Сондықтан біз тағы бір пилоттық жоба жасадық, ол енді шын мәнінде пилот емес еді. Бұл қызметтер қабылданып, әкімшілік жолмен олар мынау сіздің кодыңыз, міне командаңыз, міне сіздің менеджеріңіз деді. Қызметтер шынымен де пайда таба бастады. Сонымен қатар, шын мәнінде, олар әлі жетім, олардың қалай жұмыс істейтінін ешкім түсінбейді, ал менеджерлер олардың тапсырмаларынан бас тартуға бар күшін салады.
Тағы бір ұлы ұғым бар – партизандық даму. Кейбір бөлім, әдетте маркетинг бөлімі, гипотезаны тексергісі келгенде және бүкіл қызметке аутсорсингке тапсырыс бергенде. Оған көлік ағыла бастайды, олар құжаттарды жауып, мердігермен құжаттарға қол қояды, іске қосылып: «Жігіттер, бізде мұнда қызмет бар, трафик бар, ол бізге ақша әкеледі, оны қабылдап алайық» дейді. Біз: «Оппа, бұл қалай болады» деп ойладық.
Жетімдік қызметті алудың тағы бір жолы: кейбір команда кенеттен жүктеліп қалғанда, басшылық: «Бұл команданың қызметін басқа командаға ауыстырайық, оның жүктемесі аз» дейді. Содан кейін біз оны үшінші командаға ауыстырамыз және менеджерді ауыстырамыз. Соңында тағы да жетім қалдық.
Жетімдердің мәселесі неде?
Кім білмейді, бұл Швецияда көтерілген «Васа» әскери кемесі ұшырылғаннан кейін 5 минуттан кейін суға батып кеткенімен әйгілі. Ал Швеция королі, айтпақшы, бұл үшін ешкімді өлтірген жоқ. Оны мұндай кемелерді жасауды білмейтін екі буын инженерлер салған. Табиғи әсер.
Кеме, айтпақшы, бұдан да жаман жолмен батып кетуі мүмкін еді, мысалы, дауыл кезінде патша оған мініп жатқанда. Осылайша, ол бірден суға батып кетті, Agile айтуынша, ерте сәтсіздікке ұшыраған дұрыс.
Егер біз ертерек сәтсіздікке ұшырасақ, әдетте ешқандай проблемалар болмайды. Мысалы, қабылдау кезінде қайта қарауға жіберілді. Бірақ егер біз өндірісте сәтсіздікке ұшырасақ, ақша салынған кезде, проблемалар туындауы мүмкін. Салдары, олар бизнесте қалай аталады.
Неліктен жетім қызметтер қауіпті:
- Қызмет кенеттен үзілуі мүмкін.
- Қызмет жөндеуге ұзақ уақыт кетеді немесе мүлде жөнделмейді.
- Қауіпсіздік мәселелері.
- Жақсартулар мен жаңартуларға қатысты мәселелер.
- Маңызды қызмет істен шықса, компанияның беделі төмендейді.
Жетімдер қызметтерімен не істеу керек?
Мен не істеу керектігін қайталаймын. Біріншіден, құжаттама болуы керек. Banki.ru-дағы 7 жыл маған тестерлер әзірлеушілердің сөзін қабылдамауы керек, ал операциялар барлығының сөзін қабылдамауы керек екенін үйретті. Біз тексеруіміз керек.
Екіншіден, өзара әрекеттесу диаграммаларын жазу қажет, өйткені онша қабылданбаған қызметтерде ешкім айтпаған тәуелділіктер болады. Мысалы, әзірлеушілер қызметті Яндекс.Карталар немесе Dadata кілттеріне орнатты. Сізде бос шектеу бітті, бәрі бұзылды және сіз не болғанын мүлдем білмейсіз. Барлық осындай тырмаларды сипаттау керек: қызмет Dadata, SMS және басқа нәрсені пайдаланады.
Үшіншіден, техникалық қарызмен жұмыс істеу. Сіз балдақтардың бір түрін жасағанда немесе қызметті қабылдағанда және бірдеңе істеу керек екенін айтқан кезде, оның орындалғанына көз жеткізу керек. Өйткені, ол кезде кішкентай тесік соншалықты кішкентай емес болып шығуы мүмкін және сіз одан құлап кетесіз.
Сәулет тапсырмаларымен бізде Сфинкс туралы әңгіме болды. Қызметтердің бірі тізімдерді енгізу үшін Сфинксті пайдаланды. Тек беттелген тізім, бірақ ол әр түнде қайта индекстелді. Ол екі индекстен құрастырылды: бір үлкені әр түнде индекстелді, сонымен қатар оған бұрандаланған шағын индекс бар. Күн сайын, 50% бомбалау ықтималдығы бар немесе жоқ, индекс есептеу кезінде бұзылды және біздің жаңалықтар басты бетте жаңаруды тоқтатты. Алғашында индексті қайта индекстеу үшін 5 минут қажет болды, содан кейін индекс өсті, ал бір сәтте оны қайта индекстеуге 40 минут қажет болды. Біз мұны қысқартқанда, біз жеңіл дем алдық, өйткені тағы біраз уақыт өтіп, индексіміз толық уақытты қайта индекстелетіні анық болды. Бұл біздің портал үшін сәтсіздікке ұшырайды, сегіз сағат бойы ешқандай жаңалық жоқ - міне, бизнес тоқтады.
Жетімдер қызметімен жұмыс істеу жоспары
Шындығында, мұны істеу өте қиын, өйткені devops коммуникация туралы. Сіз өзіңіздің әріптестеріңізбен жақсы қарым-қатынаста болғыңыз келеді және сіз әріптестеріңіз бен менеджерлеріңізді ережелермен ұрып-соққанда, олар мұны істейтін адамдарға қарама-қайшы сезімде болуы мүмкін.
Барлық осы тармақтардан басқа, тағы бір маңызды нәрсе бар: нақты адамдар әрбір нақты қызметке, орналастыру процедурасының әрбір нақты бөліміне жауапты болуы керек. Адамдар болмаған кезде және сіз осы мәселені зерттеу үшін басқа адамдарды тартуыңыз керек болса, бұл қиын болады.
Егер мұның бәрі көмектеспесе және сіздің жетім қызметіңіз әлі жетім болса, оны ешкім өз мойнына алғысы келмейді, құжаттама жазылмаған болса, осы қызметке шақырылған команда ештеңе істеуден бас тартса, қарапайым әдіс бар - қайталау бәрі.
Яғни, сіз қызметке қойылатын талаптарды жаңадан қабылдайсыз және біртүрлі технологиялық шешімдерсіз жаңа қызметті, жақсырақ, жақсырақ платформада жазасыз. Ал сендер оған соғыста қоныс аударасыңдар.
Бізде Yii 1-де сервисті алып, оны әрі қарай дамыта алмайтынымызды түсіндік, себебі Yii 1-де жақсы жаза алатын әзірлеушілер таусылды. Барлық әзірлеушілер Symfony XNUMX-те жақсы жазады. Не істеу? Біз уақыт бөлдік, команда бөлдік, менеджер бөлдік, жобаны қайта жазып, оған трафикті оңай ауыстырдық.
Осыдан кейін ескі қызметті жоюға болады. Бұл менің сүйікті процедурам, конфигурацияны басқару жүйесінен кейбір қызметті алып, тазалау керек, содан кейін әзірлеушілерде ешқандай із қалмауы үшін өндірістегі барлық автомобильдер өшірілгенін көру керек. Репозиторий Git-те қалады.
Мен бұл туралы айтқым келді, мен талқылауға дайынмын, бұл голивар тақырыбы, көбісі онымен жүзді.
Слайдтарда тілдерді біріктіретіндер айтылды. Мысал суреттердің өлшемін өзгерту болды. Оны бір тілге қатаң шектеу керек пе? Өйткені PHP-де кескіннің өлшемін өзгертуді Голангта жасауға болады.
Шындығында, бұл барлық тәжірибелер сияқты міндетті емес. Мүмкін, кейбір жағдайларда бұл тіпті қажет емес. Бірақ сізде 50 адамнан тұратын компанияда техникалық бөлім болса, олардың 45-і PHP мамандары, тағы 3-і Python, Ansible, Puppet және тағы басқаларды білетін devops екенін және олардың біреуі ғана кейбіреулерінде жазатынын түсінуіңіз керек. Кейбір Go кескіннің өлшемін өзгерту қызметі, содан кейін ол кеткен кезде сараптама онымен бірге жүреді. Сонымен қатар, сізге бұл тілді білетін нарыққа тән әзірлеушіні іздеу керек болады, әсіресе ол сирек болса. Яғни, ұйымдастырушылық тұрғыдан алғанда бұл проблемалық. Devops көзқарасы бойынша, сізге қызметтерді орналастыру үшін пайдаланатын кейбір дайын оқу кітаптарын клондау қажет емес, бірақ оларды қайтадан жазуға тура келеді.
Біз қазір Node.js жүйесінде қызмет жасап жатырмыз және бұл әр әзірлеушіге бөлек тілі бар жақын маңдағы платформа ғана болады. Бірақ біз отырдық, ойын шыраққа тұрарлық деп ойладық. Яғни, бұл сіз отырып ойланып алатын сұрақ.
Қызметтеріңізді қалай бақылайсыз? Журналдарды қалай жинап, бақылайсыз?
Біз Elasticsearch жүйесінде журналдарды жинаймыз және оларды Кибанаға орналастырамыз және бұл өндіріс немесе сынақ ортасы болуына байланысты онда әртүрлі коллекторлар қолданылады. Бір жерде Lumberjack, басқа жерде тағы бір нәрсе, есімде жоқ. Кейбір қызметтерде Telegraf орнатып, басқа жерде бөлек түсіретін жерлер әлі де бар.
Қуыршақ пен Ансиблмен бір ортада қалай өмір сүруге болады?
Шындығында, қазір бізде екі орта бар, бірі - қуыршақ, екіншісі - Ansible. Біз оларды будандастыру жұмыстарын жүргізіп жатырмыз. Ansible - бастапқы орнату үшін жақсы құрылым, Puppet - бастапқы орнату үшін нашар құрылым, себебі ол платформада тікелей практикалық жұмысты қажет етеді, ал қуыршақ конфигурация конвергенциясын қамтамасыз етеді. Бұл платформа өзін жаңа күйде сақтайтынын білдіреді және ансибилизацияланған машина жаңартылып тұруы үшін оған үнемі белгілі бір жиілікпен оқу кітаптарын іске қосу керек. Бұл айырмашылық.
Үйлесімділікті қалай сақтайсыз? Ansible және Puppet екеуінде де конфигурацияларыңыз бар ма?
Бұл біздің үлкен азап, біз қолдарымызбен үйлесімділікті сақтаймыз және осының бәрінен қазір бір жерде қалай өту керектігін ойлаймыз. Қуыршақ пакеттерді шығарады және сол жерде кейбір сілтемелерді сақтайды, ал Ansible, мысалы, кодты шығарады және сол жерде соңғы қолданба конфигурацияларын реттейді.
Презентация Ruby-дің әртүрлі нұсқалары туралы болды. Қандай шешім?
Біз мұны бір жерде кездестірдік және оны үнемі басымызда ұстауымыз керек. Біз жай ғана Ruby-де жұмыс істейтін қолданбалармен үйлеспейтін бөлікті өшіріп, оны бөлек қалдырдық.
Биылғы конференция 7 желтоқсанда Технополисте өтеді. Біз 11 қарашаға дейін есептер қабылдауға өтінімдерді қабылдаймыз. сөйлегіңіз келсе бізге.
Қатысушыларға тіркелу ашық, бізге қосылыңыз!
Ақпарат көзі: www.habr.com