|
Koji programski jezik?
Molim za pomoc iskusne programere. Interesuje me u kojem programskom jeziku su napisani sledeci sajtovi:
https://www.bwin.com/sportsbook.aspx http://sports.williamhill.com/bet/en-gb https://sports.gamebookers.com/en/sports http://www.pinnaclesports.com http://www.ladbrokes.com ...i sl Dakle, radi se o sajtovima online kladionica. Da li su ovi sajtovi radjeni u PHP-u, Javi ili nekom trecem programskom jeziku? I kako na kraju krajeva mogu uvidom u kod da saznam o kojem se programskom jeziku radi? Hvala unapred na svakoj pomoci. |
koliko ja znam uglavnom svi najveci gambling sistemi su radjeni na javi, mada ovi koji si ti naveo su u ASP.Net-u
a mozes da znas po vise osnova, recimo .aspx extenzija je .Net, zatim pogledas headere koje server salje, koji je server u pitanju (Apache ili IIS) i sl. |
|
Da li to znaci da recimo HTML 5 + PHP nije dobro rešenje za sajtove ove tematike? Tj da je Java bolja opcija?
|
Citat:
|
Citat:
Iz tog razloga sam mislio da je kombinacija HTML5 + PHP + JavaScript (ili eventualno Phyton) nešto što bi funkcionisalo brže i pouzdanije, ali sam očigledno na pogrešnom putu. Hvala još jednom i svaka dodatna informacija je dobrodošla. |
Nisam ljubitelj jave iz mnogo razloga, ali java definitivno nije spora... Twitter recimo polako prelazi na Javu umesto Rubija koji su koristili, jer je javin VM efikasniji (uz odgovarajuci multithreading)
Ali kod gamblinga nije stvar (samo) u brzini koliko u kompleksnosti i pouzdanosti takvih sistema... primera radi Meridian ceo radi na jednoj aplikaciji, znaci sva uplatna mesta, kvote za kladionice sirom zemlje, web, sve to gura isti java kod i baza. Mogli su oni to da naprave kao web servis, pa da front-end za web guraju na PHP-u, bilo bi im lakse za dizajn, ali kad vec imas java tim onda obicno gledas da ti oni sve odrade da bi smanjio troskove... |
Citat:
Nije sporno da uplatna mesta rade na Javi i da na taj nacin sve funkcionise i sve je gotovo. Ali u slucaju da troskovi nisu problem, da li je preporuka da se i front-end deo sajta radi u Javi ili u PHP-u ili Phyton-u? |
Kad je gaming u pitanju, možeš da zaboraviš bili kakvo eksperimentisanje.
Java je odlično rešenje iako je ne volim nikako. Pouzdanost je ono što je jedino bitno a pouzdanost se jako teško podiže i košta mnogo više nego što može da učini na prvi pogled. Sam frontend je najlakši deo u odnosu na ono što stoji u pozadini takvih sajtova. |
Front-end mozes da uradis u bilo cemu, server-side tu prakticno i nema posla. Treba ti javascript koji ce da ucitava live feed sa rezultatima (koji generises recimo iz jave) i sve ostalo je manje-vise statican html.
Konkretno iz mog iskustva u Meridianu: oni koriste GWT za generisanje sajtova, jer je java timu tako bilo najbrze da uradi. To se pokazalo kao problem, jer dizajneri ne znaju da rade sa tim, a tebi je cesto potrebno da napravis sitnu izmenu u dizajnu sajta (dodas pahulje za novu godinu ili najavis neku akciju i sl). Ako moras da cimas java programera (koji pritom ima gomilu svog posla) za svaku izmenu u dizajnu to je jako sporo i skupo. Znaci sa te strane bilo bi bolje da su to malo bolje osmislili, da su postojali obicni html / css templejti, ali to ti onda opet pravi problem kod vecih zahvata, jer GWT vodi racuna o mnogim stvarima za tebe... sve u svemu nemas tu neki recept, mora da se proceni konkretna situacija, zahtevi i sl.. |
Java uopšte nije spora. Problem Jave je što traži znanje a mnogi ljudi ga nemaju.
Nisam jednom u PHP kodu nalazio dijelove koda koji ubiju server kao zeca |
Све ми се чини да ће тема да оде у погрешном смеру :)
|
OK, da probam da je vratim u pravi smer.
Imam nesto sto je nalik ovim sajtovima, a da vam ne bi objasnjavao o cemu je konkretno rec, lakse mi je bilo da sve to uporedim sa kladionicarskim sajtovima, koji u mnogome lice na to sto ja (mi) imam. Kod nas su isto radjene GWT aplikacije i kompletan sistem je pisan u JAVI. Sve sto se radi offline, nema problema i sto kazu radi kao sat. Medjutim, kada se to prebaci na web, desi se da prilikom nekih malo vecih opterecenja (tipa 1000 poseta u jednom trenutku), sajt zakuca server. Na samom sajtu je koriscen JavaScript. Moje razmisljanje je islo u pravcu da li da pokusamo sa preradom na PHP ili nesto slicno i da li ce to ubrzati kompletnu pricu. Drugi problem je upravo ovaj koji je pomenut, dizajneri jako tesko mogu da prave izmene, koje nisu tako retke, vec sve mora da ide preko programera, aplikacija...itd itd... Ja bih hteo da dobijem situaciju u kojoj je sajt stabilniji i u kojoj je jednostavniji za izmenu. Sve sto je u pozadini, sto se mene tice moze da ostane Java i sa time nemam problema. Koliko sam shvatio vase komentare, sve ovo manje vise se moze postici i sa samom Javom, ukoliko je onaj koji je kreira dobro poznaje i dobro optimizuje. |
Rešenje koje možete da uradite je da napravite relativno jednostavan API ka Java backendu koji će vam samo isporučiti podatke koji treba da budu vidljivi u frontendu a zatim ostatak radite nezavisno.
Deluje kao više rada u startu ali se definitivno isplati naročito jer značajno olakšava posao programerima i dizajanerima da vrše izmene a da ne mogu da zabrljaju mnogo, i da ne moraju da čačkaju tamo gde ne treba. |
Citat:
Koja je preporuka za taj frontend? Kojim jezikom da se pise? Izvinjavam se na ovoliko pitanja i podpitanja, ali medju programerima sa kojima radim nikada necu dobiti valjan odgovor, jer svako svoga konja hvali, bez obzira sto na kraju stvari ne rade kako bi trebalo. |
Ja bih za odvajanje front-enda od back-enda preporucio Smarty template http://www.smarty.net
Sluzi da bi sto vise odvoji te dve stvari i olaksao posao dizajnerima ali i programerima koji ne zele da se bakcu sa dizajnom. A sta je bolje Java ili PHP je tesko reci, generalno Java je i brza i stabilnija. Dok se u PHPu brze odrade neke stvari - mada i to je diskutabilno. Na kraju se sve svodi na to sa kakvim developerima radis. |
Meni je taj smarty mnogo ružan. Nisam php programer, ali kad moram koristim TWIG http://twig.sensiolabs.org/ za templating.
Razmisli i o renderovanju templatea na klijentu (Handlerbars, Mustache ...). Kod na klijentu stvarno može lepo da se razdvoji i upotrebom RequireJSa (AMD). Handlebars ili Mustache - templating RequireJS - za organizaciju modula, dependency injection, optimizaciju js-a itd BackboneJS, EmberJS - eventualno ako praviš single-page aplikaciju. |
http://phalconphp.com/ PHP framework u C (=brzina) extenziji.
http://phptemplatinglanguage.com/ PHP kao templating engine. http://vanilla-js.com/ I pazi ko piše Javascript i kako. |
Off Topic: @svlada: Stvar ukusa. Smarty 3 i Twig imaju jako slicnu sintaxu, ali verovatno je stvar naprosto u jeziku na koji si navikao. Smarty ima vise php-like sintaxu i koristi samo jedan par {}, a Twig koristi {{}} plus one asp {% %} tagove, sto je meni licno manje pregledno. |
Citat:
Ja da pišem tako nešto za sebe pisao bih u node.jsu, čisto da vidim kako je. ;) |
Po mom misljenju PHP nije dobar izbor za ovakvu aplikaciju. PHP radi sa MySql-om koji je sa velikim brojem podataka dosta jadan. Ovakva aplikacija ti zahteva debelu - tesku bazu (sposobnu za rad preko 10 miliona rekorda) zbog brda podataka, indeksiranja i td... ++++ sigurnost ovakve aplikacije je vazna i programerski gledano. Pored toga u bazi podataka Join je skupa operacija, tako da potpuno normalizovani model cje zdrati mnogo resursa. I taj HTML koji budes dobio, cekacjesh ga dugo. Ako ne da odgvor za 2-3 sekunde nije dobro bio on sinhroni ili asinhroni.
Tako da neka Java serverska tehnologija ili .NET kapiram da cje resiti. Pored toga treba dugorocnije razmisljati o odrzavanju aplikacije, tako da MVC pattern i serverske tehnologije koje ga podrzavaju treba da uskoce u igru. |
PHP radi sa MySQL ti je malo glupa izjava http://php.net/manual/en/pdo.drivers.php https://github.com/mongodb/mongo-php-driver ... ext/mysql je deprecated i biće prebačena u PECL u skorijim verzijama.
|
ok, glupa je , trebalo je da napisem "uglavnom radi pod mysql-om , makar ono sto sam ja gledao" . . . valjda je to politicki korektno.
Jel si ti radio pod drugim bazama sa PHP-om, ako jesi jel imas neko iskustvo, interesuje me ? |
Rekao sam malo glupa :)
Ne vidim zašto bi bilo znatno drugačije nego sa drugim programskim jezicima (komunikacija sa bazom)? A mogu ti reći da 10.000.000 recorda u MySQL nije ništa, ali to opet zavisi od broja konekcija na bazu, tj broja posjeta. Radi šta ti je isplativije za početak, kad budeš imao problem sa skaliranjem, onda se zabavi time... |
Citat:
To ne sprecava ljude koji ne znaju sta rade da pisu lose query-je, i da se posle pravdaju besmislicama kao sto je ova. EXPLAIN je vas prijatelj. |
hvala na definiciji, potrebna je.
Ocigledno se nasa iskustva razlikuju. Verovatno i velicine baze na kojima radimo. |
Nasa iskustva sa JOIN-ima su toliko pozitivna da ih koristimo i otkako smo presli NoSQL :)
|
| Vreme je GMT +2. Trenutno vreme je 07:52. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.