codez

Pēc felony komentāra var 100% droši spriest, ka viņam nekad nav bijusi saskare ar šādu sistēmu izstrādi. Davai, fellony, interneta veikala linku uz reālu tavu "gudro" temperatūras sensoru (ar cenu). Piemērs - Massive multiplayer realtime spēle, kur katrs spēlētājs var izmainīt pasaules stāvokli + paralēli pasaules stāvoklis jāmodelē neatkarīgi no spēlētājiem. Bet nav brīnums, ka tu ar tādiem gadījumiem neesi sastapies, jo ņemies ar kaut kādiem vizītkaršu līmeņa projektiņiem.

Ko darīt, ja nu tomēr vajag izmanot masīvus un ne 1D, bet 3D un gadās pielaists memory leaku, kurš izpaužas 0,01% gadījumu? Programma palaista produkcijā un ik palaikam sāk neizprotami nokārties. Zaudēts dārgais laiks un klienti. Scalā tu raksti uz JVM palaižamu programmu. Nav nozīmes, vai tu to palaid kā dēmonu, vai palaid caur konsoli un kontrolē caur user interfeisu. Ja tu izmanto Akka bibliotēku, tad programmas komponentes darbojas diezgan neatkarīgi un tava programma vienlaikus var saturēt kā kontrolieri, kurš atbild uz http requestu, tā websocket handlerus, tā actor-u, kurš tiek izsaukts, piemēram, reizi sekundē vai reaģē uz citu actor-u sūtītām ziņām. Piemērā par sensoru lasīšanu tas varētu izskatīties šādi, ir MVC kontroleris, kurš pieprasa datus stāvokļa actor-am un aizsūta to klientam, ir sensora lasīšanas actor-s, kurš ar atbilstošu regularitāti lasa sensora datus un aizsūta tos stāvokļa actor-am. Ja datiem ir jāveic pietiekami sarežģīta apstrāde, var izveidot apstrādes actor-us, kurus palaižot var palaist, piemēram, caur actor-u routeri, kas ļauj šiem apstrādes actor-iem sūtīt apstrādājamo informāciju paralēla manierē, tādā veidā samazinot response laiku. Tas viss notiek vienas programmas ietvaros. Taču es varu šo programmu palaist uz vairākām fiziskām kastēm un sakonfigurēt, ka, piemēram, sensoru actori atrodas vienās kastēs, apstrādes actori citās un to savstarpējā komunikācija automātiski pāries no programmas slāņa uz TCP slāni.

Lai uzrakstītu pareizu multithread kodu, kur vairāki thread-i strādā ar datiem vairākās datu struktūrās, ir jāiegulda pamatīgs darbs un vajadzīgas precīzas zināšanas par visām niansēm. Ir jāievieš lock-i un sinhronizācija, jāievēro ļoti strikta (arī ierobežojoša) koda struktūra, lai netiktu likti lock-i uz ilgstošiem procesiem, netiktu likti tie paši lock-i funkcionalitātē, kura viena otru izsauc, jāievēro lock-u likšanas kārtība, pareizi jāapstrādā lifelock-i un deadlock-i, vispārīgā gadījumā, lai viss strādātu pareizi, ir jāievieš rollback-i. Varu saderēt, ka Felonijs nespētu pat korekti uzrakstīt multithread programmu, kura paralēli procesi izmanto, piemēram, Map-u, nerunājot par sarežģītākām datu struktūrām. Actor-u modelis tieši tāpēc arī tika izveidots, jo tas ļauj ātri, ērti, ar mazāku iespējamo kļūdu daudzumu, uzrakstīt paralēli darbojošos programmu, kura spēj izmantot visus pieejamos resurus un kura spēj jau defaultā kļūdu gadījumā pašatjaunot savu darbību ar pēc iespējas mazākiem "zaudējumiem". Bez tam Scala Akka actor-u modeļa paralēlums nebalstās uz multithreading-u, kurš ir lēns dēļ konteksta pārslēgšanās, bet ir event based risinājums, kurš māk darboties vairākos thread-os un izmantot visus CPU kodolus, tātad krietni ātrāks par tīru mutithreaded risinājumu.

