F3llony

Semi-tipisks. Cik ar citiem komunicēju, zinu, ka ja ne vienmēr lietotas tās pašas tehnoloģijas, tad risinājumi ir ļoti līdzīgi, taču es nevarētu teikt, ka visi kaut ko tādu dara - personiskais iespaids ir drīzāk nē. Konkrēti Ebay/Magento, Skyscanner, AirBNB ir diezgan līdzīga kalibra sistēmas. Overheads developeriem pamatā nav nekāds - tiem, kas tikai programmē ir tikai branch-out/pullrequest-in un tikai skaties kad pullrequestā parādas komentāri no CI - build pass, build fail. Lokāli docker komandas ir enkapsulētas bash.rc skriptos, kas pievieno ap duci shortkutu, visiem nepieciešamajiem darbiem no php cli līdz npm install. Ja godīgi, tīri devam darboties ir ļoti, ļoti ērti - viss jauki aprakstīts, viss labi dokumentēts. Relīzes vairākas reizes dienā ir tāpēc, ka nepārtraukti tiek veikti uzlabojumi un izmaiņas, ir full-agile scrum, ir backlogs, kurā vienmēr ir kaut kas ko darīt, un darbi tiek pēc iespējas dalīti ļoti mazos gabaliņos, lai developerim nenāktos sēdēt nedēļām pie viena grandioza taska. Līdz ar to, 10 mazas izmaiņas dienā un 10 relīzes ir okei dīls. Parasti nav tik daudz, bet reizēm notiek. Patiesībā developeri ir diezgan priecīgi par šādu setupu, pie mums ir braukuši citi start-un-nestartapi skatīties, un vice versa, vienkārši atrādot un atstāstot, kā strādājam un skatīties ko dara citi. Kaut vai piemēra pēc, tie paši test buildi - ir 3 leveli kuros izķert kļūdas, code review un vēl manuāla testēšana. Dienas beigās sausais atlikums ir, ka produkcijā nopietnas kļūdas nonāk ļoti, ļoti reti. Pēdējo reizi ko atceros, bija pāris mēnešus atpakaļ, un arī tad problēma bija jauna veida statistikas datu pieglabāšana, ko no sākuma varēja vienkārši atmest un sākt glabāt pareizi, pa jaunam. Tas viss dod deviem tādu kā drošības sajūtu, mazina stresu. Viss, kas ir sabūvēts ir paradzēts tieši tam lai atvieglotu developeriem darbu un noņemtu nost visu noise un uztraukumus par infrastruktūru un ko tik vēl ne. Par tavu pūces problēmu, man ir līdzīga. Te vari ierasties jebkurā laikā starp 9 un 11, prom ej no 18-20, visi rēķinas, ka mītingi utt notiek periodā no 11-18. Nav nekas jāpiesaka vai jāsaskaņo. Gribi nāc 9, gribi nāc 11. Vasarās piektdienas pēcpusdiena pēc 14 brīva. Tādā gadījumā man Tev ir sliktas ziņas par Tavu profesijas izvēli.

