Online 323 uživatelů Přihlášení | Registrace | Zaslat heslo | Prohlížení bez přihlášení

 

Lama lamě, lamy sobě: HTML, CSS, XHTML, PHP, SQL, JS a všechno kolem NETU [ ID: 22883 ] - [ Počítače (hardware, software) / Co se jinam nevešlo ]
1 / 42
Mini Home

co zrovna programujete?


řešení banálních problémů při programování pro internet, které obtěžují zkušené programátory v jiných klubech


klub je určen především začínajícím programátorům a uživatelům, kteří  programují ze záliby nebo nějaké potřeby aniž by měli ambice stát se programátorem




kód prosím vkládejte do tagu pre,  ať  je čitelnější

DZODZO   08:49:06 02.10.2020
tuto prikladam jeden navod JAK NE :10)

IMG:https://i.nyx.cz/files/00/00/21/99/2199809_7348a8e1411febe65852.jpg?name=EjGM49zXcAErKmA.jpeg
LEIWULONG   21:24:49 17.08.2020
DAN1 [ 18:48:04 17.08.2020 ]: Ani já nejsem v OOP profík, data jako objekty jsme začili v práci pomalu používat teprve nedávno, dřiv to taky bvylo pole :D A z toho, jak to chápu já, tak by samostatný třídy měli být spíš na opakující se data. Takže class player určitě, ale v class team pak nemusíš mít 11 proměných typu player, ale můžeš je tam mít klidně jako pole těch tříd. Záleží, jak k tomu chceš / potřebuješ přistupovat. Zrovna v tomhe konkrétním případě, kdy jich máš vždycky 11, dává asi větší smysl 11 proměnných...
DAN1   18:48:04 17.08.2020
LEIWULONG [ 17:29:15 17.08.2020 ]: Takže ideální přepsat vše na objekt?

A měl bych to udělat tak, že si vytvořím class pro každou složitější položku? Tzn. že pokud mám pole o 11 hráčích, tak si vytvořím class player pro jednoho hráče a v rámci class team pak budu mít 11 vlastností (proměnných) typu player?

Přiznám se, že OOP není moje nejsilnější stránka, tak snad se neptám úplně stupidně.
LEIWULONG   17:29:15 17.08.2020
DAN1 [ 19:15:43 16.08.2020 ]: Minimálně to bude mít tu výhodu, že ti to pak bude IDEčko napovídat, nebo označovat, co máš špatně. Ať už z hlediska překlepů nebo datových typů.
DAN1   19:15:43 16.08.2020
Možná to bude blbý dotaz, ale řeším datovou strukturu. Momentálně si data v rámci třídy ukládam do pole, ale zajímalo by mě, jestli má cenu to přepsat na objekty? Bude to pak mít nějakou konkrétní výhodu pro mě?

"Hotová" implementace Soccer-Decoder je tady https://gitlab.com/vonTrips/soccer-decoder-php
DAN1   15:38:25 05.08.2020
Netuším, jestli to někoho zajímá, ale předchozí problém jsem vyřešil pomocí jednoduché utility https://gist.github.com/irazasyed/f41f8688a2b3b8f7b6df jen si pro ni musím předpřipravit vstupní data (nepatrné zvýšení paměťových nároků - 2x3 pole), ale po otestování mohu říct, že funkce funguje správně.

Momentálně jsem tak dokončil celou základní implementaci soccer-decoder, kdyby někdo měl zájem zkouknout, třída Match zde: https://codeshare.io/5ojeLX

Pokud mi k tomu někdo poskytne zpětnou vazbu, nebudu se bránit. Samozřejmě vím, že to asi není nejčistější kód, zvláště ty zanořené pole, ale fakt nevím jak jinak to udělat. Jestli to chce někdo otestovat, stačí se podívat do předchozího kódu co jsem tu sdílel, tam jsou i formáty těch vstupních dat pro simulaci.

V tuto chvíli asi budu řešit, JAK DÁL? Zůstat u implementace pomocí PHP? Řešit si vše úplně samostatně nebo přejít na framework? Tady bych asi zvolil Nette, nebo něco jiného?

