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 - Petr Blahos

Stran: 1 ... 4 5 [6] 7
76
Server / Re:Jak zálohovat MySQL databázi?
« kdy: 19. 09. 2013, 08:05:07 »
Souhlasím s Dustinem. My sice máme jen pár GB v MyISAm, ale děláme to vpodstatě stejně. Replikujeme, a 2x denně uděláme na slavu flush, zamkneme databázi na readonly, zkopírujeme soubory, odemkneme, a další databázi.

Nějaká komerční firma dělala nástroj, který fungoval přibližně tak, že normálně za běhu zkopíroval innodb databázi, a potom ji opravil na nějaký poslední bod, kdy byla konsistentní data. Detaily neznám.

77
Software / Re:Generátor výrobků na základě součástek
« kdy: 11. 09. 2013, 08:07:47 »
Panove programatori, Vase prace je neustale bastleni, ktere se neobejde bez podpory 3., 4. 5..... srany.
Kdyby byl kazdy 1000. clovek na planete programator, znamenalo by to pres 7 000 000 lidi, kteri pristavuji dalsi a dalsi patra na necem, co ma zaklady na vode.
Nechápu, jak to souvisí s původním tématem. Pokud narážíte na to, že jste nedostal řešení, tak musím konstatovat, že jste nespecifikoval problém. Odpovědi, které jste dostal chápu jako oprávněně ironické až sarkastické. Počítačovým systémem nevyřešíte něco, co nedokážete vyřešit bez něj.

P.S.: Mě třeba dost vadí, že když řídím auto, tak musím pořád něco nastavovat. Směr, rychlost, nedávno mi dokonce úplně zastavilo a odmítalo jet dál, prej něco s fjúl. Pánové konstruktéři aut si tam neustále bastlí něco, co se neobejde bez podpory 3. strany: Servis, ropa, výrobci čistících prostředků, betonová lobby...no nic.

78
Software / Re:Generátor výrobků na základě součástek
« kdy: 09. 09. 2013, 14:13:30 »
Skoda, ze nejsem programator, ale pro zacatek by stacilo, kdyby generator pracoval na zaklade porovnavani kusovniku zadanych soucastek s kusovniky jiz vyrabenych veci.
No, zajímalo by mě, kde vezmete ty kusovníky, a jak přesnou vyžadujete shodu.

79
Vývoj / Re:Otázky o programovaní
« kdy: 08. 08. 2013, 20:11:58 »
Citace
Někdo psal, že není podstatné, jak se co naprogramuje? Podstatné to sice je, ale není to ten problém. Tvůj syn řešil problém a vyřešil problém a Ty v tom hledáš chybu? Dostal zadání, vyřešil ho správně, pak dostal jiné zadání, a vyřešil ho taky správně. Udělal to nejlepší, co šlo. Reagoval na poptávku. Vlastně se z hlediska týmové práce choval dokonale.
Ak za správne riešenie problému považuješ len jednoduchý výsledok, tak to je chyba. Často je cesta (hlavne na škole) dôležitejšia ako cieľ. Ak sa spýtam koľko je 500x1 a niekto si pod seba napíše 500 jednotiek a spočíta ich je to smutné... Neexistuje dostatočne jednoduchý problém nad ktorým sa netreba zamyslieť, ktorý sa nedá lepšie vyriešiť. Dosaď si za lepšie čo chceš (cena, rýchlosť, elegancia, opakovateľnosť, aplikovateľnosť).
Předně, kloubouk dolů, myslím si, že je perfektní, že se synem děláte tyhle věci, a pokud tohle řeší kdy, hmm, ke konci základky? Na střední? Tak pak asi nebude mít problém s předmětama jako jsou grafy a jazyky a překladače. Jenže takovou úlohou se můžeme zabývat třeba 10 let, a budeme vědět, jestli jsme dostali nejoptimálnější řešení? Možná už zítra, možná nikdy. Na otázku, jak to udělat nejlépe je vždy protiotázka: Co je to nejlépe?