Mums viss stāv uz Bitbucket. Visas iekšējās bibliotēkas (kas pamatā ir Symfony bundles) atrodas atsevišķās repozitorijās (uz doto brīdi tikai manā konkrētajā projektā ir pie 80 repozitorijām). Tā pat, kā projektiem, arī libām ir savi build procesi, kas pēc katra merge izlaiž jaunu versiju - automātiski. Par build un testu automatizāciju rūpējas Jenkins. Jenkins uzdevumi tiek automātiski ģenerēti no JJB konfigurācijas - kas cita starpā tiek pieglabāta atsevišķā repā, kas weirdly enough ar POST hūku pārģenerē visus Jenkins uzdevumus pēc tam, kad konfigurācija tiek pamainīta. Katram projektam/bibliotēkai gandrīz vienmēr ir 2 veidu testi - TDD specs (PHPSpec) un integrācijas testi (PHPUnit). Visas bibliotēkas seko pamatā vienai un tai pašai struktūrai, so pamatā ieviest jaunu šārējamu bundli prasa to vien kā pievienot jaunu repozitoriju un pāris rindas JJB. Visas versijas bibliotēkām pēc builda tiek pieglabātas arī Satis - tā sanāk ātrāk deploymenti, jo nav jaklonē no GIT + backup ja bitbucket nofeilo, buildi tapat darbojas sava nodabā. Deploy pamatā notiek izmantojot Capistrano (ir daži mazāki projekti ar Mina vai Deployer) - artefakti tiek sabūvēti lokāli un pēc tam izmesti attiecīgajā vidē. Pagaidām neprasās pēc CI artefaktiem - vidējais laiks pilnam produkcijas deploy atkarībā no projekta ir pārdesmit sekundes līdz 5 minūtes. Normālām mazizmēra izmaiņām, neskaitot code review un manuālu feature un acceptance testēšanu, viss cikls aizņem varbūt 10 minūtes. Deploy daudzums ir "cik vien gribi". Citas dienas ir 1,2 produkcijas relīzes, citas ir 10. Emergency deploy - ir tiešā ķēde uz master un deploy, pāris minūtes. Code review parasti veic protams pats autors un minimums 2 citi developeri, un ne obligāti no viena un tā paša projekta vai pat offisa - tas darās tāpēc, lai visi kantorī būtu +/- kursā par to, kas apkārt notiek. Visas izmaiņas un darbības pret produkcijas datubāzēm prasa vismaz vēl 1 cilvēka signoff - tajā skaitā, visi queries, kas neietilpst migrācijās (tiek smagi lietots pt-online-schema-change, ir daudz grandiozi masīvu tabulu). Izstrāde notiek apmēram šādi - vienmēr branch out no master uz atsevišķu branchu (ja liela izmaiņa un vairāki devi piedalās - feature branch, un tad papildus branchi). Ir divi mainstream branchi, master/production un integrācijas branch. Viss, kas atrodas master = produkcija, viss, kas atrodas integrācijā - ir integrācijas serveros. Ir arī development serveri, kur var manuāli izmest izmaiņas kas prasa vairāk testu, 3rd party signoff utt. Visas vides ir mirori no produkcijas. Integrācija tiek ļoti bieži uzpildīta ar pilnu produkcijas datu backup, parasti no tās pašas dienas. Pull requesti tiek veidoti pret integrāciju, tā pat kā merge. Pēc integrācijas merge notestē integrācijas serveros, izveido relīzi un tiek nodeployots uz produkciju. Visi testi tiek izpildīti Jenkins 3 reizes: 1. pirms merge integrācijā 2. pēc merge integrācijā ar automātisku deploy uz integrācijas serveriem 3. pēc relīzes uz master un pirms deploy. Testi tiek darbināti Docker vidē, kas ir maksimāli tuva produkcijai (pamatā, 100% klons), lokāli izstrāde arī notiek Docker vidē. Gan vieglāk saturēt dependencies, gan vieglāk jauniem cilvēkiem tikt klāt pie reālas izstrādes - initial setup aizņem pāris stundas, no kurām lielākā daļa aizņem lejupielādēt docker images un noklonēt projektu repas :P nekas no valodām un runtaimiem lokāli nav jāinstalē. Produkcijā viss griežas virtuālmašīnu fermās, konfigurāciju menedžē Puppet. Logus visas aplikācijas raksta dubultā - syslog un rotētos failos, syslog logus reportē uz centrālo Ellastic serveri, kam piekabināta Kibana un Elastalert - Kibana un Jenkins build statusi arī smuki uz ekrāna pie sienas tiek attēloti, pametot aci vienmēr zini vai nav kāda šaize. Pēc deploy Kibana var paskatīties, vai nav izmaiņas trafika plūsmā, utt. metrikās. Visu infrastruktūru monitorē Nagios un kaudze dažādu citu sistēmu - tiek monitorēts viss no response time, beidzot ar mongo opcounters. Bez šīm ir vēl daudz dažādu sistēmu, citi projekti, utt. utjp. Piemēram, android/ios aplikācijām flows nedaudz atšķiras, utt. utjp. Bet web side pamatā notiek šādi. Gan jau kaut ko piemirsu still... Jo? Tikai tāpēc, ka tev tā gribētos? :D

Pievienojos qwerty, ja nav grūti, moš pastāsti kā jums būvējas? Moš es ar saņemšos sarakstīt, kas un kā.

Ah, what the hell. :/

1. vot ja viņi būtu atvērti izmaiņām un maksātu atbilstoši manām spējām aizietu un salabotu arī. Ko tu domā, nekad neesmu ar vecu drazu saskāries? 3.,4. bet es jau sen pateicu, redzi kur tooļi X, Y, Z, palīdzēs tev darīt to un šito, tā un šitā, efektīvāk, labāk un ko tik ne. Kur tad bija tava interese? Pateici nafig, tā visa ir overkompleksa figņa, nafig vajag.

