Ja sa ikkagi ei vastanud k\u00fcsimusele: 'Kas Jenkins on vajalik v\u00f5i mitte?'<\/em><\/p>\n<\/p>\n
Jenkins ei ole tegelikult kunagi vajalik. Kui t\u00f5siselt r\u00e4\u00e4kida, siis t\u00f6\u00f6riistad nagu Jenkins ja Gitlab toovad mugavust. N\u00e4ete, kas ehitamine toimis v\u00f5i mitte. Nad aitavad teil, kuid nad ei anna teile praktilisi kogemusi. Nad v\u00f5ivad anda vaid ringi \u2013 OK, mitte OK. Ja seda juhul, kui te kirjutate veel teste, sest kui teste ei ole, siis on see peaaegu m\u00f5ttetu. Seet\u00f5ttu on vaja, sest see on mugavam, kuid \u00fcldiselt saate ka ilma selleta hakkama, ei kaota kuigi palju. <\/p>\n
<\/p>\n
K. e. kui teil on praktika, kas see t\u00e4hendab, et teil ei ole seda vaja?<\/em><\/p>\n<\/p>\n
Just. Soovitan Jez Humble'i testi. Ma olen viimase punkti osas kahtleval seisukohal. Kuid kokkuv\u00f5ttes, kui teil on kolm asja: te \u00fchendate pidevalt, k\u00e4ivitate teste masteris tehtud muudatuste puhul, kiiresti parandate masteri ehituse, siis v\u00f5ib-olla ei ole teil rohkemat vajagi. <\/p>\n
<\/p>\n
Kui me ootame osalejatelt k\u00fcsimusi, siis minul on k\u00fcsimus. Me r\u00e4\u00e4kisime tootekoodist. Kas sa oled kasutanud ka infrastruktuurikoodi? Kas see on sama kood, millel on samad p\u00f5him\u00f5tted ja eluiga, v\u00f5i on seal teised eluiga ja p\u00f5him\u00f5tted? \u00dcldiselt, kui k\u00f5ik r\u00e4\u00e4givad pidevast integreerimisest ja arendamisest, unustavad nad, et infrastruktuurikood on samuti olemas. Viimasel ajal on seda \u00fcha rohkem. Kas peaksime sinna tuua k\u00f5ik need reeglid?<\/em><\/p>\n<\/p>\n
See ei ole ainult soovitus, see oleks suurep\u00e4rane, kuna see lihtsustaks elu. Niipea kui me t\u00f6\u00f6tame koodiga, mitte bash-skriptidega, vaid meil on normaalne kood.<\/p>\n
<\/p>\n
Peatu-peat, bash-skript on samuti kood. \u00c4ra puutu minu vana armastust.<\/em> <\/p>\n<\/p>\n
Hea k\u00fcll, ma ei hakka sinu m\u00e4lestusi tallama. Mul on bash'i vastu isiklik antipaatia. See puruneb inetult ja haaravalt kogu aeg. Ja see katkeb sageli ettearvamatult, seet\u00f5ttu ma ei armasta seda. Aga h\u00e4sti, oletame, et sul on bash'is kood. V\u00f5ib-olla t\u00f5esti ma ei tea ja seal on normaalsed testimise raamistikud. Ma lihtsalt ei ole teadlik. Ja me saame samu eeliseid.<\/p>\n
<\/p>\n
Kui me t\u00f6\u00f6tame infrastruktuuriga nagu koodiga, kohtame samu probleeme nagu arendajad. M\u00f5ned kuud tagasi sattusin olukorda, kus kolleeg saatis mulle 1 000 rea suuruse bash'i pull request'i. Ja sa j\u00e4\u00e4d 4 tunniks \u00fclevaate tegemisse kinni. Probleemid on samad. See on ikka veel kood. Ja ikka veel koost\u00f6\u00f6. Me j\u00e4\u00e4me kinni pull request'i ja meid pidurdavad samad bash'i mergen\u00fc\u00fcbid. <\/p>\n
<\/p>\n
Ma j\u00e4lgisin seda asja praegu v\u00e4ga aktiivselt, keskendudes tarkvara infrastruktuuri maksimaalselt ilusale kodeerimisele. Olen praegu integreerinud infrastrukturi Pulumi. See on puhtalt kodeerimine. Seal on see veel kaunim, sest mul on k\u00f5ik programmeerimiskeele v\u00f5imalused. See t\u00e4hendab, et ma tegin samade if-de abil kauneid toggles ja k\u00f5ik on h\u00e4sti. Minu muudatus on juba Masteris. K\u00f5ik n\u00e4evad seda. Teised insenerid on sellest teadlikud. See on juba millegi peale m\u00f5jutanud. Kuid see ei ole aktiveeritud k\u00f5igis infrastruktuurides. See on aktiveeritud n\u00e4iteks minu testkeskkondades. Seega, vastates su k\u00fcsimusele veel kord, see on vajalik. See lihtsustab meie elu inseneridena, kes t\u00f6\u00f6tavad koodiga, t\u00e4pselt samamoodi. <\/p>\n
<\/p>\n
Kas kellelgi on veel k\u00fcsimusi?<\/em> <\/p>\n<\/p>\n
Mul on k\u00fcsimus. Soovin j\u00e4tkata arutelu Olegiga. \u00dcldiselt arvan, et sul on \u00f5igus, et kui \u00fclesanne v\u00f5tab sul kuu aega, siis on sul arhitektuuriga probleeme, sul on probleeme anal\u00fc\u00fcsiga, dekompositsiooniga, planeerimisega jne. Kuid mul on tunne, et kui hakkad p\u00fc\u00fcdma elada Continuous Integration'i j\u00e4rgi, siis hakkad oma planeerimisega seotud muresid lahendama, sest sa ei p\u00e4\u00e4se sellest muidu. <\/p>\n
<\/p>\n
(Oleg) Jah, k\u00f5ik on nii. Selle praktika t\u00f6\u00f6maht on sarnane igasuguste teiste t\u00f5siste praktikatega, mis muudavad kultuuri. K\u00f5ige raskem on harjumuste \u00fcletamine, eriti halbade harjumuste. Ja kui selle praktika juurutamiseks on vajalik t\u00f5sine muutus \u00fcmbritsevates harjumustes: arendajates, juhtkonnas, tootmisjuhtides, siis ootavad sind \u00fcllatused.<\/em> <\/p>\n<\/p>\n
Millised \u00fcllatused v\u00f5ivad tulla? Oletame, et otsustasite, et hakkate sagedamini integreerima. Ja teie integratsioonis on seotud veel m\u00f5ned asjad, n\u00e4iteks artefaktid. Ja teie ettev\u00f5ttes on n\u00e4iteks poliitika, et iga artefakt peab olema mingil moel arvesse v\u00f5etud mingis artefaktide laos\u00fcsteemis. Ja see v\u00f5tab aega. Inimene peab m\u00e4rkima, et tema, kui v\u00e4ljalaskemanager, on katsetanud seda artefakti tootmisse panekuks. Kui see v\u00f5tab 5-10-15 minutit, kuid samas teete v\u00e4ljalaske kord n\u00e4dalas, siis n\u00e4dalas pool tundi kulutada \u2013 see on v\u00e4ike maks.<\/em> <\/p>\n<\/p>\n
Kui teete pidevat integreerimist 10 korda p\u00e4evas, siis tuleb 10 korda korrutada 30 minutiga. Ja see \u00fcletab selle v\u00e4ljalaskemanageri t\u00f6\u00f6aja. Ta lihtsalt v\u00e4sib sellest. On pidevad kulud m\u00f5ningatele praktikatest. Ja k\u00f5ik.<\/em> <\/p>\n<\/p>\n
Ja teil on kas vaja see reegel t\u00fchistada, et te enam sellisega ei tegele, st te ei m\u00e4\u00e4ra k\u00e4sitsi millegi vastavuse astet. Te toetute t\u00e4ielikult mingile automatiseeritud testide komplektile, et kontrollida valmisolekut.<\/em> <\/p>\n<\/p>\n
Ja kui teil on vaja kellegi t\u00f5endit, et juht kirjutaks alla, ja te ei l\u00e4he produktsiooni, kui Vasja ei ole \u00f6elnud, et tal on lubatud jne. \u2013 siis kogu see jama takistab praktikaid. Sest kui on seotud mingisuguste tegevustega maksud, siis k\u00f5ik muutub 100 korda keerulisemaks. Seet\u00f5ttu v\u00f5idakse \u00fcleminekut tihti mitte k\u00f5igiga r\u00f5\u00f5muga vastu v\u00f5tta. Inimeste harjumustele on raske muutuda.<\/em> <\/p>\n<\/p>\n
Kui inimene teeb harjumusp\u00e4rast t\u00f6\u00f6d, siis ta teeb seda praktiliselt mitte m\u00f5eldes. Selle kognitiivne koormus on null. Ta lihtsalt teeb valmisoleku j\u00e4rgi, tal on peas juba kontroll-loend, ta on seda tuhat korda teinud. Ja kui sa tuled ja \u00fctled talle: \"\u00c4ra t\u00fchista seda praktikat ja alates esmasp\u00e4evast rakendame uut\", siis see muutub tema jaoks tohutuks kognitiivseks koormuseks. Ja see koormus tuleb k\u00f5igi jaoks korraga.<\/em> <\/p>\n<\/p>\n
Seega on k\u00f5ige lihtsam, kuigi t\u00f5si, et mitte k\u00f5ik ei suuda endale seda luksust lubada, kuid mina teen alati just nii. Kui algab uus projekt, siis tavaliselt sokutatakse sellesse projekti k\u00f5ik katsetamata praktikad. Kui projekt on noor, ei riskime me eriti millegagi. Prod veel ei eksisteeri, seega pole midagi kaotada. Seet\u00f5ttu saab seda kasutada treeninguna. Selline l\u00e4henemine t\u00f6\u00f6tab. Aga mitte k\u00f5ik ettev\u00f5tted ei saa endale lubada selliste projektide tihedat algust. Kuigi see on ka veidi kummaline, kuna praegu toimub pidev digitaalne transformatsioon, peaksid k\u00f5ik eksperimente k\u00e4ivitama, et konkurentide ees p\u00fcsida.<\/em> <\/p>\n<\/p>\n
Siin tabad end olukorrast, kus sul peab esmalt olema arusaam sellest, mida sa tegema pead. Maailm ei ole ideaalne, prod ka ei ole ideaalne. <\/p>\n
<\/p>\n
Jah, need asjad on omavahel seotud.<\/em><\/p>\n<\/p>\n
\u00c4rivaldkonnas ei ole ka alati selgust, et nad peavad sinna suunda liikuma. <\/p>\n
<\/p>\n
On olukord, kus muutused ei ole \u00fcldse v\u00f5imalikud. See juhtub siis, kui meeskonnale avaldatakse suuremat survet. Meeskond on juba \u00fcsna v\u00e4sinud. Neil pole \u00fcldse reservi katsetamiseks. Nad t\u00f6\u00f6tavad hommikust \u00f5htuni funktsioonide kallal. Ja juhtkonnale tundub, et funktsioone pole kunagi piisavalt. N\u00f5utakse aina rohkem ja rohkem. Sellises olukorras ei ole \u00fcldse mingeid muutusi v\u00f5imalik teha. Meeskonnale saab \u00f6elda ainult, et homme teeme nagu eile, lihtsalt tuleb teha funktsioon veidi rohkem. Mingeid \u00fcleminekuid uutele praktikale ei ole v\u00f5imalik teha. See on klassikaline olukord, kus pole aega kirvest teritada, peab puid langetama, seet\u00f5ttu langetatakse nurgataguse kirvega. Siin pole lihtsaid n\u00f5uandeid.<\/em> <\/p>\n<\/p>\n
(Dmitri) Loen v\u00e4lja t\u00e4psustuse vestlustest: \u00abAga vajame suurt testimise katvust erinevatel tasemetel. Kui palju aega testimisele kulutatakse? Tundub, et see on liiga kallis, v\u00f5tab palju aega.\u00bb<\/em><\/p>\n<\/p>\n
(Oleg) See on klassikaline eksiarvamus. Testide peab olema piisavalt, et teil endil oleks kindlus. Continuous Integration ei ole selline asi, kus k\u00f5igepealt tehakse 100% teste ja alles siis hakatakse seda praktikat rakendama. Continuous Integration v\u00e4hendab teie kognitiivset koormust, kuna iga muudatus, mida te n\u00e4ete, on nii ilmselge, et te m\u00f5istate \u2013 kas see rikub midagi v\u00f5i mitte, isegi ilma testideta. Te saate seda kiiresti oma peas testida, kuna muudatused on v\u00e4ikesed. Isegi kui teil on ainult k\u00e4sitsi testijad, on neil samuti lihtsam. Te esitate ja \u00fctlete: \u201eVaata, ei ole midagi katki?\u201d Nad kontrollivad ja \u00fctlevad: \u201eEi, ei ole midagi katki.\u201d Sest tester teab, kuhu vaadata. Teil on \u00fcks commit seotud \u00fche koodijupiga. Ja see v\u00e4ljendub konkreetses k\u00e4itumises.<\/em><\/p>\n<\/p>\n
Siin oled sa muidugi natuke ilusamaks teinud. <\/p>\n
<\/p>\n
(Dmitri) Siin ma ei n\u00f5ustu. On olemas praktika \u2013 testimise kaudu arendamine, mis just sellest p\u00e4\u00e4stab.<\/em> <\/p>\n<\/p>\n
(Oleg) Siin, ma ei ole veel sinna j\u00f5udnud. Esimene illusioon on see, et tuleb kirjutada t\u00e4pselt 100% teste v\u00f5i et Continuous Integrationiga ei tule \u00fcldse tegeleda. See ei ole t\u00f5si. Need on kaks paralleelset praktikat ja need ei s\u00f5ltu otseselt \u00fcksteisest. Teie testide katmine peaks olema optimaalne. Optimaalne t\u00e4hendab, et te olete ise kindel, et see kvaliteet, millega teie master p\u00e4rast commit'i j\u00e4\u00e4b, lubab teil kindlalt vajutada nuppu 'Deploy' reede \u00f5htul, isegi joobes. Kuidas te seda saavutate? \u00dclevaatete, katmise ja hea j\u00e4lgimise kaudu.<\/em> <\/p>\n<\/p>\n
Hea j\u00e4lgimine ei erine testidest. Kui te k\u00e4ivitate teste ainult \u00fche korra pre prod'is, siis kontrollivad nad teie k\u00f5iki kasutajate stsenaariume ainult korra. Kuid kui te neid k\u00e4ivitate l\u00f5pmatus ts\u00fcklis, siis on see teie rakendatud j\u00e4lgimis\u00fcsteem, mis katab pidevalt k\u00f5ike \u2013 kas on kokku kukkunud v\u00f5i mitte. Sel juhul on vahe ainult korduvuses. V\u00e4ga hea testide komplekt, mida k\u00e4ivitatakse l\u00f5pmatult, on j\u00e4lgimine. Ja \u00f5ige j\u00e4lgimine peaks olema just selline.<\/em> <\/p>\n<\/p>\n
Ja seega, kuidas te j\u00f5uate sellesse olekusse, kui te reede \u00f5htul oma koodi juurutate ja koju lahkute, on teine k\u00fcsimus. V\u00f5ib-olla olete lihtsalt julge peast soe.<\/em> <\/p>\n<\/p>\n
Naaseme hetkeks tagasiviivale pidevale integreerimisele. Oleme natuke teise keerulise praktikaga k\u00f5rvale p\u00f6\u00f6rdunud. <\/p>\n
<\/p>\n
Ja teine illusioon on see, et MVP-d tuleb kiiresti teha, seega pole testid \u00fcldse vajalikud. See pole p\u00e4ris nii. Asi on selles, et kui te kirjutate MVP-s user story, siis on selle arendamine v\u00f5imalik kas kiirelt, st kuulete, et kuskil on mingi user story ja kohe hakkate seda kodeerima, v\u00f5i t\u00f6\u00f6tada TDD j\u00e4rgi. Ja TDD praktika n\u00e4itab, et see ei kesta kauem, st testid on pigem k\u00f5rvalm\u00f5ju. TDD praktika ei seisne mitte testimises. Kuigi see kannab nime Test Driven Development, on seal tegelikult tegemist millegi muuga kui testidega. See on pigem arhitektuuriline l\u00e4henemine. See on l\u00e4henemine, kuidas kirjutada t\u00e4pselt seda, mida on vaja, ja mitte kirjutada seda, mis pole vajalik. See praktika keskendub sellele, kuidas j\u00e4rgmist iteratsiooni teie arengu m\u00f5ttes rakenduse arhitektuuri loomisel saavutada.<\/em> <\/p>\n<\/p>\n
Seet\u00f5ttu ei ole neist illusioonidest nii lihtne vabaneda. MVP ja testid ei excluded \u00fcksteist. Tegelikult, vastupidi, kui teete MVP-d TDD praktikaga, siis teete selle paremini ja kiiremini kui lihtsalt proovimata.<\/em><\/p>\n<\/p>\n
See on v\u00e4ga ebamugav ja keeruline m\u00f5te. Kui kuulete, et n\u00fc\u00fcd hakkan kirjutama veel teste ja samal ajal teen midagi kiiremini, k\u00f5lab see t\u00e4iesti ebaadekvaatselt. <\/p>\n
<\/p>\n
(Dmitri) Siin paljud, kui r\u00e4\u00e4givad MVP-st, on inimestel laisk kirjutada midagi korralikku. Need on siiski erinevad asjad. \u00c4rge muutke MVP-d mingiks halvaks asjaks, mis ei t\u00f6\u00f6ta.<\/em> <\/p>\n<\/p>\n
Jah-jah, sa oled \u00f5ige.<\/p>\n
<\/p>\n
Ja siis \u00e4kki MVP prod.<\/em><\/p>\n<\/p>\n
Igaveseks. <\/p>\n
<\/p>\n
TDD k\u00f5lab esialgu v\u00e4ga ebatavaline, kui kuuled, et kirjutad teste ja tundub, et teed rohkem t\u00f6\u00f6d. See v\u00f5ib tunduda kummaline, kuid tegelikult on see t\u00f5husam ja elegantsem. Kui sa kirjutad testi, m\u00f5tled juba peas palju selle \u00fcle, millist koodi ja kuidas sa kutsud, samuti millist k\u00e4itumist me sellelt oodata saame. Sa ei \u00fctle lihtsalt, et ma kirjutasin mingi funktsiooni ja see teeb midagi. Esmalt sa m\u00f5tled, et sellel on sellised tingimused ja nii kutsutakse seda. Sa katad selle testidega ja seel\u00e4bi saad aru, kuidas sinu koodi sees olevad liidesed v\u00e4lja n\u00e4evad. See m\u00f5jutab arhitektuuri v\u00e4ga palju. Su kood muutub automaatselt moodulamaks, sest sa p\u00fc\u00fcad esmalt m\u00f5ista, kuidas sa seda testida saad, ja alles seej\u00e4rel kirjutad selle. <\/p>\n
<\/p>\n
Minu TDD teekond oli selline, et \u00fchel hetkel palkasin Ruby mentori, kui olin veel Ruby programmeerija. Ta \u00fctles: \"Teeme nii, et sa hakkad TDD-d rakendama.\" M\u00f5tlesin: \"Issand, n\u00fc\u00fcd pean veel midagi lisaks kirjutama.\" Lepisime kokku, et ma kirjutangi j\u00e4rgmise kahe n\u00e4dala jooksul kogu olemasoleva koodi Pythonis TDD p\u00f5hjal. Kahes n\u00e4dalas sain aru, et ma ei taha enam tagasi minna. Kahe n\u00e4dala jooksul p\u00fc\u00fcdes seda igal pool rakendada, m\u00f5istsin, kui palju lihtsam on isegi lihtsalt m\u00f5elda. Kuid see ei ole ilmselge, seega soovitan k\u00f5igil, kellele tundub, et TDD on keeruline, aegan\u00f5udev ja \u00fcleliigne, proovida seda j\u00e4rgida ainult kaks n\u00e4dalat. Minule piisab kahest.<\/p>\n
<\/p>\n
(Dmitri) Saame selle m\u00f5tte infrastruktuuri k\u00e4itamise vaatenurgast lahti. Enne kui k\u00e4ivitame midagi uut, teeme me monitooringu ja seej\u00e4rel k\u00e4ivitame. Sel juhul muutub meie monitooring normaalseks testimiseks. Ja arendamine toimub monitooringu kaudu. Kuid enamik inimesi \u00fctleb, et see v\u00f5tab kaua aega, mul on laisk, tegin ajutise mustandi. Kui me teeme monitooringu korralikult, saame aru CI s\u00fcsteemi seisundist. CI s\u00fcsteemis on palju monitooringut. Saame aru s\u00fcsteemi seisundist, m\u00f5istame, mis selle sees toimub. Ja arendamise ajal loome s\u00fcsteemi, et see saavutaks soovitud oleku.<\/em> <\/p>\n<\/p>\n
Need praktikad on olnud tuntud juba ammu. Arutasime seda umbes 4 aastat tagasi. Kuid nelja aastaga ei ole praktiliselt midagi muutunud.<\/em> <\/p>\n<\/p>\n
K\u00e4esolevates m\u00e4rkustes soovitan ametliku arutelu l\u00f5petada.<\/em><\/p>\n<\/p>\n
Video (sisestatud meediaelemendina, kuid mikski ei t\u00f6\u00f6ta):<\/p>\n
\nhttps:\/\/youtu.be\/zZ3qXVN3Oic<\/a><\/noindex> habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041e\u0431\u0441\u0443\u0434\u0438\u043c \u043f\u043e\u0447\u0435\u043c\u0443 CI-\u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b \u0438 CI \u2013 \u044d\u0442\u043e \u0441\u043e\u0432\u0441\u0435\u043c \u043f\u0440\u043e \u0440\u0430\u0437\u043d\u043e\u0435. \u041a\u0430\u043a\u0443\u044e \u0431\u043e\u043b\u044c CI \u043f\u0440\u0438\u0437\u0432\u0430\u043d\u043e \u0440\u0435\u0448\u0438\u0442\u044c, \u043e\u0442\u043a\u0443\u0434\u0430 \u0432\u043e\u0437\u043d\u0438\u043a\u043b\u0430 \u0438\u0434\u0435\u044f, \u043a\u0430\u043a\u0438\u0435 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043f\u043e\u0434\u0442\u0432\u0435\u0440\u0436\u0434\u0435\u043d\u0438\u044f \u0447\u0442\u043e \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442, \u043a\u0430\u043a \u043f\u043e\u043d\u044f\u0442\u044c \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 \u0435\u0441\u0442\u044c \u0438\u043c\u0435\u043d\u043d\u043e \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0430, \u0430 \u043d\u0435 \u043f\u0440\u043e\u0441\u0442\u043e \u0443\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u043d\u044b\u0439 Jenkins. \u041c\u044b\u0441\u043b\u044c \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0434\u043e\u043a\u043b\u0430\u0434 \u043f\u0440\u043e Continuous Integration \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u0435\u0449\u0435 \u0433\u043e\u0434 \u043d\u0430\u0437\u0430\u0434, \u043a\u043e\u0433\u0434\u0430 \u044f \u0445\u043e\u0434\u0438\u043b \u043f\u043e \u0441\u043e\u0431\u0435\u0441\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u044f\u043c \u0438\u0441\u043a\u0430\u043b \u0440\u0430\u0431\u043e\u0442\u0443. \u041f\u043e\u043e\u0431\u0449\u0430\u043b\u0441\u044f […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":93886,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-93885","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Continuous](\"\/wp-content\/uploads\/2020\/09\/ed8a32ae63b8dccfc8b4893ab27f1527.jpg\")
<\/p>\n