No a proti tomu tu máme týmovou práci na úkolu, kdy máme něco jako plán, a když máme úlohu spočítat 500x1 a naše řešení, ač beznadějně neoptimální, bude v danou chvíli dostatečné, tak se prostě posuneme dál. A samozřejmě oba víme, že 500x1 je nadsázka.

V praxi je ale větší problém to, aby software byl pro uživatele dostatečně přirozený, a uživatel aby věděl, že dělá 500x1, nepřipadalo mu to krkolomné, při příštím použití to věděl znovu, a nezasahovalo to do jeho pracovního workflow. Čímž reaguju spíš na otázky ohledně přístupu k počítačům s větším množstvím procesorů.

A teď bych se měl vrátit k tomu že se budu častěji sám sebe ptát: Je tohle to nejlepší, co mohu v této chvíli dělat?

80
Vývoj / Re:Otázky o programovaní
« kdy: 08. 08. 2013, 19:57:44 »
Děkuju za usměrnění ohledně norem. To je samozřejmně blbost, která ze mě vypadla pod vlivem příspěvku původního autora, kterému vyčítám vpodstatě to, co potom někteří z vás mě. Norma je např. ASCII nebo UNICODE. Děkuju taky za podporu těm, kteří pochopili, jak jsem to myslel. Mimochodem, ISO 27000 není IT norma. Automotive bych v této souvislosti taky nezmiňoval. Původní autor psal často o coding stylu, revision control a práci v týmu, a moje poznámka se měla týkat hlavně toho. Nepochybuju o tom, že ISO nebo EU na to nějakou tu aspoň malou (200-500 stran) normičku vydalo. Fakt je, že coding style, revision control a metodiku týmové práce si každá firma naštěstí dělá po svém. Taky si uvědomuju, že jsem vlastně viník toho, že celý tento thread šel do h**zlu. Go me!

Teď jsem se díval na studijní plán FIT CVUT, a hle obor Softwarové inženýrství s týmovými projekty. Pokud chcete mít kecy, že to tam učí blbě, tak prosím, to nedovedu posoudit, ale upřímě, vysokou školu už si studujete sami, a je na vás, jak se k tomu postavíte. Za nás byly různé předměty s různou formou spolupráce, a mohli jsme to vzít pohodově nebo vážně.

Citace
Heh? Pokud je to týmová práce, tak snad jen jeden musí rozumět řešeni. Jeden dělá grafiku, jeden docs, 1 programuje podle zadání, jeden to vede.
Koukám, že to máš pěkně a jednoznačně nalajnované. Myslíš že to nejde jinak? Já bych řekl, že existuje spousta možností, jak týmovou "semestrálku" pojmout tak, aby dala studentům, kteří mají otevřené oči a i mysl, hodně do jejich profesního života. To co píšeš opravdu nepatří mezi takové přístupy.
To je schéma, které popisoval původní tazatel.
Nerozumiem tomu. Ak ide naozaj o to pripraviť ľudí pre prax, trval by som na tímových projektoch, kde sa jeden študent môže prejaviť ako grafik, iný ako schopný analytik, tretí ako výkonný kóder, štvrtý dorobí dokumentáciu..... Tak ako v živote, každý má silnejšie a slabšie stránky a podstatné je to dať dokopy.


81
Vývoj / Re:Otázky o programovaní
« kdy: 08. 08. 2013, 08:01:42 »
Podľa doterajších reakcií by som to zhrnul asi tak že:
- Výuka programovania ako priprava na prax v CZ/SK prakticky neexistuje (dodržiavanie noriem, kooperatívny vývoj...). Je to veľmi smutné tvrdenie.
Mám dojem, že máš odpověď bez oholedu na to, co Ti kdo napíše. Jaké normy? V IT normy zatím nejsou. V programování už vůbec. Jaká praxe? Praxe programátora? Nemůžeš čekat, že ze školy vyleze hned hlavní programátor (to je název pozice).