Tāpēc jau tavs kods izskatās tā, itkā mans 3gadnieks būtu vienkārši nomaucis pa pogām ar plaukstu. 1. How about fucking fixing it? 3.4. Nenāksies. Jo tevi vienkārši nevienā pieklājīgā darbā ar tādu attieksmi nekad neņems - pietiek kandidātu, kam patiesi arī interesē ko pie velna viņi dara.

http://cs.sensiolabs.org- you are welcome :P Mēs lietojam arī kā pre-commit huku, pasaka ja kaut kas nav noformatēts kā vajag pirms komita. Man papildus tam šis ir arī post-save hūks. Galvenokārt tāpēc, ka mums lieto kas katram ērtāk - IDEA, Atom, Vim, etc. Gala rezultāts - visiem viens. Plus ja ir dažādi stili dažādos projektos, ir .php_cs, kur var sakonfigurēt kā ienāk prātā. 1. Right. Good luck then. 2. Jā, ir tādi uzņēmumi. Saucas bedres, kam vairāk interesē internal policy kā produktivitāte. Ja cilvēks ir 10 gadus nolietojis VIM, kāpēc forsēt jamo lietot ko citu? Un Jetbrains tā kā sen jau vajadzētu sponsorēt visiem, by default. 3. Kāds testiem buildiem un pull requestiem sakars ar koda stilu? Tāds, ka viens no build stepiem var būt koda stila pārbaude. Piemēram, mums katrs pull requests iet caur CI serveri - atver pull requestu, post hooks painformē Jenkins, ka ir jauns pull requests. Jenkins novelk izmaiņas, automātiski samerdžo ar mērķa branchu (vai nu tā ir integrācija, vai produkcija), izpilda testus un novalidē mainīto kodu - tiesa, mums nepārbauda koda stilu, jo par to rūpējas pre-commit huki - so neglīts kods repā vispar nenonāk, nekad - taču man ir zināmi konkrēti kantori kur koda stils un lint, utt utjp tiek darbināts pret katru buildu, lai izvairītos no dajebkāda regresa. Visbeidzot Jenkins noreportē build statusu kā komentāru pie pull request. Tas viss automātiski, katru reizi kad upteito pull request un nulle interaction no programmetāja puses. Tu to zinātu, ja vismaz pacenstos apzināt tos tūļus, ko "nevajag arī". 4.5. PHP ir de-fakto stils, saucas PSR. Python, Java, HTML, JS, CSS, LESS, SASS ir savi standarti. Ja tas kantoris izmanto kaut kādu ļevu pašizdomātu figņu, nav brīnums, ka operē tur jefiņi, jo neviens normāls cilvēks uz to neprarakstīsies. Un ja atbilde uz pozitīvām izmaiņām ir "vācies prom", jebkurš, kurš vēl nav aizvācies ir jucis.

1. punkts depends. Ne visu var vienmēr pārcelt uz pēdējo versiju overnight. 2. lieto kādu ide/tūļus gribi. Kuru tas vispār interesē? Codebase ir vcs, a kā tu jamo raksti - da kaut ar kreisās kājas īkšķi. Par to, ka kāds izmanto tūļus, par kuriem tev nav nekādas sajēgas - tas jau tomēr akmens tavā lauciņā. 3. koda stila kontrolei ir attiecīgi instrumenti. Pirms atvērt pull requestu, neviens vairs buildus netaisa, testus nedarbina, neko, nē? Wtf? Kam visi tie CI un build serveri, kaķiem? 4. Merge request uz master? Tātad integrācija ir produkcija, un testējam produkcijā? WTF? 5. kādos nafig pāros? Katram pull requestam review (no >=2 cilvēku signoff, svarīgām izmaiņām arī no lead). 6. WTF? What is this? Did you loose a bet? Lai gan ko es te vairs komentēju... Problēma ir acīmredzama. Un jamā ir abās pusēs. Ko tad gaida uz kaut kādu pasakainu vidi ar tādu attieksmi...

@Mr.Key nē, parasti notiek tā, ka aizsūti CV un tad ir divpusēja intervija(s), kur cilvēki mēģina saprast, vai darbinieks der uzņēmumam un uzņēmums - darbiniekam. Savādāk sanāk "oj, man te nemaz nepatīk" pēc tam kad darba devējs tevī jau ieguldījis dienas/nedēļas/mēnešus laika (ja sanāk kantoris, kas to dara). @jurchiks Nu jamiem otrā lapa (oojo) man met 403. Ar 700/800 kantori es domāju 700/800 neto kantori. :D Bet 1200 nešto ir vēl ciešami... Lai gan no otras puses, nauda nav gluži vienīgais faktors. Edit: ko tu tajā githubā tādu ieraudzīji? Es palasīju repas, nekas tāds interesants acīs nekrīt... Kko palaidu garām?

