Roze

Laikapstākļi http://www.theregister.co.uk/2016/06/05/aws_oz_downed_by_weather/ un (ganjau) koderi http://www.theregister.co.uk/2015/09/20/aws_database_outage/ :)

Labi es vēl saprotu, ka visi grib/meklē all-in-one DBA/tīklinieku/Sysadminu/Devopu (būtu labi arī ja vēl kodētu un photoshopā kaut ko uzzimēt spētu) utt.. kā arī.sistēmas dokumentācija / procedūru izstrāde ir viens, bet .. .. ja vēl jānodarbojas ar supportu gala lietotājiem, kas potenciāli var neko nesaprast, tad nez.. reizēm šķiet, ka tomēr tās vēlmes pārāk nenopietnas (varjaubūt gan, ka tikai man tā šķiet).

Webaplikācijām (php) prepared statementus diezgan reti kur var jēdzīgi izmantot, jo tie darbojas tikai sesijas/konekcijas ietvaros. Ko standartā esmu novērojis ir, ka vai nu cilvēki cītīgi loopaa katru (vienuntopašu) kveriju "prepāro", tad izpilda (nav loģikas vai konkrētais kverijs ir iepriekš jau preparots) vai arī pieslēdzas, prepāro, izpilda, atslēdzas .. kur pa lielam tam no performances viedokļa DB ir vairāk darba nekā pārsēt un izpildīt parastu SQL. Lai būtu jēga/ieguvums šādos gadījumos, tad ir jāraksta Stored procedūras, tad efektam ar "prekompilētu" kveriju būtu jābūt līdzīgi kā pēc prepared statementa (bet bez vajadzības to darīt katru reizi). https://www.postgresql.org/docs/current/static/plpgsql-overview.html#PLPGSQL-ADVANTAGES

Ja DB glabāts no php, tad viens no variantiem ir, ka pēc konekcijas ir aizmirsts uzlikt SET NAMES 'utf8' .. php noklusēti (vismaz līdz šim) slēdzās ar 'latin' kodējumu.. Es tāpēc parasti visiem DB serveriem lieku šādu kombināciju: [mysqld] skip-character-set-client-handshake character-set-server=utf8 // vai utf8mb4 ja vajag pilnu kas principā ignorē klienta sūtītās opcijas (nav arī jālieto SET NAMES vairs) un vienmēr izmanto UTF8. Jāfiksē ir droši vien noselectējot kā 'latin,' tad konvertējot uz utf8 (ar php vai piem. no komandrindas ar iconv) un liekot atpakaļ jau ar pareizu konekcijas enkodingu.

Heh http://pietiek.com/raksti/kaspar_foigt,_ar_kadam_tiesibam_jus_esat_publiskojis_personas_vardu_un_uzvardu

A jēga uzdevumam jebšu kam tas domāts/plānots? Jo nu tikpat labi vari paņemt linux kerneli, tad un vienā C failā tur iebakstīt printf("foofofooo\n") (protams ar pārējiem vipendroniem) .. tb skatīt Master Programmer @ http://roze.lv/Evolucija.txt

"Kad tas notiks" nezudīs jēga no "vēlēšanām"? Proti, lēmumu par piemērotāko tikpat tad varētu pieņemt pats algoritms, vadoties pēc kandidātu parametriem (vai ieteikt, jo, velkot zināmas paralēles ar "robotikas likumiem", sfērā mēģina turēties pie principa, ka pamatfunkcija ir atbalsts, ne pilnīga lēmuma pieņēmēja (cilvēka) aizstāšana (tabu)). Bet vispār DSS (decision support systems) ir interesanta tēma kibernētikā..

Tādu true-remote-only kompāniju esmu redzējis tikai Gitlabu / attiecīgi https://about.gitlab.com/jobs/ .. filozofējot par programmētājiem, transportu un sastrēgumiem droši vien kādā brīdī uzņēmumam varētu būt interesanti iegādāties kaut kādu elektroautoparku un tad pa sabtransa joslām ;)

