F3llony

Labs apraksts, really advanced tas viss. Tas jūs paši līdz tam nonācāt, vai tas ir tāds kā tipisks risinājums web projektiem, kas tā kā mazliet palielāki? Kā izstrādātāji jūtas, nesanāk liels overheads? Un ko nozīmē deploymenti vairākas reizes dienā? Frontendā es saprotu - podziņa tur vai šurp, bet backendā.. Nu vispār arī saprotu, tiek kaut kas uztaisīts un pēc relīzošanas jau kādu laiku šis tas jāpamaina.

 

Un kā tas sanāk, kādas ir iespējas? Jo esmu arī mega pūce. Nav problēmu piecelties arī 6os, bet es nespēju domāt no rītiem. Jau no pirmajām klasēm visu patiesībā mācījos vakaros, pildot mājasdarbus, man ilgi nepieleca, ka citi skolēni mācās arī stundu laikā. Nezinu, varbūt ar ķīmiju kaut kas saistīts. Tagad arī, ja no rīta esmu uzcēlies, varu darboties, bet ne jau sēžot pie datora, to fiziski nespēju. :D (ar fiziski es domāju tiešām fiziski. Vakaros nav problēmu - varu kaut līdz rītausmai nosēdēt nepieceļoties.)

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.

Nu vot tas ir reāli complicated stuff. Man tādas lietas nepatīk.

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...

Karoče incoming flame no F3llony in 3... 2... 1...

Jo? Tikai tāpēc, ka tev tā gribētos? :D

Ellē ratā visu automatizāciju, nafig vispār pieņemti standarti! Jurčiks visu labāk zina :)

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 davaj, aizej uz Dyninno un salabo. I dare you.

3., 4. Sure. Jo tas, ka es nezinu 1 tūli, nozīmē, ka es neesmu ieinteresēts to iemācīties, ja tas nepieciešams darbam...

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.

Ne visi izmanto tos "vispārpieņemtos" standartus. Man, personīgi, daļa no PSR noteikumiem liekas stulba un es tos netaisos ievērot.

Tāpēc jau tavs kods izskatās tā, itkā mans 3gadnieks būtu vienkārši nomaucis pa pogām ar plaukstu.

1. Kā tad, jāsamierinās ar vecu softu, vai ne?

2. Es teicu preferred, nevis required.

3. "var būt koda stila pārbaude". "Tu to zinātu, ja vismaz pacenstos apzināt tos tūļus" - except man nevienā darbā nav nācies tos izmantot. Kad nāksies, tad iepazīšu.

4. Visiem jau tāpat ir skaidrs, ka tu ienīsti visus citus koda stilus, kas kaut nedaudz atšķiras no PSR. I don't give a fuck, es neesmu robots, man ir savs viedoklis un savs stils. Un es nebūt neesmu vienīgais. Nāksies vien deal with it.

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. 

 

Šo ir elementāri atrisināt, jo ir vispārpieņemti standarti.

Piemēram, mēs uzliekam Stormam, lai tas lieto PSR1/PSR2 stilu. Visi koderi lieto IDĒ auto-format.