A pár poznámek k hotovému kódu:
- simuluje zápasy dvou týmů v závislosti na jejich skillech, z nichž počítá aktuální ratingy
- skilly i ratingy se upravují v závislosti na stáří hráče, jeho fyzičce a zkušenostech (mladý hráč bez zkušeností se zpravidla unaví rychleji, než ten starší, protože ten tam neběhá jako splašený zajíc)
- ratingy (které se porovnávají) se snižují po každé rozehře (bitvě)
- ideální počet bitev je momentálně 100 (možná bude nutné zvednout časem)
- každý rating projde Erlangovou distribucí => i nižší rating může vést k vítězství v bitvě
- dochází k více zakončením, než kolik nakonec padne branek (u dřívějšího tomu tak nebylo)
- přidal jsem ještě další zónu, která určuje to, že dochází k zakončení
- při změně držení míče (mimo krajní zony, zakončení) se již hra nepřesouvá automaticky do středu hřiště
- hra je připravena pro implementaci protiútoků (counter attack), ale zatím mi to nepřišlo jako důležité

V zápasovém engine zatím není, ale určitě by mělo být:
- implementace protiútoků (obecně)
- boj o pozici nemusí nutně vést k posunu dál nebo změně držení míče (tzv. dobývání šestnáctky)
- implementace různých herních stylů (např. držení míče, přímočarý, obranný, protiútoky atd. - tohle bude nejhorší vymyslet, protože bude těžké vyvážit výhody a nevýhody každého stylu)
- vliv prostředí na týmový výkon (doma hrajou týmy lépe než venku; na špatném terénu se špatně kombinuje atd.)
- zranění, střídání, vyloučení
DAN1   23:07:01 03.08.2020
Už jsem se opět dostal dále, ale nastal jeden problém, se kterým si lámu hlavu už několik dní, třeba někdo poradí...

Dostal jsem se do fáze, kdy už vím, že tým A má šanci (zakončení) proti týmu B. U týmu B je to jednoduché, zde se pracuje s ratingem brankáře, ale u týmu A netuším, jak co nejefektivnější a nejjednodušeji zvolit konkrétního hráče!

Umím určit, na jaké pozici hraje hráč, který bude zakončovat. Ale nevím, jak jednoduše určit toho jednoho konkrétního hráče, který má zakončovat šanci. Řekněme, že zakončovat bude jeden ze záložníků (cca 30 % všech šancí) a těch mám na hřišti 4.

Úvaha je taková, že ti s nejlepším ratingem mají mít nejvyšší šanci se do zakončení dostat (prostě když budu mít 3 pepíky a jednoho Pavla Nedvěda, tak do zakončení se dostane pravděpodobněji Nedvěd). Ale pro další zpracování nepotřebuji znát jen rating zakončujícího hráče, ale jeho jméno (id). A hráči, kteří jsou momentálně na hřišti jsou uvedeni v poli pod indexy 1 až 10 (s tím, že pozice pod indexy jsou různé dle rozestavení, např 4-5-1 = jeden útočník; 4-3-3 = 3 útočníci atd.).

Jak  tedy co nejjednodušeji získat index konkrétního zakončujícího hráče, samozřejmě náhodně zvoleného, ale tak, aby pravděpodobnost byla určena ratingem (v rozsahu cca 5.0 až 9.9)? Ve výše uvedeném příkladu, tedy jak zvolit jednoho ze čtyř záložníků? Zvláště, když potřebuji jen získat index pole.
SYSTEM   06:43:01 28.07.2020
Automaticky generovaná zpráva:
Klubová anketa byla vynulována.
DAN1   19:59:40 22.07.2020
Pokud by to náhodou bylo pro někoho zajímavé, tak úplně základní implementace soccer-decoder (moje implementace pomocí PHP) je k vidění tady https://codeshare.io/5zOkON a 49 zápasů generuji za cca 0,08 s

Ale je to teprve začátek, ještě tam bude zapotřebí implementovat spoustu věcí, jako je vliv fyzičky, věku, formy atd.
DAN1   16:27:52 21.07.2020
PAULSMITH [ 11:10:56 21.07.2020 ]: díky za zpětnou vazbu, je to spousta otázek k zamyšlení...

Než na to zareaguji, tak chci jen říct, že jsem něco podobného viděl napsáno v Reactu, což mě zaujalo - https://fd-sim.surge.sh/ Běhá to docela rychle, ale vývoj toho je pomalý a běží to na velmi jednoduchém algoritmu, kdy se prostě jen provnávají ratingy, sčítají body a ty pak určí vítěze.