Pamatošu kāpēc Node vai Scala ar Akka un Play freimworkiem ļoti labi iederas (labāk kā PHP) šādu uzdevumu veikšanai. Un kāpēc Scala der labāk par Nodi. Jāsāk ar to, ka PHP šādā gadījumā sastāvēs no divām daļām: pirmā būs background process, kurā notiks saziņa ar sensoriem, otra web backends. Scalas un Nodes gadījumā, abas šīs lietas atradīsies vienuviet. Apskatīšu pāris reālas dzīves iespējamās situācijas un kā tas izskatīsies katrā no sistēmām: 1)Sensors lasa 100 lasījumus sekundē un vajadzīgs attēlot pēdējās stundas datus. PHP - web backendam un sensoru lasīšanas daļai ir caur kaut kurieni jākomunicē - visdrīzāk caur kaut kādu db. Tā varētu būt mysql, litesql vai memcached. Visos gadījumos jāraksta db saglabāšanas kods un no db nolasīšanas kods. Mysql un litesql gadījumā tas rada arī ievērojamu slodzi uz sistēmu, bet memcached gadījumā, pie programmas nobrukšanas pazūd pēdējās stundas dati. Node - glabājam js masīvā. Sensoru lasīšanas laika events nolasa datus iepušo masīvā, backend lasa no tā paša masīva. Nav nekāda starp komunikāciju overhead-a. Tomēr pret datu pazušanu programmas nobrukšanas gadījumā, būs jāuzraksta persistances kods (taču izmantojot kaut ko šādu, tas būs īss). Scala - izmantojam Akka, izveidojam Akka actor-u, kurš glabā stāvokli masīvā, sensoru lasīšanas actor-s sūta datus stāvokļa actor-am. Web backend paņem datus no stāvokļa actor-a. Nav nekāda starp komunikāciju overhead-a. Pie tam izmantojot Akka persistence, mēs iegūstam automātisku stāvokļa saglabāšanu un atjaunošanu, nobrukšanas gadījumā. 2)Sensoru datu lasīšanas un apstrādes kodā ieviesusies kļūda, piemēram, apstrādājot datus 0.001% gadījumu sanāk dalīšana ar nulli, vai vēl vairāk - grūti novēršama kļūdu kombinācija (piemēram, iespējams pārrāvums komunikācijā ar sensoru mikrokontroleri vai kas tmldz.) PHP - jāorganizē PHP background procesa atjaunošana, vai jāiebūvē globāls kļūdu pārķeršanas mehānisms. Node - viekāršā gadījumā kļūda būs vienā nolasīšanas eventa ciklā un nekas nav jādara, sarežģītākā gadījumā tas pats kas PHP. Scala/Akka - akka actor-i ir konfigurējami dažādiem kļūdu gadījumiem. Vienkāršā situācijā ieliekam, lai kļūdas gadījumā actors tiek pārstartēts. (Tas ir mēs nedaram neko, jo tas notiek defaultā). Kad rodas kļūda, attiecīgais actor-s tiek pārstartēt un visa aplikācija normāli turpina strādāt. Respektīvi Scala/Akka gadījumā pat, ja mums būs grūti notverama, reta un nepamanīta kļūda, visdrīzāk aplikācija turpinās normāli strādāt. 3)Memory leaks kodā PHP - jāorganizē background procesa atjaunošana pēc atmiņas pārpildes. Node - tas pats, kas PHP. Scala/Akka - actor-s pārstartējas un viss turpina normāli strādāt defaultā. 4)Performance: PHP - sensoru lasīšanas procesam 1 - threads, bloķējoša porta lasīšana, kas nozīmē, ka var rasties kaudze performances problēmu, vai arī ir jāveido sarežģītāka aplikācijas koda struktūra - respektīvi jāveito globāls cikls, kurā notiks visas programmas darbības. Node - 1 threads, nebloķējoša lasīšana, kas nozīmē, ka mums lasīšanas datus apstrādā atsevišķi callback-i. Vienkāršāka koda struktūra kā PHP gadījumā. Scala/Akka - multithread vide, bet bez visām multithread programmēšanas problēmām, pateicoties akka actoru vienkāršajai arhitektūrai + nebloķējoša portu lasīšana + automātiski varam dabūt datu apmaiņu starp stāvokļa un porta lasīšanas actoriem starp vairākiem PC, kas ļauj izveidot liela skaita sensoru lasīšanu no vairākiem PC, tikai ar konfigurācijas rindiņas palīdzību (bez papildus koda).

Parādi kur.

Scala patiesībā ir ļoti pat normāls rīks šādiem uzdevumiem, it sevišķi, ja tev būtu jālasa tas viss no 100k sensoriem uz 50 kastēm un jāreaģē dažu ms laikā, ņemot vērā lielu skaitu lasījumu. Bet vienkāršā gadījumā tīri labi noderētu arī Pyhton-s vai Node. P.S. Un pa laikam iečekojot, ko labu piedāvā, piemēram, UK - tad PHP, js, python, utml. algas sludinājumos svārstās no 100 - 300 GBP / dienā, kamēr Scalai tās ir no 500 - 800 GBP / dienā.

Izvadi pirms tās nestrādājošās rindas console.log(JSON.stringify(this.state.r), JSON.stringify(k.id))