Citace
- Argumenty, že týmové projekty sú nezmysel, lebo jeden robí a ostatní sa vezú sú chybné. Podľa mňa je len otázkou, ako bude pedagóg sledovať, účasť jednotlivých členov týmu a pri prezentácii si veľmi rýchlo zistí, či všetci členovia tímu rozumejú riešeniu. Vaše reakcie, myslím si, len odzrkadlujú Vaše skúsenosti zo školy i praxe.
Heh? Pokud je to týmová práce, tak snad jen jeden musí rozumět řešeni. Jeden dělá grafiku, jeden docs, 1 programuje podle zadání, jeden to vede.
Citace
- To že nie je podstatné ako sa čo naprogramuje, hlavne ked to robí čo má, sa mi tiež nepozdáva. Nedávno som so synom riešil klasický problém ôsmich dám na šachovnici. Samozrejme, že jeho softwarové riešenie bolo postavené na brutalforce. Keď som sa ho spýtal na šachovnicu 1000x1000, alebo iné figúry, mal problém. Za týždeň prišiel s riešením, ktoré počítalo šachovnicu 1000x1000 za pár sekúnd. Ďaľší krok sú strelce i veže.  Ide o analýzu. Ak niekto tvrdí že pri bežnej business aplikácii nie je už čo vymyslieť, že je to o pár formulároch a databáze, je to omyl. Presne týmto sa dobré produkty odlišujú od zlých. Majú v sebe nápad. Pred 10 rokmi mnohí vraveli, že Photoshop vie už všetko.....
Někdo psal, že není podstatné, jak se co naprogramuje? Podstatné to sice je, ale není to ten problém. Tvůj syn řešil problém a vyřešil problém a Ty v tom hledáš chybu? Dostal zadání, vyřešil ho správně, pak dostal jiné zadání, a vyřešil ho taky správně. Udělal to nejlepší, co šlo. Reagoval na poptávku. Vlastně se z hlediska týmové práce choval dokonale.

