Roze

Jānem AWS, to moš neviens īpaši nenogāzīs ;)

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

sniegt tehnisko atbalstu un konsultācijas lietotājiem ar dažādiem zināšanu līmeņiem. 

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

2) PDO prepare utt ir lēnāki par tiešu SQL. Man šķiet, ka PDO nolasa saistīto tabulu metadatus (struktūru), lai zinātu, kādi ir lauku tipi, un izveidotu statement.

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

Svarīgākais nosacījums programmai: tai ir jābūt pēc iespējas obfuscētai. Bez koda aizkodēšanas un ievērojot koda standartus (indents utt) ir jāpanāk to, lai kods izskatītos maksimāli sarežģīti, lai cilvēks no malas ar lielām grūtībām varētu saprast, ko programma dara.

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

Bet, kad tas notiks, tad pat uzvarēšana vēlēšanās būs atkarīga no tā, cik tavi algoritmi labi ģenerē reklāmas, preses relīzes, publisko informāciju un kā un kad šo informāciju pasniedz katram individuāli. 

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

Elasticsearch meklējumos pēc kompleksiem nosacījumiem krietni pārspēj Mysql.

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

Jau pasen pieteicos ar 15+ gadu pieredzi, t.sk, 3 GIS sistēmās. Pēc atbildes neesamības spriežot, neiekļuvu otrajā kārtā. No comments.

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

Attiecīgi arī iesūtīto pieteikumu daudzums ir milzīgs.

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

katrai otrajai tabulai lien ārā uz zoom=100%.

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

Tādi, kuriem ir tikai FTP access. Es darbā vairākās vietās, incl. PM, rakstīju, ka vajadzētu uz servera wkhtmltopdf dabūt, lai tos rēķinus varētu normāli ģenerēt, bet klusums. Visi ir līdz matu galiem darbos, jo paņemti 20x vairāk projekti, nekā spēj izpildīt.

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() :)

Apmēram 2-3x pārsālīti. 

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

tātad tu uzskati, ka tas ir normāli - maksāt par hostingu - un kad tev vajag tikt klāt failiem - tad skuju ... ???

 

...

6. lapa down, adminam pieejas nav, ftp pieejas nav, ssh pieejas nav, nekāda paneļa nav

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.

Es šeit par “edgy“ saucu *automātisku* security bugu ķeršanu, like this. https://secure.php.net/manual/en/intro.taint.phpTo darīt automātiski ir vairāk kā crazy. :)

 

Tas ko tev dod labs template engine ir automātiskais escapings. Tā vietā lai paļautos ka dators *uzminēs* kas ir slikts un kas nē, tu escapo visus mainīgos kas tiek padoti templatam

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

un tad vēl sāki man braukt virsū

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

Tas Taint izskatās ļoti, ļoti edgy.

 

Uzticēties, ka sistēma automātiski atradīs problēmas (this will 100% fail at some point) un tad uzticēties, ka kāds šos warningus ņems vērā (kāds piemirsīs, kaut vai netīšām)? Mēs šeit tomēr runājam par security.

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

Datus ir jāglabā as-is, nesapistus. Ja ir nepieciešams optimizēt, izmanto cache.

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

Tas ka plain PHP output escape by default nenotiek, bet template engine notiek un tam vairs nav jāpievērš speciāla uzmanība, izņemot vietās kur tu specili forcē templeitam rādit neeskeipotu saturu.

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

Ja jāizvēlas būtu pašam, tad es pat nezinu ko ieteiktu. Lai arī pure php ir tuvāks sirdij, es gribu ticēt, ka ir kas labāks.

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.

Paga, analoģiski nepieļaut būtu aizliegt, piemēram, servera administratoram pieejamajā SQL konsolē izpildīt "DROP TABLE".

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

Es pieļauju, ka šajā gadījumā lietotājs ir tās frēzes operators, kurš, ja grib, tad jebkurā gadījumā var palaist uz CNC kaut ko pēc būtības nepareizu.

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

Uz USA east cost RTT būs vismaz 70ms(šitas ir straight line no Rīgas līdz New York)

Tā rupji rēķinot visam kas ir pāri okeānam 0.2 sec tīklā roundtrips aiziet viennozīmīgi  .. 

Man pings uz google.com - 30ms

pings uz tvnet.lv - 9ms

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

Atver draugiem.lv, tur runā plūsma arī tiek renderēta tīri klienta pusē, un tur ir ļoti daudz JS'a, pasaki, ka lēni ielādē :)

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

pats BLOB, ja ir kompresēts, ir dekompresēts .pdf, kurš vēlreiz kompresēts

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

 faila saglabāšana datubāzē diezivai notiek ātrāk, nekā parasta faila izveidošana;

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 neliek publiskā direktorijā failu, var izmantot readfile(), lai padotu to klientam, kas jebkura gadijuma būs ātraks neka to izvilkt no datubāzes un padot klientam;

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. 

failu glabāšana datubāze var palielināt tās izmērus reizes 10, kas apgrūtinātu rezervju kopiju veidošanu, datubāzu kopēšanu, uzturēšanu.

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

kāds tur scaling, ieslēdzam kaut kādu cache plugin'u, kas ģenerē html'u un tas sūds strādā

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

Aha, CDN būs down, nevis tavs serveris, pa 5EUR no DigitalOcean. Sure.

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/