reklama

Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - cjohn

Stran: [1] 2
1
/dev/null / Re:Ignore LinkedIn
« kdy: 15. 08. 2019, 21:13:06 »
Xing.com pre nemecky hovoriace krajiny.
Inak takmer vsetky LinkedIn emaily/push notifikacie sa daju vypnut. Ja ich mam vypnutá a vsetky nutne veci (v zasade iba connect requesty a spravy), riesim asychronne. T.j. az ked si ich vsimnem.

2
ELK. Pomaly, spatne skalovatelny, lucene domain specific language, priplatek za hloupy aclka a integraci s ldapem.  Upgrade vsech komponent to je tak na 3 dny prace pokud vse funguje.

Maji nasazeno nektere aplikacni tymy na java appky  ale hledat neco v tom prakticky je za trest.
Nechapu na co se ucit dalsi dotazovaci jazyk.

A napriek tomu je to de fakto standard na logy. V cloude si ELK das na par klikov ako SaaS a tiez na par klikov naskalujes podla potreby (nerozumiem pojmu spatne skalovatelny).

3
Vývoj / Re:Fakturace do zahranici (USA) jako OSVC
« kdy: 02. 08. 2019, 20:22:30 »
ad 4

Na prevodu do CZE používám většinou Akcentu a občas RoklenFX. Příjde mi lepší se držet od bank dál, když vidím jejich ceník za převod z EUR do CZK :).

Ja zase na prevody pouzivam transferwise.com - pokial nepotrebujem danu menu, tak menim hlavne podla pohybov kurzov. Na tom sa da tiez stratit/ziskat, takze preto aj prepocet rocnym kurzom moze, ale nemusi byt vyhodny. Osobne pouzivam freeagent.com (neposobim na CZ trhu, ale global verzia by snad isla napasovat na CZ), ktory zmeny kurzov realne denne prepocitava a ma na to uctovnu polozku "Realized Currency Exchange Gain/Loss".


4
Teoreticky cgroups: vytvoris osobitny cgroup pre svoju ulohu a nastavis na nu rozne obmedzenia zdrojov (cpu/mem/blkio). Stale je to vsak iba o limitovani zdrojov. Z tvojho popisu je vsak jasne, ze ty chces scheduler. Pokial nepojdes na uroven kernel scheduleru, tak mozes napr. pouzit Kubernetes kde si napises vlastny scheduler, ktory bude managovat tvoj task podla tvojej logiky.

5
Sítě / Re:Monitoring a vizualizace síťových prvků
« kdy: 10. 07. 2019, 14:05:06 »
Specialne iba na network sa pouziva network-weathermap ...
Jistě, ale požadavkem jsou krásné grafy ... .
To znie ako manazerska poziadavka. Tak to nakod v exceli, kedze manazeri lubia grafy v exceli. Priklad implementacie cez Google Sheets, ktore sa pripaja cez Zabbix API a kresli "krasne excelovske" grafy - https://github.com/monitoringartist/monitoring-for-managers:

6
Sítě / Re:Monitoring a vizualizace síťových prvků
« kdy: 10. 07. 2019, 07:33:06 »
Specialne iba na network sa pouziva network-weathermap: https://www.network-weathermap.com/