Ad1) Jelikož moje implementace bude založená na veřejné práci (soccer decoder), tak mi nevadí, že se na to někdo koukne. Dokonce to možná zveřejním i na GitHubu
Ad2) Jak náročné zápasy budou zatím netuším... je to na mnohem hlubší analýzu, ale základní algoritmus má 100 opakování, kdy se spolu něco porovnává, generují se náhodná čísla určuje se další průběh. Jenže!
a) Netuším, kde se vzalo to číslo 100, tohle se ještě může změnit (je třeba to nějak vybalancovat), klidně těch opakování může být víc
b) Algoritmus v základu řeší pohyby po hřišti, ale chybí tam vliv hřiště, trenéra, únavy, taktiky atd. - tohle udělá časem celý výpočet složitější (kolikrát, zatím nevím)
c) Chtěl bych tímto algoritmem počítat nejen své zápasy, ale všechny zápasy soutěže (8 až 10 utkání na jednu ligu), ne jak jiné hry, které ostatní zápasy "odrbou"
d) Rád bych časem simuloval více soutěží, řekněme že třeba 5 soutěží po 20 týmech = 50 utkání v jednom kole, které by se počítaly "najednou"
e) A to tady ještě nemám vymyšlená střídání, zranění, vyloučení atd. => zase složitější výpočet i vyšší nároky na data

Z toho všeho vyplývá, že by pro každý zápas a tým mělo být k dispozici 17 hráčů, celkově možná i víc, třeba 20. Při dvaceti týmech je to jen v základu 400 hráčů na ligu + nějací volní hráči. Při 5 ligách už by to bylo 2000 hráčů + volní. Časem taky nějací geneři, jako příchod mladých hráčů (řekněme 5 až 8 mladých každou sezónu), takže se databáze (ať už bude SQL nebo jiná) bude nadále rozrůstat s každou sezónou.
K výpočtům je zapotřebí získat data (nejspíše z databáze), kdy se načtou potřebné údaje o hráčích, spočítají se počáteční ratingy atd.

A k tomu zbytku se nevyjádřím, neboť tomu sám moc nerozumím.
PAULSMITH   11:10:56 21.07.2020
DAN1 [ 18:59:44 20.07.2020 ]: TLDR: jestli je to pro radost, udělal bych to v tom, co tě baví/chceš se naučit/umíš.

Pár otázek k zamyšlení:
* Vadí ti, že někdo bude chtít zápasový algoritmus exploitovat? Když bude na backendu, to bude těžší.
* Jak náročné ty výpočty budou v porovnání s datovým přenosem? - nemůžeš totiž počítat s ničím u klienta, nevíš, jak silný stroj bude mít, atd atd. když budeš počítat na backendu, můžeš řešit různé optimalizace napříč klienty. můžeš škálovat železo mnohem snadněji, ale zase to víc leze do peněz, než když servíruješ jen program, který si to pak počítá jinde. (mluví zaujatý backenďák)
* bude to vyhodnocování všechno transakční, nebo budeš mít nějaké kontinuální background joby?
* k databázím: strašně záleží na typu dat. jestli se na tom chceš hodně naučit, doporučím ti napsat si to se všema a napiš si na to benchmarky. ale takový rules of thumb: cokoliv větší než malý, co vyžaduje referenční integritu (cizí klíče) - vyhni se sqlite. tenhle use case, než přeroste) ti zvládne asi každá sqlka. Pokud pokukuješ po no-sql, tak to nejde jen tak od pasu. existují rychlé, existují spolehlivé, existují velké. ale všechno záleží na tom, jaká data tam budeš zapisovat a jak...
* další rule of thumb: jestli ti jakkoliv hrozí, že to budeš někdy využívat jiné klienty/platformy, než pro který začínáš, tak striktně dodržuj rozdělení backend - frontend. až ti přijde nový frontend, poděkuješ si.

Takže můj postup by byl:
frontend - co nejtenčí s minimem javascriptu.
backend - servíruju si z vlastního VPSka, takže mi nezáleží na cloudových optimalizacích, lambdách a jiných pokročilých featurách. pokud se rozhodneš pro aws/azure/google, budou myšlenky trochu jiný
- railsy
- hlavní data (uživatelé, nastavení, ... málo se mění, důležitá je konzistence) v SQLce
- cache a vedlejší data (často se měnící data k výpočtům, průběžná data) do Redisu
- background joby bych dal do sidekiqu (rails-specific, ale resqueue mě jednou spálilo)

ale ještě jednou důležitý: Jsem zaujatý backenďák bez cloudu.
DAN1   18:59:44 20.07.2020
Zdravím, dělám si teď tak pro radost jednoduchý fotbalový manažer a zajímá mě, jak postavit architekturu. Zatím totiž dolaďuji zápasový algoritmus a jaké nároky na data to vlastně bude mít.

Aplikace je určitě koncipována jako jednouživatelská, tzn. že jedna herní sada ("databáze") je pro jediného uživatele (alespoň zpočátku), ale chci to jako webovou aplikaci, abych mohl mít tu apku na serveru a zahrát si kdykoli a odkudkoli.