Ticēt rakstītajam .. Personīgi nācās tikt nedaudz pāri nepatikai pret Javu (bērnības traumas), bet Elastics noteikti ir gan labāka object store (vs Mongo) gan search engine (Lucene v0v), gan replikācijas (automagically shardings/clusterings utt), proti, ja ir vēlme var pilnībā iztikt tikai ar ES (pretēji piem. ja izmanto kādu eksternālu meklēšanas pļurzuli kā Sphinx kuram rezultāti ir tikai dokumentu id).

Tiešām nebija nekāda atbilde? Tā nevajadzētu būt, proti, kaut kādai atbildei (pozitīvai vai noraidošai) būtu jābūt, ja nesaņēmi nekādu atbildi, tā nav pareiza/korekta procedūra. Ja vēl ir kāda nebūt interese atsūti lūdzu PM (ja gadījumā sūtīji no cita e-pasta, kā forumā reģistrēts) .. Jāņem vērā, ka labāk ir pieteikties caur webformu vai kādu no darbs@ .. e-pastiem, ar privātajiem darbinieku e-pastiem reizēm ir kā ir.. Programmētāji kā reiz tik daudz nekur nefigurē t.i. reti kad faktiski aktīvi sūta savus CV (slinkums mainīt ieradumus, kaut vai piedāvātais atalgojums u.c. bonusi iespējams ir lielāki) un lielākoties tiek atrasti no jau esošo darbinieku ieteikumiem vai tiešas uzrunāšanas ..

Piezoomo uz kādiem 300-400% tur viss ir ok .. In general tā ir pdf attēlošanas ķeska https://forums.adobe.com/message/5055494 un rezumē http://www.witti.ws/blog/2013/03/21/table-border-challenges-converting-word-pdf