Ja kāds lietotu citu editoru (dies` pasarg, nāktos konvertēt), tad noteikti arī tam varētu iestatīt konkrētu, vispārpieņmetu standartu.

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. Es vēlos strādāt ar modernām tehnoloģijām, un ja jau es meklēju jaunu darbu, tad man ir tiesības izvēlēties vietu, kura izmanto tās modernās tehnoloģijas.

2. Ir uzņēmumi, kuros ir preferred IDEs/editori/workflowi. Ja uzņēmums ofisā sponsorē PhpStorm (jo tas tomēr ir maksas produkts), tad tas arī ir liels pluss. Par tūļiem - atvaino, neviens nevar zināt visus tūļus (un nevajag arī).

3. Koda stilu neietur ar formatētāju uzstādījumiem (jo formatētāji katrai IDEi/editoram savi galu galā, neviens neies uzturēt up-to-date configus visiem editoriem), ir teksta dokumentācija, kā būtu jābūt. Kāds testiem/buildiem/pull requestiem sakars ar koda stilu? Kodam būtu jābūt noformatētam pareizi jau pirms tā.

4., 5. Dyninno ir tā - ir standarts. Nenormāli sūdīgs standarts, bet standarts, un tam ir jāseko, jo tā ir pateikts. Apstrīdi - vācies prom.

6. Dzērumā priekšnieki izsapņoja, 100%.

 

Bet vispār, atkal jau tu te ar savu augsto tehnoloģiju un complex workflow domāšanu...

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?

DYNINNO.

700/800 kantoris imo? Piemēram:

 

[...] racionāli domājošas smadzenes un gara pātaga, kas sniedzas līdz pat biroja galam. Visas grūtības, kuras rodas, uztveru viegli, bet ne vieglprātīgi, jo zinu, ka mūsu komanda, jaudas, tehnoloģijas (un mana pātaga) spēj kvalitatīvi atrisināt jebkuras grūtības.

- Ruslans, Tehniskais "guru"

???? 

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. 

Tiešām lielāka atdeve par kādu labi targetētu reklāmu caur, piemēram, FB audience?

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".

homofobs :D !!!

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.

Es strādāju lielā komandā, kur kopā ir kādi 6 projekti. Katram ir pa kādiem 2 projektiem un 10-15 uzdevumiem. Man arī ir 10 - 15 uzdevumi. Bet visos 6 projektos.

 

Es eju prom. Nevar tā strādāt. 

 

Eju tur, kur man būs pie 1 projekta jāstrādā.

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);

 

Domāju, ka internaly PHP visdrīzāk glabā to pašu 0.30....04, bet pie izvades viltīgi noapaļo.

 

P.S.

yep,

http://codepad.org/AZbcjiGw

echo ((0.2+0.1)===0.3)?"Yes":"No";

Output:
1 No

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

 

 

php > $x = bcadd(0.1, 0.2, 50);                                                                                                                                                                                                        

php > var_dump($x);

string(52) "0.30000000000000000000000000000000000000000000000000"

scala> 0.1+0.2
res0: Double = 0.30000000000000004

Nu tas jau ir floating point standarts un saistīts ar to kā atmiņā un procesora reģistros tiek glabāti flouting point mainīgie.

Ja kaut kur 0.1+0.2 = 0.3, tad visdrīzāk pa virsu ir uztaisīts kaut kas, bet tad vairs tā skaitļošana nav tik ātra.

 

P.S. Starp citu pasaule programmēšanas olimpiādē jau kādu laiku ir izņemti uzdevumi, kuros jāizmanto floating point mainīgie.

 

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.

Skumjākais ir tas, ka kaut kur reāli pastāv tāds kods (par šo skaidrs, ka parodija).

https://github.com/jezen/is-thirteen

Daļēji piekrītu, bet kad iemācies ar to visu strādāt, gala rezultāta ir viens pareizs ceļš kā panākt rezultātu.

Tā pat, kā jebkurā citā valodā. 

Par JS math. Pašlaik taisu web 3d spēli, kurā tiks implementēta lag kompensācija, kas nozīmē, ka man viens un tas pats algoritms jāsimulē uz klienta un servera. Klients - js, serveris - Scala. Pagaidām nekādas nesakritības matemātikā starp šīm platformām neesmu novērojis.

P.S. Bet par pārējo piekrītu. JS ir diezgan pļiekana valoda. Es būtu priecīgs, ja uz browseriem būtu kārtīga, strikti tipēta, funkcionāla, oo valoda kā Scala.

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

@F3llony Ja valoda būtu striktāka un konsistence saglabātos, šādu problēmu būtu mazāk. Pats kaut kad rakstīji, ka PHP storm (Laikam, tā to verķi sauca) ir viens no veidiem, kā grupas darbu ar PHP uzturēt kaut kāda kārtībā. Kas principā nozīme, ka ar teksta redaktoru tiek labotas valodas dizains. Iespējams kļūdos.

 

Man vairāk satrauc tas fakts, ka pēc ilggadējas pieredzes ar PHP, galīgi nelikās ka esmu kaut kur progresējis. Cik saprotu, vajadzēja pāriet uz kādu frameworku, kur vismaz konsistence ir izveidota. Tai paša laikā, ar JavaScript'u progresu jūtu ļoti strauji. Gan izstrādes ātrumā, gan risinājumu veidošanā. Iespējams esmu stulbs, neapstrīdu. :>

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...