82
Vývoj / Re:Otázky o programovaní
« kdy: 07. 08. 2013, 21:17:01 »
Keďže považujem programovanie za veľmi tvorivú činnosť, prekvapuje ma, že nič o tomto aspekte nepočujem. Analýze problémov sa venuje minimálne množstvo času. Predpokladal by som, že sa začne vývojovými diagramami, ukážkami ako previesť problém zo života do matematicko-logickej postupnosti. Že sa poukáže na to, ako dokáže dobrá analýza X-násobne urýchliť výpočet, ako ani najrýchlejší počítač nedokáže vyriešiť koncovku šachovej partie, ktorá je aj pre priemerného šachistu evidentná, ak nemá k dispozícii tabuľky koncových pozícií.
Problém je trochu jinde. Ne převést problém ze života do matematicko-logickej postupnosti, ale do takové posloupnosti úkonů čí akcí, která bude nadále dávat podobný smysl a splní ten účel, který se očekává. Jinak, většina úloh je banálních. (Dobře, chce to navrhnout databázi aspoň trochu správně, a všeobecně, nebýt idiot, ale málokdy jsem se setkal s tím, že vymyslet, jak něco naprogramovat, by byl problém. Problém je, jak to správně navrhnout z hlediska firemního (nebo lidského) workflow.)
Začína sa inštaláciou voľajakého megamonštra (dosaďte si IDE podľa ľubovôle) a po obligátnom "hello world" nasledujú nijako nesúvisiace ukážky kódu v tom-ktorom jazyku. Triedenia, výpisy, súborový systém..... všetko bez toho PREČO?
A potom dostane študent voľajakú úlohu, ktorá bola už 1k krát na internete či inde riešená (s malou obmenou, v inom jazyku), veď nech si minuloročný druháci zarobia na pivečko.
Pokud studenti nebudou umět tyhle základy (a oni je zatím neumí), tak nemá smysl zabývat se nějakým smysluplným projektem. Známému jsem pomáhal s nějakými OS na FIT, myslím, že ve druhém semestru. Byla to podle mého názoru né úplně jednoduchá úloha typu producent - konzument. No a prostě když to neumí, tak si to musí natrénovat. Ani v prváku na FEL CVUT jsem před těmi 20 lety neměl v programování semestrálku, která by se dala někde najít (ikdyž s obměnami). A nebyla úplně nezanedbatelná. Nadruhou stranu, nevidím nic špatného na opakování podobných úloh.
Nerozumiem tomu. Ak ide naozaj o to pripraviť ľudí pre prax, trval by som na tímových projektoch, kde sa jeden študent môže prejaviť ako grafik, iný ako schopný analytik, tretí ako výkonný kóder, štvrtý dorobí dokumentáciu..... Tak ako v živote, každý má silnejšie a slabšie stránky a podstatné je to dať dokopy.
To bys ale musel dát dohromady lidi z víc škol nebo aspoň víc oborů. U nás byly týmové projekty v:
Softwarové inženýrství I a II, Mikropočítače, Počítačová grafika nevím kolik, asi jich bylo víc, ale teď si nevzpomenu.
Ak ste dočítali až sem gratulujem. Tu sú moje otázky:
- Možete mi napísať akou genézou programovania ste prešli?
Hodně ve zkratce. Atari Basic, Assembler 6502, Turbo Pascal, (Turbo/Borland) C, C++, trošku toho assembleru 8086 a 8051 (velice trošku), pak GCC+Emacs+CVS, pak první zaměstnání C++, Win32, Visual Studio 6, Visual Source Safe (bad joke), pak druhé zaměstnání a znovu Emacs a YCP/Yast + CVS + autobuild (+autotest) systém distribuovaný v několika zemích, myslím, že tady někte byl taky přechod na vim, pak třetí zaměstnání, VIM, java (+ servlets + jsp), perforce ale práce v týmu velikosti 1, pak čtvrté zaměstnání (zase sám v týmu), Visual Studio 6, C++, SVN, javascript na serveru (asp zase bad joke), Python+wxPython na klientské aplikace, Python Pylons a později Pyramid na weby.
- V ktorej etape je podľa vás podstatný výber jazyka?
Nikdy
- V ktorej etape je podľa vás podstatné zapojenie a využívanie kooperácie a CVS?
Včera. Version control se hodí i pro nevývojáře, vpodstatě komukoliv, ale nikdo jiný než vývojáři to nebude schopen používat.  Dá se to pochopit rychle, ale je zapotřebí mít toho šéfa.
- V ktorej etape je podľa vás podstatný výber IDE?
Není důležité. Člověk vůbec musí prvně přijít na to, jestli IDE ano nebo ne, a jestli ano, tak je pak skoro jedno jaké, a jestli ne tak je to taky jedno.
- Zažili ste / trvali vyučujúci na voľajakej "štábnej kultúre" kódu? Na komentovaní, na dodržiavaní konvencií pri pomenovávaní?
Ano, ale vlastně jen v té grafice (Žára).
- Viete si predstaviť / zažili ste na školách využívanie niečoho ako codenvy, čo by viacej tlačilo na tímovosť, nevyžadovalo silný hardware na strojoch študentov (furt čítam že pre programovanie treba SSD s 8+ GB RAM)? Používajú školy niečo takéto?
Nedovedu si představit projekt, na který bych potřeboval výpočetně silný stroj. Pokud budu dělat úlohu z paralelních systémů, budu mít nástroje, jak to testovat na svém slabém notebooku, a občas vyzkoušet na skutečném železe. Ale cloud IDE? WTF?!?
- Majú študenti prístup ku voľajakým výpočtovým farmám (povedzme 128 jadrová pračka v pivnici) na ktorých si môžu spúšťať svoje projekty a testovať "multiprocesorovosť"?
My jsme měli, sice ve formě emulátoru, ale fungovalo to dostatečně. Upřímě, kolik studentů to využije? 1 ze 100? Věřím, že ten se k tomu dostane. My jsme se hlavně naučili, že tyhle věci jsou o něčem jiném.
- Viete si predstaviť / zažili ste na školách prácu hoci aj v konzole (ssh na školský server, vim alebo niečo iné, git)?
Haha, vim na sériovém terminálu k Unixu? No nic, tenkrát se ještě používal telnet.
- Viete si predstaviť / zažili ste na školách niečo ako, že na jednom predmete sa niečo postaví (hardware), na druhom sa to naprogramuje, na treťom sa spraví dokumentácia/manuál/propagačný materiál/web/marketing/prezentácia?
Nedovedu. Bylo by trochu blbý v předmětu B trpět za chyby, které udělal někdo jiný v předmětu A.
- Viete si predstaviť / zažili ste na školách orientáciu na tímovú prácu? Výuku toho ako bude človek neskôr v praxi pracovať?
Problém bude sehnat vedoucího týmu. Když se zamyslím nad tím, jak to bylo za nás, tak pár lidí bych do týmu sehnal, ale vedoucího blbě. Malý týmový projekty byly. Občas bylo i něco v tom smyslu, že se udělalo něco, co se pak použilo na něco dalšího (jako knihovna nebo tak).