Paeksperimentē .. Atkarībā no hostinga reizēm netiek diseiblotas php exec() shell_exec() utt funkcijas .. tad atliek tikai uzlikt (pa ftp) statiski sakompilēto wkhtmltopdf bināriju ( piem no https://github.com/h4cc/wkhtmltopdf-amd64) un tad tikai exec() vai `` vai proc_open() :)

Ūja .. alumīnija ultrabooki nav kaut kā redzēti 300-500 robežās .. Kad beidzot nomirs mans m1330 xps tad noteikti next būs šis (šī sērija).

Jocīgs gan "hostings" bez jebkādām pieejām + prasīt, lai hosteris "kodē php" (kas, protams, varētu būt saprotams no cilvēcīgā viedokļa, bet nav diez ko adekvāti, ja šādas lietas nav atrunātas savstarpējā sadarbībā/līgumā) - attiecīgi iespējas "uzmest lūpu" abām pusēm ir vienlīdz lielas. Nedaudz jocīga ir arī tā visa datu sinhronizācijas būšana, ja ir tik būtiski, lai kaut kādi klienti neredz veco serveri, risinājums ar die() ir so-so.. Proti, kas sanāk labāk - vai lietotājs redz normālu lapu kaut vai uz vecā servera vs kaut kādu īsu die() paziņojumu? Ja datu sinhronitāte ir tik svarīgi vienmēr ir tak iespēja salīdzināt vai nav radušies jauni ieraksti/faili/utt pēc migrācijas .. No tehniskā viedokļa, ja plāno migrāciju, tad kādu brīdi pirms tās domēnam var uzlikt ļoti īsu TTL (time-to-live), kas, protams, nav 100% garants (eksistē klienti/lietotāji ar īpatniem caching dns serveriem, kas reizēm to ignorē (forsē savu)), bet 99% gadījumos "downtaims" (vecais serveris -> jaunais) ir/var būt ļoti īss.

Tik un tā nešķiet, ka vārds "edgy" kaut kā attiecināms (varbūt kardināla atšķirība tulkojuma izpratnē). Taint ir mehānisms kā "ķert" vai koderis variabli ir "eskeipojis" TAJĀ SKAITĀ arī lietotot kādu template engini (un kas to varētu "labāk" zināt kā internāli pati valoda).. Tas, ka ir template engine, neliedz koderim kodā neatkarīgi no templates esamības izpildīt <? =$_GET['blabla']; ?> vai mysql_query(" ... id = $_POST['id']) .. crazy? Tā notiek realitātē. Tai pat laikā template engine (gatavi risinājumi) var radīt iluzioru iespaidu (vai pat sliktāk neradīt izpratni) par to, kas vispār notiek un kam tas vajadzīgs (laika gaitā ir nācies saskarties ar diezgan daudz šādiem gadījumiem).. Neviens nekur nebrauc, bet ir jocīgs komentārs (ar domu pirksti vēdeklī) "mēs te runājam par security" un tad to tomēr bāzēt uz cilvēka faktoru, kas vienmēr ir problēmātiskākais ..

Ko nozīmē "edgy" šajā gadījumā? (īsti nesaprotu arī kā konkrēto vārdu kaut kā attiecināt uz šo diskusiju) Taint principā ir Zend engines hooks, kas pasaka vai ar mainīgo ir veikta kāda apstrāde (untaints), ko varētu attiecināt uz "eskeipošanu", ko un kā programmētājs ir darījis ir cits jautājums. Ja "mēs šeit runājam" par "security", tad ir diezgan jocīgi (vai pat amizanti) piesaukt kaut kādus third-party template risinājumus, kuri lielākoties tiek pljek-snjek ievilkti ar visādiem package managariem on-the-fly un noteikti lielākais vairākums pat faktiski neskatās, kas konkrētajā kodā notiek paļaujoties uz tā autoru zināšanām/godaprātu vai kaut kādas publikas pozitīvu novērtējumu utt.. Cache menedžments / invalidācija utt ar aizņem resursus (reizēm pat lielākus) .. Datus pa lielam mēdz glabāt "normalizētus" .. Protams, teksta apstrāde 99% gadījumos būs pilnīgi nebūtiska, jo kverijs tieši virs tā būs patērējis 99% no visas lapas ielādes laika, attiecīgi investēt enerģiju tās optimizēšanā nebūs visai produktīva, Šeit domāju tīri sintētisku salīdzinājumu.. jo personīgi nedaudz nepatīk programmētāju atrunas par to "ka, tas jau neko neaizņem" un tad ir 1000 opkoda rindiņas "ar to neko" un galā cpu ir nodedzināts un renderēšanas laiks ir so-so..

Vispār jau šim ir risinājums (kas kā reiz forsē programmētājus pievērst uzmanību, kas notiek ar datiem (ne kaut kur "maģiski" kādā pluginfailā)) http://php.net/taint Nestrādā gan (vairs) uz 5.5.x un 5.6.x, bet tagad kā autors solījis izskatās ka ir releasota php7 ( http://pecl.php.net/package-changelog.php?package=taint&release=2.0.1) versija. No performances viedokļa (un ja dati/apstākļi ļauj t.i. nav būtisks oriģināls), tad "eskeipotus" glabāt ir krietni labāk nekā ziljons reizes transformēt pie izvades (tāpat ar visādiem nl2br() utt).

Nu nez, labāk jau pure php .. php visa būtība ir būt embeded html templeitam. Jo kad visādas templeitsistēmas (piem tas pats Twig) sāk darīt kaut ko šādu: {% for user in users %} * {{ user.name }} {% else %} .. t.i. redefinēt pašas valodas konstrukcijas, tad man liekas, ka tālāk vairs nav kur. Principā jā, tāpat kā eksistē sistēmas/distributīvi, kas aizliedz/kontrolē 'rm -rf /' jo kā izrādās ir, piemēram, iespēja http://linux.slashdot.org/story/16/02/01/1357237/running-rm--rf--is-now-bricking-linux-systems Tāpat arī ar visādiem "štrumentiem" nu CNC operātoram nevajadzētu būt iespējai (dot iespēju) izfrēzēt sev rokā caurumu :)

Tāda pieeja/loģika gan diezko forša nav. No otras puses Latvijā gan ir jocīgi precedenti, ka nezkapēc soda (mēģina) end-useri par "nepareiziem" ievaddatiem ..

Tā rupji rēķinot visam kas ir pāri okeānam 0.2 sec tīklā roundtrips aiziet viennozīmīgi .. Abet jocīgi (ka tik daudz).. google jau LV auditorijai savu cache instanci hostē tepat Telijas DC "Every project that creeps up is even more ambitious than the next. It all starts with a core module and 400 plugins for this module." - šis ir kas mani visvairāk tracina, atliek tikai piekrist developerim, ka vajag uzlikt uz servera composeri vai npm, kā sākas miljons un viena dependency ķeska utt :)

Šāds apgalvojums gan ir diezgan subjektīvs (uz lietotāja sajūtām balstīts). Šeit daži grafiki no tiem pašiem draugiem.lv (t.i. real world "keiss") t.i. secinājums var izdarīt dažādus, bet fakts ir ka serverside average ir 30ms kur klienta puse ir 3 sec .. Attiecīgi var domāt par to kuru galu optimizējot teorētiski iespējams gūt labākus "panākumus".

Īsti nesaprotu, ko domā ar "blobs ir dekompresēts pdf" .. Bet mans komentārs par kompresiju bija vispārīgs neņemot vērā konkrētu datu failu īpatnības. (bet arī 10% ir ieguvums :) ).