Tāda, ka Scala pašlaik ir labākā JVM statiski tipētā valoda un daudzi JAVAisti jaunos projektos izvēlas Scalu un arī šādus tādus vecus, kuriem vajadzīgas Scalas fīčas (asinhronītāte, responsivitāte), migrē uz Scalu. Piemēram, viena no lielākajām IT kompānijām Latvijā "Evolution Gaming" arī migrē no Javas uz Scalu: https://www.evolutiongaming.com/jobs/scala-developer Ja nemaldos LV startups Reachly izmanto Scalu. Zinu vēl pāris vietas, kur projektā vajadzīgas ātras un paralēlas kalkulācijas un kur pamatā izmanto Scalu.

Node, Python un Scala arī ir.

Latvijā vidējā alga ir ap 700 EUR, vai šādu algu piedāvājat?

Kur tava attieksme? Darba sludinājuma vajadzēja būt aptuveni ar šo:

1 apmeklējums ģenerē no dažiem līdz pat vairākiem desmitiem un pat pāri simtam pieprasījumu (.css, .js, .jpg, etc.), atkarībā protams no lapas struktūras.

Vai gadījumā pie MsSQL -> MySQL migrācijas nebūs jāpārraksta liela daļa koda?

Pfff, tās rūpnīcas bija par 20 - 30 gadiem atpalikušas no pārējās pasaules - kā jau praktiski viss padomju savienībā. Bet ko var gribēt no "kultūras", kas vairāk kā tūkstoš gadu balstījusies uz citu zemju iekarošanu un izlaupīšanu. Par laimi tagad Latvija vairs tur nav un šis tas moderns sāk notikt arī Latvijā.

Nē, nu saprotams, ka standarta web projektam es nekad tā nedarītu, bet teiksim, ja ir jāuztaisa kāds viegli šipojams produkts, kuram prasības pēc apjoma nav tik lielas un var pat izmantot kādu embedojamu db, tad, lai viss projekts būtu vienā .jar failā, varētu arī atļauties failus glabāt db.

Kur joins? Kur selektoti tikai konkrēti lauki?

Var jau netaisītu kešu pats vispār, servējam failus no db ar vienalga kādu backend-u, priekšā pieliekam Varnish, kurš tad arī visu automātiski kešo. Primo reizi attēlu paņems no db, pēc tam, kamēr vien regulāri tiks pieprasīts, nāk no Varnish. P.S. Piemēram, saliekot Varnish priekšā, Elasticsearch ar šo pluginu pakaļā, var ar pāris rindiņām un bez nekādām baigām zināšanām uztaisīt milzīgi lielu, viegli platumā skeilojamu bilžu glabāšanas klasteri. (Ne optimālākais variants, bet ļoti ātri radāms). Protams, ideālā gadījumā būtu jāņem distributētas failu sistēmas, bet tās konfigurēt ir par kārtu sarežģītāk kā Elasticsearch-u.

Kādam maksā par šādu bezjēdzīgu sludinājumu sacerēšanu?

Tops: http://php.lv/f/index.php?app=members&module=list&max_results=20&sort_key=posts&sort_order=desc&filter=ALL

P.S. Sapratāt?

Pfff, uzvar tas, kuram visvairāk postu.

Jā, modeļa lauku un attiecīgo db tabulas lauku. Jautājums vairāk par to, kuru definē pirmo un kuru ģenerē. Tā kā dēļ šiem specifiskiem laukiem, modelis ir augstāku abstrakcijas pakāpi, tad tā vai tā sanāk, ka jādefinē ir modelis no kura ģenerē db shēmu, nevis otrādi. Teiksim, man Scalā ar Slick ir šāds princips - definēju modeļa lauku, kuriem automātiski tiks uzģenerēta shēma. Standarta lauki: def id = column[Long]("id") def name = column[String]("name") Bet varu laukam izvēlēties arī tipu pilnīgi brīvi: def json = column[JsObject]("json") def customClass = column[MyClass]("myclass") def standartContainer = column[Map[String, String]]("map") utt. Tālāk, man vajadzīgs tikai definēt kāds būs maperis starp modeļa lauku un db kolonnu, kas standarta datu struktūrām ir automātiski. Mans sākotnējais komentārs bija vairāk par to, ka beigu beigās tik un tā izdevīgāk ir definēt modeli un ģenerēt db shēmu, nevis otrādi.

Kā jūs darāt - veidojat shēmu db un tad ģenerējat modeļus? Kā tādā veidā var, piemēram, specifiskus laukus kā json, array, class, utml. norādīt?

Dzirdēt un izmantot ir 2 dažādas lietas. Gribētu redzēt kā tajā hipsteru pierakstā tu javascriptā rakstītu anonīmas funkcijas, nestētus json objektus, utml. Šitā? (function(obj) { if (obj.a == 1) { doSomething(obj.b) } else { doSomething2() } } ) ( { "a":1, "b": { "c":2, "d":3 } } )

Tas, ka tu raksti angliski latviešu forumā, tavu teikto nepadara gudrāku. Kārtējais hipstera izgājiens?