Příspěvky

4306

Sítě / Re:Cloud a DDOs utok

« kdy: 05. 03. 2015, 22:53:32 »

Jestli to má fkloudu nebo nefklaudu je celkem jedno, základní princip je stejnej. Jestli máš pocit, že si všichni nějak neuvědomili, že má cloud tuhle slabinu a tebe to napadlo teď při sprchování podpaždí, tak to seš spíš mimo

Jinak viz http://www.root.cz/clanky/ddos-utok-na-servery-internet-info-pohled-administratora/

4307

Software / Re:Wiki/knowledge base

« kdy: 05. 03. 2015, 21:39:21 »

Ale confluence (nakej zakladni) markup podporuje - https://confluence.atlassian.com/display/DOC/Confluence+Wiki+Markup - jediny co me sere, ze se to chova jina v Jire a jinak v Conf (v Conf to jakoze udela boxik po prvnim napsani tagu, aspon u code v jire v klidu pisu dal)

No prave - nejakej. Coz v principu znamena zadnej, pokud se na to neda spolehnout...

ad dokumentace generovana ze zdrojaku, k tomu ale prece slouzi jiny nastroje napr doxygen na jenkinsu nightly, imo ...

No jasne, ale pokud z nejakyho duvodu chces dostat dokumentaci ze zdrojaku do Confluence (nebo jakkoli jinak generaovat z cehokoli), tak celkem utres nos. Coz je na tak predrazenej produkt docela trapny...

4308

Vývoj / Re:Paralelizace a zrychlení v Pythonu

« kdy: 05. 03. 2015, 21:19:05 »

V tomhle dobrý, asi bych to měl vyzkoušet. Právě ty PARALELNÍ data v Pythonu, mi přišlo že se člověk musí věnovat víc implementaci paralelního modelu, než samotnýmu významu dat. Prostě si to v OpenMP, či pomocí socketů napsat sám.

Ono s tou paralelizací je to těžký - nemám moc rád v tomhle ohledu obecný tvrzení, protože víc zamlžují než odhalují. Primárně je paralelizace o tom, jak vypadá ten proces, že jo. Pokud máš operace, který na sebe z principu musí čekat, tak s tím nic nenaparalelizuješ. A naopak pokud máš triviální SIMD operace, tak to nějak půjde paralelizovat prakticky v jakýmkoli jazyce... A někde mezi tím je programátorská kultura - když máš brutálně propojenou haldu objektů, tak seš v pytli každopádně. Pokud máš oddělený datový struktury, je zas šance větší... Prostě no silver bullet, většinou je to stejně nakonec o kvalitě analytika

Ohledně distribuované verze, tam jenom vim že by to prej asi mělo jít, ale teď se věnuju něčemu jinýmu.

Jo, vím že existuje třeba http://www.ebi.ac.uk/Tools/rcloud/ a různý jiný balíčky, ale vyzkoušený to právě nemám a ani to zatím není úplná priorita...

Neni tajemství že je Python lepidlo C knihoven. Takže výsledná kombinace by měla bejt přijatelně rychlá, napsaná v přijatelným čase a oproti C přehlednější.

Jenže to právě nic neříká o kvalitě jazyka. To bys taky mohl mít jazyk, ve kterým by se OS Windows implementoval takhle:

Kód: [Vybrat]

new Windows();

...a zbytek by byl v C++

4309

Vývoj / Re:Paralelizace a zrychlení v Pythonu

« kdy: 05. 03. 2015, 21:03:14 »

Poprosil bych jeden kernel-driver

Nestraš prosímtě, nebo to fakt někdo udělá. Viz http://micropython.org/

4310

Vývoj / Re:Paralelizace a zrychlení v Pythonu

« kdy: 05. 03. 2015, 20:46:46 »

Nikam neposílám, jen Python umí všechno, co ostatní jazyky a ještě máš lepší flexibilitu. Nemusíš ji použít, ale počítá se s ní a funguje dobře. Je to jako Linux. Záleží na tobě, co si z toho postavíš.

Ehm. To bys n8m asi musel ozřejmit, jaké "ostatní jazyky" máš namysli.

Jenom namátkou, co python nemá: ze zásadních věcí: makra (a tímpádem ani rozumnou podporu DSL), pattern matching, paralelnost. Ze specialit: třeba snadno implementovatelnou obecnou lazy evaluaci (ne, to fakt není xrange) nebo jánevím třeba podporu pro http://en.wikipedia.org/wiki/Definite_clause_grammar

