Příspěvky

376

Vývoj / Re:Staré zdrojáky - hříchy mládí

« kdy: 22. 07. 2014, 10:04:30 »

Jednou jsem viděl mnohem větší pecku: v javascriptu na straně klienta se vytvořil celý SQL dotaz a ten se jen
poslal do skriptu na serveru, který ho tak jak přišel provedl

Hlavně si myslím, že nejhorší jsou právě lepiči kódu z internetu, prostě je to jen příklad a někdo na tom klidně slepí ostrou aplikaci (to je smutné)

Co se týče novodobých easy-vysokoškoláků tam u některých jsem si jist, že jejich IQ nepřesahuje 90 bodů. Jsem přesvědčen, že kdysi by stěží dali výuční list.

377

Server / Re:Virtualizace PostgreSQL

« kdy: 04. 07. 2014, 15:22:48 »

Proxmox (OpenVZ), výkonnostní rozdíl neměřitelný téměř za všech okolností...

Jinak full virtualizace různé - obvykle až 50% ztráty v IO něco málo v CPU.
Pokaždé se to chová jinak. Raději v ostrém provozu nepoužívám.

378

Odkladiště / Re:Blíží se Skynet?

« kdy: 04. 07. 2014, 15:17:29 »

S tím mozkem jsem to pochopil tak, že člověk nepoužívá najednou víc jak 10% z energetických důvodů.
Těžko říct, jestli to tak je, ale pokud ano spíš bych si to představil jako obrovskou knihovnu o deseti místnostech - svítíte jen v jedné.
Nicméně dostupná je celá po částech nikoliv jako celek.

Je to spíš takový odhad.

379

Server / Re:Zabezpečení web serveru

« kdy: 29. 06. 2014, 22:14:23 »

Já se přikláním k ostatním, neřešit nesmysly. Pár řádků v logu nemůže žádný normální server příliš přibrzdit (nezapisuje se to najednou, ale po blokách). Pokud je výkon problém, tak se logování obvykle vypne nebo silně omezí. Na internetu si neustále nějaký robot něco zkouší a to všechny možné nesmysly (nemá vůbec smysl řešit jednotlivosti, objeví se jiné a jiné).

380

Vývoj / Re:MySQL databáze nad 500 MB

« kdy: 13. 06. 2014, 21:07:39 »

To je ale implementace v PostgreSQL. Navíc i tam by v tomhle případě asi šlo bez problémů použít bytea. Tazatel ale píše o MySQL, kde jsou BLOBy normální datový typ.

Fajn, z rychlého přeletění dokumentace MySQL (5.5) to vypadá, že (long)blob je u mysql podobný typ jako bytea v psql. Potom tedy ano.

Mě MySQL nesmí do domu už nějakých pár let, takže tohle mi uniklo.

Ono se hodně změnilo v průběhu času a takovej Gallera Cluster není vůbec špatná věc.
http://galeracluster.com/products/
Je fakt, že vývoj byl vždycky spíš cílený na praktické věci, zatímco PostgreSQL se snaží jít cestou Oracle DB (obojí ma něco do sebe)

381

Odkladiště / Re:Nabídl vám někdo práci skrze LinkedIn?

« kdy: 09. 06. 2014, 15:11:38 »

LinkedIn má jednu velmi dobrou výhodu, síť uživatelů a jejich propojení. Lidi rádi znají alespoň někoho kdo zná někoho.
Příklad mám známého a jeho známý hledá člověka... jelikož vidí, že jste propojeni může se svého známého zeptat (je to debil, nebo to s ním půjde?). Navíc pokud je profil vyplněný může vidět projekty, s kým jste spolupracovali atd...
Je to lepší a důvěryhodnější, než shánět někoho naprosto naslepo. Je docela těžké tam lhát, protože ostatní to uvidí a znají vás.

Prostě ano - je to rozhodně výhodné.

382

Bazar / Re:Daruji zvukovku SoundBlaster Audigy