A nyní řeším na čem to postavit. V podstatě mám více možností s tím, že jediné o čem jsem tak nějak přesvědčen je, že výstup bude HTML5+CSS, ale jak řešit výpočty?
1. PHP a vše počítat na straně serveru?
2. Napsat si to v JS, takže by apka mohla být teoreticky rychlejší?
3. Používat pro data klasickou DB (MySQL) nebo něco jiného (SQlite, popř. něco úplně jiného)?

Našel jsem pár řešení na GitHub, kde se používají různá řešení (neřeším desktop a mobile) a jsou tam jak PHP, tak čistě JS (React) věci. A mě jen zajímá co by na to asi bylo v hodnější...

PAULSMITH [ 20:20:46 30.09.2018 ]: Díky za tip, já si to přečetl, ale bylo to už v době, kdy jsem to měl de facto vyřešeno ;:)
PAULSMITH   20:20:46 30.09.2018
DAN1 [ 12:10:10 09.09.2018 ]: Dělám ve firmě, která umí monitoring klíčového slova (často zákazníkova značka) ve článcích či sociálních sítích. U této věci jsem nebyl, ale chceš propojit?
DAN1   12:10:10 09.09.2018
Je to z vedlejšího klubu, ale dám to i sem, třeba někdo už něco podobného řešil...

Řeším už dva dny problém, že bych rád sbíral z českých RSS jen konkrétní články. Ty které by splňovaly nějaké parametry (např. by v názvu nebo v textu bylo slůvko "Indy"). Vytvoření vlastního RSS kanálu mi nečinilo problém, ale to jsem tahal články z vlastní DB. Přiznám se, že nevím jestli vůbec existuje řešení tohoto problému. Díky za každou reakci
DZODZO   10:09:50 15.07.2018
prosim vas neviete co je to za programovaci jazyk Rajhrad? :10)

IMG:http://gallery.kirril.com/images/0001/1531642155748.jpg
YURA   13:50:49 23.02.2018
Nevim, jestli sem nekdo chodi, ale zeptam se.
Potrebuju poradit SQL dotazy v Access neco pro ignoranta jako jsem ja - uplne zaklady jak pro idiota
Treba ted se snazim vypsat dve hodnoty ve sloupcich jestlize hodnota ve slupci D je mensi nez ve sloupci S

SELECT D, S
FROM Tabulka_C
WHERE D < S

To mi ale vyhodi vsechny zaznamy, ktere jsou plne a nevim jak to omezit, aby mi to vypsalo jen ty, co maji hodnotu S vetsi nez D
MIRIS   21:31:03 23.09.2016
DAN1 [ 18:30:21 21.09.2016 ]: sem lama ,ale nekde se  to cykli, otazkou je proc se to cykli? mozna htacesem? mozna adresa 1 smeruje na 2 a 2 smeruje na 1 ?
PAULSMITH   13:52:02 22.09.2016
DAN1 [ 18:30:21 21.09.2016 ]: tak základní otázka je jestli ten prohlížeč po zadání té adresy vůbec dorazí na správný stroj.... takže tracert/traceroute na adresu a sledovat IPčka...

to ti problém nevyřeší, ale pomůže lokalizovat
DAN1   18:30:21 21.09.2016
zkusím to i tady...
Zdravím,

v rámci jedné zakázky nám firma instalovala nový HW, na kterém nyní běží virtuální servery. Na jeden takový pak technik instaloval LMS Moodle, bohužel si ho tak trošku pojmenoval podle sebe, takže adresa byla "portal1.domena.cz"...

Server je Ubuntu 15.10, dále je zde PHP 5.6, PostgreSQL (9.4) a Apache.

Nyní si už musím nastavit vše sám, aby to běželo na "moodle.domena.cz" (na subdoméně portal už totiž běží jiná aplikace na jiném serveru). Změnil jsem záznamy v DB a config.php samotného Moodle. Dále jsem nastavil hostname na "moodle.domena.cz" a přidal i nový záznam do apache (site-enabled) s tím, že původní (portal1) jsem dal disabled. Jiný člověk pak přidal záznam do DNS, tam nemám přístup.

Problém je, že se na "moodle.domena.cz" nedá dostat, bohužel ani na původní "portal1.domena.cz". V prohlížeči to háže chybu "ERR_TOO_MANY_REDIRECTS", takže jsem asi někde něco nezměnil. Otázkou je kde a co? Mě už bohužel nenapadá co dál změnit...
FROGGER   15:57:08 30.11.2014
Tak tak, nejprve se provede složení celého dokumentu (tj. se všemi includy) a pak se to celé shora dolů začne provádět.
1 / 42

Prodej a vykup aut