Par šo tēmu vienam vai otram variantam var nosaukt diezgan daudz gan pozitīvas gan negatīvas īpašības. Protams, ja faili ir 100, 1k vai 10k, tad par to īpaši nav vērts lauzīt galvu un, ja vien nepārspīlēs ar "risinājumu" un nesapīsies meistarībā, strādās jebkura no izvēlētajām metodēm. Ne vienmēr. DBMS bieži vien ir dažādas specifiskas tehnoloģijas, kas var uzlabot rakstīšanas ātrumu vs "pliks wraits uz diska" (nu piemēram rakstīšana (uzreiz) nemaz (buffered write) nenotiek uz fiziskā dzelža (šo gan var panākt arī ar parastām failsistēmām)). Protams, jārēķinās arī ar to, ka dažos gadījumos, piemēram MySQL, rakstot failu ierakstāmais apjoms var pieaugt pat 3 reizes (datu tabula + innodb logs + binlogs). Ja lieto readfile() (kas idejiski nav visai labs paņēmiens (labāk izmantot webserveru x-accel-redirect (analogi gan nginx gan apache) iespēju), tad starpība starp nolasīšanu no db un diska var arī nebūt nekāda. DB apjomu jā, bet ar datu apjomu vispār var būt arī otrādi - praktiski visas DB sistēmas nodrošina šādu vai tādu kompresijas iespēju, kas turpretī ir reti kurai failsistēmai (no tām kuras esmu lietojis tāda ir tikai BTRFS, ZFS un uz win NTFS). Lielām failsistēmām rezerves kopiju veikšana ir krietni sarežģitāka nekā DB - īpaši, ja jāveic inkrementāli (kaut cik jēdzīgas snapshot iespējas no nekomerciāliem risinājumiem, manuprāt, ir tikai ZFS un LVM) Otra lieta ir, ja ir daudz mazu failu, tad jāņem vērā arī tāds aspekts kā "vietas zaudēšana" dēļ failsistēmas block/stripe size, kur DB parasti viss tiek sapakots pāris lielos "klučos" kurus tas neietekmē. Lielākais failsistēmu mīnuss ir tāds, ka ir salīdzinoši lēnas metadatu darbības (ar SSD situācija protams ir uzlabojusies, bet tomēr) t.i. lai nolasītu failu (un informāciju par to) ir jāveic diezgan daudz zema līmeņa darbības (jālasa direktoriju struktūra/jameklē innodes utt), kas daļēji atkrīt DB gadījumā (vai pareizāk DB sistēma ir optimizēta datu meklēšanai/atrašanai).

Parasti gan, lai neskartos tam klāt (jo nu admini nekodē (bet tiem kā reiz sāp ar zilām liesmām degošas serveru instances)), pieliek priekšā kaut kādu Varnishu (un skeilo to) vai nopērk gatavu servisu aka Cloudflari, Fastly etc..

Var nebūt down, bet, piemēram, Cloudflares gadījumā Latvijā ir interesanta situācija .. p.s. līdz šim ar CDN būtiska problēma bija, ka zūd kontrole par failiem un to saturu (attiecīgi ir Man-In-The-Middle iespēja), tagad ar SRI ir šis tas atrisināts https://hacks.mozilla.org/2015/09/subresource-integrity-in-firefox-43/ un http://www.w3.org/TR/SRI/