700/800 kantoris imo? Piemēram: ???? Kā Tu jurchik vispār tur nonāci? Es pieņemu, ka backstory tur ir vismaz 0.5L vērts. Tā pat, kā 403 Forbidden showcase 2. pozīcijā.

Kas tā ir par bedri, par ko iet runa? Citiem par brīdinājumu.

Te arī paši dati. https://github.com/Addvilz/data Es tā padomāju, moš saspamojiet savus Githubus/Bitbucketus/Gitlabus, kurš nu kuram? Kazi kas noderīgs atradīsies...?

Sanāca vajadzība pēc kaudzītes datiem no Wikipedia "List of X by Y". Biju par slinku čakarēties 1by1, uzrakstīju šo - Chrome extension kas ļauj pagrābt jebkuru wikipedia tabulu kā CSV.

Depends, bet pamatā organiska meklēšana vienmēr būs ar augstāku conversion ratio kā vislabāk mērķētā reklāma, jo organiskie meklējumi ir "tagad vajag", un ja uztrāpa uz, piemēram, "nopirkt X" un cilvēks meklē X, ir ļoti liela varbūtība, ka X tiks nopirkts. Savukārt, ja tu reklamē "hey, varbūt tev vajag X?", atbilde "nē", būs daudz biežāka. Viens faktors ko ņemt šeit vērā ir "audience reach". Ja tu mārketē X un organiski jamo meklē varbūt 5k cilvēku dienā, bet tajā pat laikā tu izmet targeted reklāmu audiencei 500k dienā, conversion ratio pārsniegs organisko, tikai tādēļ, ka reklāma izmesta masveidā un nostrādā "o, bet man taču to X vajag".

Garām. Islamofobs, fat-shamer, body-ableist, white male cis scum. Kā tu uzdrīksties!

.nazi_piece_of_shit { display: none !important; }

https://www.jetbrains.com/pycharm-edu/

Izklausās pēc software house kaut kāda, Accenture vai tamlīdzīgs brīnums?

Jautrākais ir tas, ka ir pilna dibenpuse tādu "foršo" vakanču, es pat šeit iepostēju. Cik man uzrakstīja? Nulle. 6 projekti, katram pa 2, sanāk 3 cilvēki. Liela komanda where?

Tad ej dillēs. Tiem kam interesē - string reprezentācija tiek izmantota tāpēc, ka tad tiek garantēta precizitātes saglabāšana - gan tajā pašā, gan starp dažādām sistēmām, un vari būt drošs, ka reģistru izmērs nebūs faktors lai to floatu pieglabātu.

Kaspar neliels fail tev tur. Ieliec abus floatus pēdiņās as in string. <?php $x = bcadd('0.300000000000000004', '0.2', 50); var_dump($x);

Nu es kaut ko tādu arī gaidīju. Tajā pašā laikā, PHP ir arī standarta risinājums -

Es zinu, ka standarts, bet es apšaubu, ka daudzi šeit sagaida tādu rezultātu... :P Un nav jau tikai absolūtie 0.1 un 0.2, bet arī daļas (kā piemērā). PHP pastarītis redz izvada 0.3. https://github.com/jezen/is-thirteen

Tā pat, kā jebkurā citā valodā. Tev vienkārši veicas. Pagaidām. Par otro daļu - http://webassembly.github.ioun tad jau būs normāli transpaileri da praktiski no jebkuras valodas. :P > 0.2 + 0.1 0.30000000000000004 > 0.3 + 0.1 0.4 > 0.1 + 0.1 0.2 > 0.1 + 0.3 0.4 > 0.1 + 0.2 0.30000000000000004 > 0.9 + 0.2 1.1 > 0.1 * 0.2 0.020000000000000004 > 0.134 * 0.2 0.026800000000000004 > 0.134 * 0.155 0.02077

Es rakstīju, ka PHPStorm ir validatori un style guides kas palīdz saturēt kodu kārtībā, jebkurā valodā. Tas pats ar IntelliJ, Pycharm, CLion utt. Un nekādu progresu tu nejūti, jo JS ir vēl vairāk problēmu (pie tam, nopietnu, nevis argumentu kārtība un funkciju naming). Standarda library? Neeksistē. Scopes? Kas tas tāds. Type system ir smieklīga. You cant do math (or even pretend to do math), es varētu turpināt bezgalīgi...