Python je určitě prima jazyk, rád ho používám. Ale jestli si myslíš, že má "všechno", tak to jsi toho v programování asi moc nezkusil

4311

Vývoj / Re:Paralelizace a zrychlení v Pythonu

« kdy: 05. 03. 2015, 20:41:25 »

V tom nejsme ve sporu. Jak je to trivilani filtrovani a takove to domaci interaktivni solichani dat, tak ma R svoje kouzlo (pokud clovek pretrpi to, ze co pes, to jina ves). Ale jak se po nem zacne chtit neco vic, tak je to dost tvrde pristani (prestoze tam teoreticky je spousta veci, prakticky uz jenom pitome unittestovani je bolest a utrpeni, o cemkoli serioznejsim nemluve).

Ale co, neco vic? To je proste jazyk pro interaktivni solichani dat, co bys po nem chtel? Uz to, ze pises o debuggeru a unit testech, dost ukazuje - takova prace, ktera vyzaduje unit testy, by se v R nejspis vubec delat nemela. Pro serverove davkove zpracovani jsou jine jazyky. Nemam nic proti tomu, kdyz takhle nekdo Rko pouzije, ale pak at si nestezuje, ze je Rko na prd...

Problem toho mnozstvi knihoven pak je dost nevyrovnana kvalita.

To je pravda. Ostatně jako u jakékoliv jiné obrovské kolekce knihoven zdarma

4312

Vývoj / Re:Paralelizace a zrychlení v Pythonu

« kdy: 05. 03. 2015, 20:34:18 »

Python je úplně normálně paralelní jako ostatní jazyky. Nevím, proč něco přepisovat.

Myslíš úplně stejně jako všechny ostatní OOP jazyky?

A vůbec ze všeho nejparalelnější je GIL

4313

Software / Re:Wiki/knowledge base

« kdy: 05. 03. 2015, 20:10:01 »

Re Confluence: Jediný problém s češtinou byl export do pdf který se spravil nahráním jiného fontu, což člověk nakliká za cca 30 vteřin.

Jak a kde přesně se to dá naklikat? Tohle bych docela dost potřeboval vyřešit.

Markup je podle mě věc zvyku.

Je to docela zásaní problém, pokud potřebuješ dokumentaci generovat např. ze zdrojáků.

4314

Vývoj / Re:Paralelizace a zrychlení v Pythonu

« kdy: 05. 03. 2015, 20:05:06 »

Jak moc uživalelsky pohodlná je paralelizace v R? Byly by to body, o který by R porazilo Pandas.

Vyzkoušení paralelizace mám na TODO listu, takže nepovím Nástroje na to jsou, ale jak pohodlné to ještě nevím.

Jo počkat, myslíš paralelizaci přes víc strojů nebo v rámci jednoho? Jestli myslíš v rámci jednoho, tak to je v pohodě - Rko je docela funkcionálně orientovaný, takže klasika parallel map atd. Samozřejmě balíčků je na to X (jako ostatně v Rku na všechno ). Ale v tom žádnej rozdíl oproti Pythonu nebude, tam to jde určitě taky (vyzkoušený nemám).

Cokoli vetsiho v R je peklo. Je to prima nastroj na "otevru CSV, profiltruju na NA, namaluju obrazek, prozenu ANOVOU", ale na nejake programovani R nefunguje moc dobre. Zoufaly nedostatek pouzitelnych nastroju (uz jenom debugger je problem a nasi researcheri to obchazeji pomoci View v RStudiu), blbe navrhnuty jazyk (pro statistika dobre, ale na vetsi projekty nema dobre vlastnosti) a spousta ruznych necekanych pasti.

Jémine, tyhle jazyky přece nejsou určený k tomu, abys v tom psal informační systém (i když i http server v Rku existuje ). Jsou to jazyky primárně na interaktivní práci s datama. Prostě vezmu dataset, dotlačím ho do správnýho formátu a vrazím do nějaké knihovny. Je to prostě lepidlo na knihovny, nic víc od toho nelze očekávat. Rozhodující pro tuhle práci je množství a kvalita knihoven a v tom je Rko dost slušný bych řekl.