83
Software / Re:Vyhledání bodů v DB podle vzdálenosti
« kdy: 01. 08. 2013, 07:40:22 »
Nedá se o těch datech a dotazovaných vzdálenostech nedá říct nic bližšího? Šlo by to rozdělit na kvadranty "vhodně zvolené velikosti", pak jít po kvadrantech, a spočítat si, ve kterých kvadrantech má smysl pro hledanou vzdálenost hledat body, a v nich pak hledat a porovnávat konkrétní body.

Nebo jestli to není overkill, tak použít http://en.wikipedia.org/wiki/Quadtree. Což by odpovídalo na otázku "jak vhodně zvolit velikost kvadrantu".

84
A pak jsou taky notebooky, myslím, že to bylo HP, které mají v sobě od výrobce linux (nějaký sles), a v biosu je zařízeno, že se na ně windows nainstalovat nedají. Tam je pak potřeba provést ještě nějaký neoficiální "upgrade" biosu spojený se ztrátou záruky.

85
Vývoj / Re:Bash a spouštění příkazů
« kdy: 02. 07. 2013, 09:27:17 »
od -t x1 akt.sh

dos2unix akt.sh


86
Vývoj / Re:Python a msvcrt
« kdy: 06. 06. 2013, 09:21:56 »
Jestli se nepletu, tak ctypes.cdll.msvcrt už je ta nahraná knihovna, a normálně má třeba ctypes.cdll.msvcrt.strcmp. Takže zavolám
Kód: [Vybrat]
import ctypes
ctypes.cdll.msvcrt.strcmp("AAA", "aaa")
a dostanu -1. Pokud jste v pythonu docela nový, tak bych určitě nedoporučoval začínat něčím docela pokročilým jako je ctypes. Pokud potřebujete něco specifického pro windows, tak doporučuji nainstalovat pywin32. Je ale dost možné, že to co chcete, lze udělat v čistém Pythonu, nebo pomocí nějaké už existující knihovny, lépe.

87
Stroj zapisuje do evidence kdy co delal? Snizovat normu sem vzivote nikde nevidel, zvysovat nekolikrat. A v 99% pripadu se norma stanovuje tak, ze se veme nejaky obdobi (trebas 3 mesice) spocita se, kolik se toho ceho vyrobilo a to se stanovi jako norma.
Docela by mě zajímalo, jak uděláte nabídku zákazníkovi, když nevíte dopředu, kolik ta výroba bude stát. A to se nesnažím rejpat, fakt mě to zajímá.

Jenze porad sme u toho, ze to sou delnici u pasu, pokud nekdo trebas neco programuje, jak mu asi tak chces stanovit normu? V poctu radku? OK budu psat
Já jsem si to znovu pročetl, a nevšiml jsem si, že by kdokoliv chtěl počítat efektivitu práce programátorů. Hmm. Hezky se to dá shrnout takhle:

A: Chceme počítat produktivitu práce.
B: TO NEJDE!!!
C: Dělá se to takto: ...
B: UŽ JSEM PSAL, ŽE TO NEJDE. MELETE VŠICHNI NESMYSLY, PRO PROGRAMÁTORY TO NEJDE. NEJDE! NEJDE!!!

88
Software / Re:Evidence odpracovaných hodin
« kdy: 18. 04. 2013, 09:12:02 »
Tech 300ks muzes ovsem merit tak nejakymu delnasovi u pasu, a tam nastava zas jinej problem - treba by slo udelat 350, ale proc by to delal, ... nejakyho managora by pak napadlo zvednout normu a on by za stejny prachy musel delat vic.

U dost věcí se dá docela exaktně spočítat, jak dlouho mají trvat. Např. když to dělá stroj, a člověk je tam jako obsluha. Ale ikdyž je to čistě manuální práce, tak se to počítá. Takže máme normu 300ks, stihne se jen 250, protože stroj se na 2 hodiny pokazil, takže na výrobu 300ks bylo potřeba 10 hodin místo osmi, takže produktivita je 0.8. Neberte mě za slovo, ale v principu je to tak.

Jo, a když se pak zjistí, že ten, jak říkáte dělňas, stihne vpohodě víc, tak se norma zvýší, protože byla nastavená špatně. Ale když nestíhá, tak se zase norma sníží.

89
Produktivita v ekonomii je vztah mezi výsledkem a časem potřebným k dosáhnutí tohoto výsledku.
To bys ale musel nějak měřit obtížnost úkolu.

Nemyslí se tím nutně nejkratší možný čas potřebný na splnění, ale čas spotřebovaný ke splnění úkolu. Dost lidí v tomto threadu píše o tom, jak to k ničemu není, jenže vy si sedíte v těch svých kancelářích, a děláte si ty svoje strašně složitý věci, u kterých nikdo nedokáže poznat, jestli děláte, nebo ne. Když vezmete běžnější případ, jako že norma je 300ks za pracovní dobu, tak musíte sledovat, jestli pracovník udělá 300ks nebo třeba jenom 280, a z toho pak vypočítáte produktivitu, a následně prémie. Ovšem to
je ve firmách, kde se dělá něco hmatatelného. My takový systém máme, in-house developed, ale je propojen s dalšími systémy (docházkový, kde lidé pomocí čipových karet evidují přítomnost, a ERP, kde je napsáno, že se má udělat těch 300ks za směnu).

Předpokládám, že původní tazatel nemá nic. Takže bez nějaké automatizace je to opravdu strašná buzerace.

90
Vývoj / Re:Pár otázek ohledně unixu a programování
« kdy: 30. 01. 2013, 12:55:29 »
Považujete se někdo za dobrého programátora i administrátora nějakého unixového systému? Říkám si, jestli se dá zvládnout obojí, tzn. umět programovat např. složité síťové aplikace jako servery atd.. a zároveň se vyznat dostatečně v unixu, abych to dokázal někde rozběhat, server zabezpečit atd..

Byla ta otázka dobrého programátora a administrátora, nebo dobrého programátora a dobrého administrátora? A nějakého unixového systému, nebo unixových systémů?

Servery nemusí být složité síťové aplikace. Servery mohou být jednoduché síťové aplikace, a je to tak lepší.

To, že si umím nakonfigurovat, zabezpečit a spustit svou/nějakou aplikaci ze mě nedělá dobrého administrátora. Já bych za dobrého administrátora považoval někoho, kdo umí s co nejmenším úsilím spravovat např. firemní síť.

Záleží, kam si dáme laťku, ale já si myslím, že programátor nemůže být dobrý admin a naopak, protože na to druhé nemá čas. Ale pokud jde o to spravovat si jednu mašinu, na které běží i můj program, tak to už se zvládnout dá.

Stran: 1 ... 4 5 [6] 7