« kdy: 05. 06. 2014, 20:19:01 »

No a není to škoda? Já používám Audigy 2 ZS a to je vlastně Audio Processor (DSP jde programovat) ~3 milióny tranzistorů.
192KHz Stereo a 96Khz 7.1 s HW mícháním zvuku... S/N 108dB

Integrovaný zvukovky proti tomu působí jako trapnej vtip i akusticky. Chtěl jsem pořídit něco lepšího, ale za těch mnoho let nějak nic moc už není...

383

Server / Re:Databazy - programovanie/spravovanie

« kdy: 17. 05. 2014, 12:21:28 »

Překvapuje mě návrh, jednoznačný identifikátor z venku a syntetický uvnitř ze systému...

To jako když se mi sejdou tři auta se stejným VIN, mám je uložit do systému? Co to je za nesmysl?
Známe lidi, klidně tam ty nesmysly narvou. Pak VIN může klidně být primární klíč a naopak je to silně žádoucí.
Přenos nějakého nesmyslného identifikátoru napříč celým heterogenním systémem je prostě nesmysl.
V servisně orientované architektuře to ani není dobře realizovatelné.

Nedivím se, že pak ty IS stojí za starou bačkoru, pokud každý uvažuje takhle...
Nehledě na to, že běžný databáze už jsou fakt trošku zastaralé, je to ta nejprimitivnější část systému.
Neberu psychopaty, který chtějí pomálu v nich spouštět aplikaci (největší problém dneška - obvykle se to celé musí zahodit)

384

Server / Re:Je zobrazování chyb PHP nebezpečné?

« kdy: 15. 05. 2014, 18:15:17 »

Já bych obecně řekl, že výstup chyb jen tak ven, je volba srážící PHP k amatérské rovině.
Opět není to chyba jazyka, ale implementace,provozování a nastavení.
To se hodí jen na developerskej server, nikdy ne do produkčního prostředí, kde lze logovat do souboru.

Ovšem abych nebyl zlej, třeba jisté velké české firmy tímto způsobem odkrývali svojí vnitřní strukturu a to tam byla nasazené
"enterprise" technologie (java a oracle db). Člověk si tam klidně stopoval jednotlivé stroje v clusteru jako by nic.
Takže amatéři se najdou všude...

385

Vývoj / Re:webová aplikácia - výkon - Java vs hocičo

« kdy: 14. 05. 2014, 08:23:31 »

Zdravím.