Python je sice bezva, že to je univerzální jazyk, jenže jako lepidlo právě (imho) zas tak dobře nefunguje. Protože ho prostě ohýbáš na něco, na co nebyl určenej. A speciální nevýhoda je, že nemá rozumný makrojazyk. Takže předat parametr tak, aby se nevyhodnotil v době volání, je opruz. Viz krkolomná syntaxe selectu (narozdíl od Rka, kde samozřejmě selectem design jazyka začali - a téměř u něj skončili ).

4315

Vývoj / Re:analýza dat- python - zrychlení

« kdy: 05. 03. 2015, 01:31:23 »

Někdy je ale třeba data zpracovávat "element" po elementu, tak tam je numpy k ničemu. Cython tady naopak
udělá dobrou službu, včetně paralelizace alá openmp.

Ok, nehádám se. Numpy používám jenom na drobnosti, náročnější věci zkouším spíš v Rku. Myslel jsem spíš to, že pokud člověk dělá nějaké hodně profláknuté operace (což ta zmíněná hustota je), tak na to nejspíš pro numpy bude existovat způsob, jak to udělat efektivně a ne forloopovat v pythonu

Pokud dělá něco specifického, tak mu samozřejmě numpy nepomůže, pokud bude forloopovat, akorát přes dataframe

4316

Vývoj / Re:analýza dat- python - zrychlení

« kdy: 05. 03. 2015, 00:05:39 »

3) alternativni (ryhlejsi) interpretery pythonu - pypy, cython ... muze to udelat docela dost muziky za malo penez

Naprosto zbytecny. Ty zminovany matematicky baliky maji samozrejme potrebne casti udelane v C/C++.

4317

Vývoj / Re:analýza dat- python - zrychlení

« kdy: 04. 03. 2015, 23:01:33 »

co například začít už tím, že jeden a týž řádek nebudeš porcovat pětkrát?

Třeba spolíhal na to, že má Python líný vyhodnocování

4318

Vývoj / Re:analýza dat- python - zrychlení

« kdy: 04. 03. 2015, 22:51:21 »

Tak tohle rozhodně v žádném případě nedělej v čistém Pythonu. Podívej se na http://www.numpy.org/ http://pandas.pydata.org/ anebo rovnou http://www.scipy.org/

Ze začátku se asi budeš cítit jak Alenka v říši divů, ale to se poddá A s konkrétními dotazy určitě někdo rád pomůže.

4319

Vývoj / Re:analýza dat- python - zrychlení

« kdy: 04. 03. 2015, 22:28:40 »

Myslíte, že to urychlí zpracování dat. Jak byste to řešili Vy? Díky za tipy a nasměrování k paralelnímu zpracování.

Jak říkali kolegové, především si musíš změřit, kde vlastně trávíš nejvíc času. Pokud to chceš dělat na jednom stroji a nejvíc času trávíš čekáním na disk, tak ti logicky paralelizace nepomůže že jo

Takže jako první krok určitě změřit, kolik trvá načítání a kolik to vlastní zpracování (vůbec nepíšeš, jaký výpočet nad těmi daty probíhá).

Pokud bude zádrhel ve výpočtu, tak v první fázi rozhodně použít numpy, pandas a podobné balíky specializované na hromadné výpočty (pokud už je nepoužíváš), ve druhém kroku pak případně přepsání nějakých kritických částí do C.

Každopádně dej vědět, jak pokračuješ, zpracování dat je hodně zajímavá a žhavá parketa, určitě si o tom víc lidí rádo něco přečte.

4320

Studium a uplatnění / Re:Uživím se lépe jako síťař nebo sysadmin?

« kdy: 04. 03. 2015, 15:10:35 »

Súhlasím. Ale bez tak aj študenti rozmýšľajú mainstram-ovo. Zapíšu si C, C++, Javu, C# a majú to "vychytané". A na Haskell ide asi 5 (slovom päť ľudí).

Jak kde. U nás (FI) byl haskell myslím povinný. Ale narazili jsme pro změnu na ten bod 2 - nedostalo se mi srozumitelného vysvětlení, proč je haskell zajímavý. Přišel jsem na to až nějaký pátek po škole, kdy už bylo pozdě Možná to nebyla chyba učitele, možná jsem si pod lavicí četl faktury, už si na to nepamatuju.

Každopádně mám pocit, že byl haskell dost brzo, dal bych ho trošku později, až by člověku došlo, jakou to má vlastně vazbu na algebru apod. Třeba moc krásný zážitek byl, když mi při jakýmsi předmětu bylo sděleno, jak je vlastně Prolog založený na Hornových klausulích