Vseobecnejsie riesenie by bol monitoring, ktory dokaze poskytnut data Grafane (napr. Zabbix). V Grafane si uz vytvoris svoje vizualizacie s pomocou vhodnych pluginov (napr. https://github.com/GlobalNOC/globalnoc-networkmap-panel):

7
Vývoj / Re:OpenID Connect (oauth2) & angular/django
« kdy: 19. 06. 2019, 23:43:05 »
Standardnejsie riesenie je pouzit na SPA frontende (Angular) implicit OIDC flow, ktory ti vygeneruje token, ktory pouzijes pri komunikacii s backendom (Django). Backend uz len verifikuje token, ale neriesi jeho vydavanie/obnovovanie. Authorization code flow na backende, ktory posiela token do SPA frontendu mi pride divny. Poriesil si aj refresh tokeny?

8
Vývoj / Re:PHP autentifikačný framework
« kdy: 17. 06. 2019, 09:40:38 »

9
Server / Re:Pokažená znaková sada na webu
« kdy: 20. 03. 2019, 08:36:09 »
Ta stranka je v 1250, takze potrebujes dat do html:

Kód: [Vybrat]
<meta http-equiv="Content-Type" content="text/html;charset=windows-1250"/>
To prinuti prehliadac pouzit 1250, namiesto utf-8, ktora je deklarovana webserverom v response header:

Kód: [Vybrat]
Content-Type: text/html; charset=UTF-8
Najlepsie by bolo vsak urobit uz stranku priamo v utf-8.

10
Server / Re:Vizualizácia na viacerých VPS
« kdy: 14. 03. 2019, 00:50:11 »
Mhm, LXD (LXC) execution drivers nie su prave najpopularnejsie v uvedenych nastrojoch. Pozrel by som sa vsak po OpenStack alebo iba po jednoduchsom LXD v cluster mode.

11
Server / Re:Vizualizácia na viacerých VPS
« kdy: 13. 03. 2019, 12:02:13 »
kontajnery pohodlne presúvať z jednej VPS na inú
Presun kontajnera (presun RAM, volumes, fs, ...) nie je trivialna uloha. Isto chce presuvat kontajnery alebo iba vytvorit dalsiu instanciu kontajnera s pomocou nejakeho kontajner orchestration nastroja?

Docker orchestration nastroje na vyber:
  • Kubernetes - najpopularnejsi
  • Docker Swarm
  • Nomad
  • Rancher
  • Mesos (+Marathon)
  • Cloud Foundry
  • ...

Klucove slova do googla  "docker orchestration", pripadne nieco podobne pokial nepouzivas Docker kontajnery.

12
Pre niektorych ludi je Let's Encrypt (LE) "CA pre chudobnych" a je pre nich vecou prestize nepouzit LE, ale zaplatit si za EV (OV) certifikat.  Aj mne by prislo divne, keby https://www.apple.com/ nemal EV certifikat, ale iba LE cert. Pri malych projektoch, malych znackach mi vsak pride normalne, ked sa pouzije LE. Nevidim, zeby Seznam pouzival niekde EV certifikaty, tak nevidim problem s pouzitim LE.

13
Server / Re:Jak zjistit prez ssh zatez HDD
« kdy: 27. 02. 2019, 15:05:31 »
Začal bych u
Kód: [Vybrat]
man iostat.

iostat je zaklad. A este iotop, blktrace a pod. ... vid http://www.brendangregg.com/Perf/linux_perf_tools_full.png

14
Vývoj / Re:Zajímavá aplikace pro AWS Lambda
« kdy: 16. 02. 2019, 10:09:02 »
Pekne akademicke zhrnutie serverless-u (Lambda je tiez serverless): https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf

15
Vývoj / Re:Zajímavá aplikace pro AWS Lambda
« kdy: 12. 02. 2019, 11:33:58 »
A když tam návštěvnost je, tak máš nějaké cenové srovnání v porovnání s běžným hostingem?
Nemám a ani mě nenapadá, jak by se to dalo rozumně porovnat. Musel bys mít aplikaci s úplně stejnou funkcionalitou, napsanou nějak srovnatelným způsobem (??) a musel bys ji provozovat na mašině přesně odpovídající trafficu, popř. ji mít napsanou jako flexibilně škálující.

Čili bys v podstatě jenom implementací tohodle srovnání strávil půlku mládí a výsledek by nebyl aplikovatelný na jakoukoli jinou aplikaci, čili by byl v podstatě k ničemu ;)
Neměl jsem na mysli nějaké akademické srovnání, ale jen přibližné. Třeba když by firma měla několik webů v PHP, které by se přes API napojovaly na hlavní backend, který by byl třeba v Pythonu nebo Javě a na nějaké VPSce. No a ten backend by se firma rozhodla kvůli škálovatelnosti převést z VPS (nebo vlastních serverů) na Lambdu. Funkcionalita, návštěvnost i traffic by byl pořád zhruba stejný, takže srovnání měsíčních nákladů před a po by se dalo hezky porovnat. Zajímalo by mě to od někoho z první ruky kdo se na vývoji podílel a mohl by případně říct i výhody/nevýhody takového přesunu.

To sa neda porovnat tak jednoducho ako uz bolo spomenute. Zalezi na konkretnom pripade. Pokial mas par requestov do mesiaca, tak bude lacnejsia lambda. Ked vsak requestov bude tak vela, ze cena za lambda execution time bude vacsia ako cena za VPS tak uz bude ekonomicky vyhodnejsia VPS (pozor, vacsinou este s lambdou platis za traffic, API GW, ...). Nemusis vsak pozerat iba na ekonomiku. Napr. operations nepotrebujes v takej miere (ziadne OS/siet deployment) + mas priestor (cloud), kde sa inovuje super rychlo a zdroje su dostupne na par klikov za par sekund.

Moj priklad: potreboval som reverse proxy s basic auth. Typicky admin nahodi/nakonfiguruje nginx, hispterskejsi to urobi este v kontajneri. EC2 t3.nano to zvladne ($0.0052/hod). Viem, vsak ze par ms latencie pre pouzivatela v mojom pripade nie su kriticke a nebudem mat vela requestov, tak to mam cez API GW (pripadny throttling)+lambda 1 (auth)/lambda 2 (proxy) - kalkulovane prevadzkove naklady na toto riesenie su okolo $1/mesiac a to sa samo skaluje a uz to nemusim chytat v buducnosti. Len cista t3.nano by mala naklady $3+ bez skalovatelnosti + OS by potreboval pravidelnu starostlivost. Pokial by som uz mal 5 nasobne viac requestov, tak to nebudem implementovat v Lambde.

Stran: [1] 2

reklama