Na serveri sa budú upravovať "dávkovo" dáta (rozumej neinteraktívne). Existuje nejaká výkonovo zmysluplná alternatíva k Jave/JIT, ktorá by ušetrila zmysluplno výkon? povedzme o 10 - 15%?
Napadol mi nejaký framework pre C/C++ (http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#C)
Samozrejme ide o schopnosti programátora a optimalizáciu. Aby bol server čo najlepšie využitý.

Ďakujem za rady.

Moc se to nevyplatí, železo obvykle bývá mnohem levnější než programátor.
Tudíž sice se píšou optimalizované věci, ale až od většího množství serverů (řádově desítky stovky tisíce - tam to má smysl).
Jinak v C zcela jistě jen drobné části (vývoj je opravdu dost náročný a háklivý na chyby).

Teď je otázka to co vlastně má být? Je to služba (soa/rest), nebo frontend?

386

Server / Re:Více domén pro Tomcat za Apachem

« kdy: 10. 05. 2014, 17:47:39 »

Proč je takový problém vytvořit virtuál pod Tomcatem, na kterém poběží aplikace normálně jak má, jen na portu 8081
a ten se přes proxy (přes tu virtuální doménu) načte do Apache. To je normální řešení...

Prostě http://neco.nekde.cz:8081/ bude normálně fungovat jak má a tu načte Apache, který běží na portu 80

Proč vymýšlet šílené nesmysly a nepřehledné konfigurace?
Aplikace obvykle port neřeší (i když může), cesta už může být v samotné logice aplikace (neměnil bych jí).

387

Server / Re:Více domén pro Tomcat za Apachem

« kdy: 10. 05. 2014, 17:40:58 »

Aplikace si občas načítá document root tudíž pokud má být v / tak by tam měla být i v Tomcatu a ne na adrese /MOJEAPP...
Tudíž musí odpovídat na portu 8081 přímo. http://host:8081/ by měl vrátit normálně běžící aplikaci.

<script src="/MOJEAPP/static/js.js"></script> tomu napovídá ne?

Jinak by ta proxy musela měnit i obsah přenášených dat (dá se to, ale je to šílenost).

---
Když tak na to koukám (bože děkuji ti za Nginx) to je fakt naprosto jinej level ten Apache a Tomcat je zhůvěřilost.

388

Server / Re:Více domén pro Tomcat za Apachem

« kdy: 10. 05. 2014, 10:12:29 »

Já to tedy téměř nepoužívám, ale logicky - název virtuálního hosta by neměl být
localhost, ale jméno domény (jak na straně Apache tak Tomcatu).

    ProxyPass / http://neco.nekde.cz:8081/

Jak by jinak ten Tomcat poznal, co má obsloužit za virtuál?

Zkusil jsem postupovat podle oficialniho tomcat7 navodu http://tomcat.apache.org/tomcat-7.0-doc/proxy-howto.html

V Apachi mam zapnuto mod_proxy. A takhle vypada muj virtuahlost:

Kód: [Vybrat]

<VirtualHost *:80>
    ServerName neco.nekde.cz
    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>    
    ProxyPass /mojeApp http://localhost:8081/mojeApp
    ProxyPassReverse /mojeApp http://localhost:8081/mojeApp
</VirtualHost>

do nastaveni tomcatu /etc/tomcat7/server.xml jsem pridal:

Kód: [Vybrat]

<Connector port="8081" protocol="HTTP/1.1" connectionTimeout="20000" URIEncoding="UTF-8"
              proxyName="neco.nekde.cz" proxyPort="80"/>

Kdyz nyni jdu na adresu http://neco.nekde.cz dostanu chybu 404, kterou vraci apache httpd, pokud zadam http://neco.nekde.cz/mojeApp, funguje to.
Ja ale chci mit aplikaci primo na http://neco.nekde.cz.

Pokud v definici virtualhostu uvedu:

Kód: [Vybrat]

    ProxyPass / http://localhost:8081/mojeApp
    ProxyPassReverse / http://localhost:8081/mojeApp

Pri pristupu na adresu http://neco.nekde.cz jsem automaticky presmerovan na http://neco.nekde.cz/mojeApp a dostanu chybu 404, kterou tentokrat vrati tomcat.

Kde delam porad chybu? :-(

389

Server / Re:mysql io i po reinstalaci

« kdy: 04. 05. 2014, 12:20:50 »

Ahoj a děkuji,

nastavení mysql toho vadného serveru VPS mám docela optimalizované pomocí mysql tunner scriptů (mysqltuner.pl, mysql-tunning-primer.sh)

Pozor, na tuning skripty pod kontainerama (systém má touhu reportovat velké množství RAM a prostředků, které má v ideálním případě k dispozici - což běžný provoz nemusí být) jak vypadá výpis /proc/bc u toho stroje???

390

Server / Re:mysql io i po reinstalaci

« kdy: 04. 05. 2014, 12:17:20 »

Je třeba zjistit následující:
Na všechny tabulky raději pustit "Check" a "Optimize".

Je nastavení bariér v OpenVZ stejné jako před instalací?
Pokud je to stejné, tak je možné, že se aplikace zbláznila a vytváří nesmyslné věci (extrémní spojení tabulek, temporary tabulky atd.)
Možná, že systém prostě už má málo RAM... u OpenVZ se všechny prostředky sdílejí (pokud jich je přebytek každý kontejner může překračovat svoje kvóty, pokud jich je málo přidělují se hardlimity)