Vélemény a Webtudorról

Projektek általános

Sziasztok,

elérkeztünk a Webtudorral a 10. előadáshoz és szeretnénk egy kis segítséget kérni. Ha van egy perced, kérlek, töltsd ki ezt a kérdőívet: http://goo.gl/forms/zS5kTFo4UB (Google Forms).

Ha inkább szabad szavasan mondanád el, hogy mit gondolsz, írd le a megjegyzésekbe.

Let the flamewar commence. :)

(És köszönjük a segítséget.)

( dejo v | 2015. 04. 20., h – 22:31 )

Kitöltöttem, de nem hiszem, hogy sokra mész vele.
Csak általánosságban tudtam véleményt mondani egy feltételezett valamiről, mert sohasem hallottam a Webtudorról.
Kerestem de nemigen ez az? http://webtudor.hu
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

A választ lásd alább janoszentől. :-)
Amúgy van egy csomó általános kérdés. Milyen gyakran, milyen hosszú, milyen mélységben, hány rész lehet egy sorozat, élőben vagy felvételről, stb. Ezekre simán lehet válaszolni.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

( maszili | 2015. 04. 20., h – 23:45 )

Én csak a "upc-vs-externet-interju-angeli-janossal" részt láttam "felvételről" de abban szerintem kicsit sokszor (percenként legalább egyszer) hangzik el a KVÁZI szó...

( khiraly | 2015. 04. 21., k – 09:57 )

Most raneztem a weboldalra (pontosabban a "linux alapok fejlesztoknek" videot)
Ami megvan:
- kamera
- egy youtube videohoz elegendo filmvagasi kepesseg
- zene

Ami nincs meg:
- youtube-nezo idejenek nem-elb*szasa

Most komolyan. Az osszes video 1+ ora. Kinek van turelme ugy vegignezni, hogy az elso video 3 percig mindjart kezdodik zene megy.

Az a zene mehetne hatternek. 20mp-es atvezeto animaciok is ertelmetlenul idorablok.

Szerintem ezeket a videokat 10perces szeletekre kellene osztani.

Noh mindegy. En belehallgattam 10 percet, csak hogy *ertelmesen* tudjak hozzaszolni, de nem erzem ugy, hogy jol toltottem volna el az idomet.

Mondjuk ha nagyon videozni akarok ugyis angolul hallgatok informatika temat.

Azert egy linux telepitest 1:1 lenyomni azert durva. Illene belegyorsitani...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ugye ezek elo adasok, ahol a nezo kozbe tud kerdezni. Nyilvan ha szerkesztett adasokat csinalunk, akkor egeszen mas a helyzet.

Ami erdekes gondolat, hogy vajon erdemes-e megszuntetni az elo adasokat es helyette inkabb szerkesztett videokat adni.

--
Pásztor János
Üzemeltető Macik

Ne szüntessétek meg az élőt, én mindig nézen! :-)

Ettől függetlenül tényleg lehet lehetne gyorsítani az adásmeneten adásmeneten. A upc vs externet ebből a szempontból (is) nagyon jóra sikerült, talán azért is mert nem egy embernek kellett mindent intéznie.

Ha az előadás után nem azonnal, hanem csak néhány nap múlva kerül fel a videómegosztóra szerintem az nem olyan nagy baj, mintha vágatlan nyers anyag lesz fönt véglegesen hosszú időkre.
Szóval a nyers felvétel ne is legyen kint és akkor a kereső nem fogja azt megtalálni.
Esetleg legyen a címben jelezve: [nyers] [szerkesztett] és akkor arra is lehet keresni.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Nem ez a problema. Belinkeli vagy beagyazza a linuxmint.hu, az itcafe.hu, a prohardver.hu, stb. es ok mar nem fogjak megvaltoztatni a linket. Ha atteszem a videot privatra, akkor azok a userek akik kesobb onnan jonnek, lukra futnak. (Es igen, ezek valos peldak.)

--
Pásztor János
Üzemeltető Macik

( Polesz v | 2015. 04. 21., k – 10:08 )

Megnéztem 1-2 előadást, aztán a többit is. Ígéretes. Lehetne gyorsítani, ahogy khiraly is írta jól. Egyébként nem problémás. Csak így tovább előre a lenini úton :-)

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

A youtube-on oda kattintasz az előadásban ahova akarsz. Én is át szoktam lapozni az elejét.
Meg 1.25x, 1.5x, 2x-es sebességgel nézem meg / hallgatom most is meg. Tehát lehet gyorsítani, ha szeretnéd most is. :-)
Másnak viszont lehet, hogy így túl gyors. A normál tempó jó a kezdőknek.

Ha őszinte akarok lenni, akkor a célközönség nem egészen tisztázott. A mára már zombi állapotban levő Weblabor helyett szeretnék egy olyan platformot, ahol lehet webfejlesztőknek, webfejlesztésnek fontos témákat megvitatni, illetve az ifjabbaknak segíteni, hiszen én is így kezdtem. (Lásd http://devstories.hu/sztori/4)

--
Pásztor János
Üzemeltető Macik

( Kayapo | 2015. 04. 21., k – 19:37 )

Tegnap éjjel meg ma reggel megnéztem néhány videót, keresve, mivel lehetne javítani.

Itt is sokan említik az "érdeklődési völgyeket", távozási pontokat.

Felkelted az érdeklődést de nem tartod fen. Ez egy élő adásnál nem könnyű. Csak nagy apparátussal lehet ide-oda kapcsolgatni a helyszínek között, ez nyilván nem megoldás. Megoldást hozhat az a módszer ahogyan annak idején az "Ablak" c. műsor volt élő:
Nagyjából és egészében az élő adás annyit jelentett, hogy "konzerv műsort" néztünk, előre felvett bejátszásokat tárgyaltak meg a stúdióban.

Tehát a téma részeit előre felveszed, ahogyan mondjuk egy programozási feladatot, részletről részletre haladva, feldolgozol, 5 - 15 perces sketch -ekben. A részek között pár perces szünet amiben a nézőkkel meg tudod vitatni a történteket, illetve megvilágíthatod más aspektusait is a témának.

----
올드보이
http://molnaristvan.eu/

Csak most esett le, hogy az "élő adás" egyenesen a Youtubon keresztül megy és egyúttal az marad a felvétel is.
Na hát így tényleg nehéz vágott anyagot készíteni belőle. Úgy hogy ugyanazon a web-címen maradjon.
Akkor esetleg az élő adás felvétele alá oda lehetne tenni a szerkesztett videó linkjét.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Igen, ez a formátum eredetileg arra lett kitalálva, hogy az emberek élőben nézik. A mostani visszajelzések alapján viszont hajlok arra, hogy ketté osszam a témát és az előadások menjenek felvételről, a talkshowk illetve kérdés sessionök pedig maradnak élőben.

--
Pásztor János
Üzemeltető Macik

( pityulaman1983 v | 2015. 04. 24., p – 06:43 )

Én majd mindre join-t nyomok, de tegnap is fél 9kor vettem észre, hogy már megy. Kellene valami Webtudor ébresztőóra app/widget/whatever, ami az arcomba tolja, hogy "APA, KEDZDŐŐŐŐDIK!!!!" :)
Említették az érdeklődési völgyeket. Anno az SQL Server 2012 bemutatóján voltak előadók, akik ezt a csúcsra járatták. Fantasztikus volt az összes előadás. A PowerView előadásról már majdnem kimentem, mikor kiderült, hogy ez is a show része. Az előadó nagyon jó érzékkel találta el, hogy meddig lehet feszíteni a húrt, hogy aztán amit tényleg be akar mutatni, az viszont nagyot üssön.
Az Always On technológia bemutatását pedig annyira viccesre vették, hogy esténként a Rém rendes család előtt/után szivesen megnézném újra.

-----------
"Pontban 0:00-kor nem nagyon szoktak véletlen dolgok történni"

( janoszen v | 2015. 05. 15., p – 09:02 )

A visszajelzéseitekre hallgatva megalkottuk a sorozatunk következő videóját "Hogyan írjunk böngészős játékot?" címmel. A videóhoz az inkább olvasók kedvéért blogpost is tartozik.

kép

Sajnálom hogy ilyen rövid lett a videó, mi az oka? Nagyon tetszettek az eléggé mélyre menő előadások. Örülök neki hogy szerkesztett lett és nincsenek üresjáratok, de sajnálom hogy emiatt a tartalomból is vágni kellett.

(Számomra eddig a legjobb adás amit "megvágtál a YouTube borzalmas szerkesztőjével")

Mindenesetre át fogom olvasni a github kódot érdekesnek ígérkezik.

Sokat küzdöttem azon, hogy ilyen kompakt legyen. Az élő adásban ez könnyebb, de ott ugye sok az üresjárat, amire sokan panaszkodtak. Remélem, így hogy vágott videókat csinálunk, könnyebb lesz majd elosztani a munkát.

Ebben benne volt az is, hogy ez az első ilyen, így is 3 nap meló volt. Remélem, majd gyorsabban fog menni.

--
Pásztor János
Üzemeltető Macik

Szerintem az igazán optimális hossz valahol a kettő között van, ennél azért jóval bővebb tartalommal tartalommal, csak a konkrét kérdésre várást, technikai szüneteket, kapcsolgatást mellőzve. Mondjuk olyan 30-45 perc környékén. Persze beleszólni mindig könnyebb mint elkészíteni, úgyhogy elnézést kérek :-) Ha tudok valami segítséget nyújtani, ne kímélj.

Hacsak nem akarsz az After Effects - Premiere komboval sokat dolgozni, nem igazan tudsz segiteni jelenleg. :)

Update: Azaz mégis csak tudsz. Ha így dolgozunk, akkor a témákhoz mindig előre meg kell írni a szöveget és feljegyzetelni a shotlistet hogy hova milyen animáció kerül. Ha erre van kapacitásod, isten hozott.

--
Pásztor János
Üzemeltető Macik

Írtam egy kisebb választ... :)

https://www.webtudor.net/s1e13-hogyan-irjunk-online-jatekot/#comment-31

Mivel "Your comment is awaiting moderation.", ezért:

Néhány észrevétel, javaslat, ötlet, mint gyakorló játékfejlesztő... :)

"Műszakilag rengeteg minden kell hozzá, éppen ezért nem kis fába vágod a fejszédet."

Ha az ember egyedül kezd neki, akkor nem csak műszakilag kell rengeteg minden, hanem mindenféleügyileg kell rengeteg minden: a teljes stack kezelése az üzemeltetőtől kezdve a fejlesztőn, grafikuson és tesztelőn át a menedzserig és pénzügyi emberig mindenre szükség van. Mármint akkor, ha az ember komolyan gondolja... :)

"Ezekről egy igen kiváló áttekintést nyújt a html5gameengine.com oldal."

Ez egyébként kicsit megtévesztő és szerény véleményem szerint félrevezető is, mert jelenleg az új casual játékok nagyon-nagyon-nagy része mobilon jön ki először, mobilon pedig a fenti keretrendszerekből nagyon szép képregény lesz csak mobilon, a WebGL alapú megoldások pedig szinte alig működnek, ha mégis, akkor ott is egy nagyságrend a különbség teljesítményben.

Szóval ha cél a mobil platform is - márpedig cél, akkor a Javascript felejtős. Nagyon felejtős! Helyette el kell dönteni, hogy melyik az elsődleges platform: az iOS vagy az Android.

Mind a kettő esetben van lehetőség arra, hogy a másik platformon minimális teljesítményvesztéssel működjön a program, az iOS-Android irányt nem ismerem, de az Android-iOS irányra teljesen jól működő megoldás a Libgdx, elég sok alkalmazás használja, minimális köret kell csak iOS-on a Libgdx core modul köré.

De az egyik esetben Java nyelven kell fejleszteni, a másik esetben ObjC és/vagy Swift. Mindegyik eléggé messze van a Javascript-től.

"Az olyan nyelvek mint a PHP jók, ha hagyományos alkalmazásokat kell írnunk, viszont egy játék alatt hamar elvérezhetnek."

Sok minden más is el tud vérezni, például azon, hogy szerver oldalon teljesen másképp kell gondolkodni, mint a kliens oldalon... :)

"A NodeJS egy további előnnyel is rendelkezik: JavaScriptben írhatunk szerver oldali programokat."

Ami csak akkor előny, ha van a rakás JS fejlesztőnk a padláson vagy a spájzban, akiknek épp nem tudunk feladatot adni _és_ a szerver oldal buta, nincs benne logika vagy komplex számolás. Amint lesz ilyesmi és nem csak egy brókerként funkcionál, a NodeJS akadozni fog, márpedig egy játékban a szerver nagyon sok mindent ellenőriz, nem hihet a kliensnek, a kliens csak megjelenít és csak a megjelenítéshez (=élvezhető játékmenethez) szükséges logikákat tartalmazhatja.

Szóval ha nincs Javascript fejlesztő a spájzban és a kliens oldal se Javascript, akkor felejtsük el a szerver oldali Javascript-et... nézzük körül, van sok egyéb más megoldás, amelyek jól működnek, ha pedig az Android az elsődleges mobilplatform, akkor a szerver oldalra is próbáljunk Java-t tenni (hogy Java EE vagy Spring vagy bármi egyéb, az más kérdés).

"Kezdetben itt elegendő lesz egyetlen feldolgozó szál, ami percenként fut. Ezt akár a rendszer crontabjából is el tudjuk indítani és feldolgozzuk az aktuális feladatokat."

Ezt nagyon gyorsan felejtsük el. De tényleg!

Ez az eredményezi, hogy a szerver tüskékkel lesz terhelve percenként és ennek a percenkénti terhelésnek az ideje a felhasználószámmal és/vagy egyéb objektumok számosságával lineárisan növekedni fog. Először percenként egy másodperc, aztán tíz, aztán fél perc és a felhasználók azt látják, hogy a szerver szaggat vagy folyamatosan lassú.

Fordítsunk időt "szimulált játékidő" megértésére, az eseményvezérlésre, illetve arra az elvre, hogy az erdőben a kidőlt fának nincs hangja, ha senki nem hallja! Ez utóbbi a legtakarékosabb megoldás, minden objektum esetén eltároljuk az utolsó frissítés idejét és az interakcióknál kiszámoljuk az eltelt idő változásait minden érintett objektumra, ha nem megy az egy képletben való integrálás, akkor lehet szimulálni egy közönséges ciklusban az eltelt perceket is.

A lényeg az, hogy a szerveren legyen szétkenve a terhelés, mert a szerverért teljesítmény alapon fizetünk... legyen terhelve folyamatosan. Annak nincs sok értelme, hogy veszünk egy drága szervert sok pénzért, hogy percenként pár másodpercig mind a nyolc CPU dolgozzon a frissítésen és SSD kell alá, hogy gyors legyen, amikor elég lenne egy tized akkora gép tized annyi pénzért.

Ugyanakkor ne feledkezzünk meg arról, hogy ha véletlenül bejön a játék, akkor ne csak vertikálisan tudjuk skálázni egy darab nagyobb szerverre, mert előbb-utóbb elérjük a maximális szerverméretet és nincs tovább, illetve ha ez a szerver megdöglend, akkor sincs tovább. Olyan architektúrát építsünk fel, amelyik sok kis szerveren (=horizontálisan skálázható) képes működni, mert sok kis szervert jobban lehet cloud-ban üzemeltetni, mint egy nagyot. A szerverek számával könnyebben lehet játszani, mint a szerver méretével, mert általában csak felfelé skálázható a szerver, lefelé már nem.

"Éppen ezért érdemes vagy nagyon kicsi és nem erőforrásigényes játékot írni, vagy jól átgondolni, hogy miből kerül finanszírozásra a projekt."

Lehet hobbi is... havi 100 dollárból már egészen nagy szerverparkot fel lehet építeni és ez a 100 dollár a mi szakmánkban nem olyan nagy összeg, csak napi két kávé ára a céges büfében... :)

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Azert ha cel az eroforrashatekonysag, akkor a Java-t csak akkor rakjuk szerveroldalra, ha van egy rakas profi Java programozonk, akiknek epp nem tudunk munkat adni. Nem azert, mert a Java terhel, hanem mert egy nem hozzaerto Java programozo lassu es szar kodot fog irni, Javaban ugyanis ilyesmit relative konnyebb elkovetni, mint barmelyik masik nyelvben, talan az interpretalt nyelvek kivetelevel.

Szerintem itt inkabb az a jo paradigma, ha szerver oldalra is, meg kliens oldalra is olyan emberek programoznak, akik maximalisan ertik az adott nyelvet, es igazabol a szerveroldalnal tok mindegy, hogy az adott nyelv pontosan micsoda (Java, C#, Python, Ruby, C/C++, barmi jo lehet). Ha nem hobbiprojektrol van szo, akkor mar kozeptavon sem ugyanazok az emberek fogjak a szerveroldalt irni, mint a kliensoldalt, egyszeruen azert, mert a ket oldalhoz tok mas megkozelitesek szuksegesek.
--
Blog | @hron84
Üzemeltető macik

"Azert ha cel az eroforrashatekonysag, akkor a Java-t csak akkor rakjuk szerveroldalra, ha van egy rakas profi Java programozonk, akiknek epp nem tudunk munkat adni."

Ha az előző évtized közepén élsz, akkor igen. Azóta viszont eltelt tíz év és nem kell egy rakás profi Java programozó, csak átlagos programozók, akik olvasták a Java EE 7 for dummies könyvet. Tényleg nem kell több.

"Nem azert, mert a Java terhel, hanem mert egy nem hozzaerto Java programozo lassu es szar kodot fog irni, Javaban ugyanis ilyesmit relative konnyebb elkovetni, mint barmelyik masik nyelvben, talan az interpretalt nyelvek kivetelevel."

Sok minden igaz a Java nyelvre, például a magasabb belépő küszöb igaz, de az, hogy ha nem értesz hozzá, lassú lesz: az nem. Java-ban ugyanis eléggé véd a nyelv (sokan ez miatt szidják is), így relatíve sokkal nehezebb rossz kódot írni, mert nem fog működni. Ha meg rossz az algoritmus, akkor az bármelyik nyelven rossz lesz.

"Szerintem itt inkabb az a jo paradigma, ha szerver oldalra is, meg kliens oldalra is olyan emberek programoznak, akik maximalisan ertik az adott nyelvet"

One man show esetén sem fog fennállni, kompromisszumokat kell kötnöd, egyedül kell mindenhez érteni.

"(Java, C#, Python, Ruby, C/C++, barmi jo lehet)"

És ezek közül jelenleg a Java az, amelyikkel lehet az összes mobilplatformra (plusz nyártól WP-re is) fejleszteni, lehet HTML5 kódot generálni webre és meg lehet írni a szerver oldalt is. A második ilyen a C# a Unity és az IIS okán, de ezek már drága eszközök, nem lehet olcsón megúszni a licenceket. Aztán jön az összes többi.

"Ha nem hobbiprojektrol van szo, akkor mar kozeptavon sem ugyanazok az emberek fogjak a szerveroldalt irni, mint a kliensoldalt, egyszeruen azert, mert a ket oldalhoz tok mas megkozelitesek szuksegesek."

...és ezért legyen mindenhol Javascript? :)

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Osszeteveszted a rossz kod fogalmat a hatekonytalan kod fogalmaval, a ketto nem ugyanaz. Hiaba ved a platform, ha olyan kodot akarsz irni, ami tobbszazezer felhasznalot kiszolgal koltseghatekonyan, akkor bizony oda kell figyelni, hogy mikor mit hasznalsz. Mar a szalkezelesen el lehet bukni az ilyesmit, es az meg igencsak az alapja az ilyen rendszereknek. Te tapasztalt Java programozo vagy, szamodra elkepzelhetetlen, hogy "rossz" vagy hatekonytalan kodot adj ki a kezedbol. Egy most indulo startupba viszont nagyon jo esellyel nem a hozzad hasonlo tapasztalt oreg rokak fognak menni nagy mennyisegben, hanem a kockazatkedvelo fiatalok, akik meg nem estek tulsagosan pofara. Egy fiataltol nehez elvarni egy olyan melysegu tapasztalatot, aminek az osszeszedesehez az embernek 5-7-10 ev szukseges, torvenyszeru, hogy az ilyenek altal eloallitott kod csak a sokadik iteracioban lesz jo es koltseghatekony egyszerre. Es ez nem szegyen senki szamara, egyszeruen igy mukodnek ezek a dolgok. Csakhogy egy startupnak, amely tamogatastol tamogatasig el, nagyon nincs koltsegkerete arra, hogy a tokeletlen kod ala eroforrast tegyen, barmennyire is elkotelezettek a koderek a ceg celjai mellett.

" jelenleg a Java az, amelyikkel lehet az összes mobilplatformra [...] és meg lehet írni a szerver oldalt is."

De meg mindig nem latom, miert kellene egy embernek irni a szerver es a kliensoldalt is? A ketto gyoekresen eltero latasmodot, gondolkodast igenyel, raadasul a fokusz sem ugyanott van a ket oldalnal. Lehet, hogy egy hobbi one-man-show eseteben ez mukodhet, de egy produktiv rendszernel ez a legjobb esetben is ket kulonbozo embert jelent. Es igen, elhiszem, hogy te a gacivs-ot meg tudtad oldani szepen mind a ket oldalon, de nem mindenki Auth Gabor, es nem mindenki olyan jo Java programozo mint te vagy, raadasul te se az erettsegi utani fel ev alatt lettel egy olyan ember, aki a gacivs-ot ossze tudta rakni olyan minosegben, amilyenben az most van. Ami neked van, azt ugy hivjak, hogy tapasztalat, es ha megnezel egy akarmilyen random startupot, abba jo esellyel pofatlanul fiatal emberek vannak, akikben a legnagyobb joindulattal sem lehet meg a te tapasztalatod, mert egyszeruen nem elnek meg annyi ideje a fold felszinen.

"...és ezért legyen mindenhol Javascript? :)"

En ezt nem mondtam. Nem ismerem se a Node.JS-t se az IO.JS-t, nem tudok egyik mellett sem ervelni. Ha azonban van olyan programozo, aki kepes hatekony szerver oldali kodot irni, akkor a jatek szempontjabol tokeletesen mindegy, hogy az a kod Go-ban, JavaScript-ben, Haskell-ben vagy Brainfuck-ban van irva.

--
Blog | @hron84
Üzemeltető macik

> De meg mindig nem latom, miert kellene egy embernek irni a szerver es a kliensoldalt is?

Miert ne? :)

Most reszt vettem egy olyan fejlesztesben, ahol a kliens es szerver oldal is javascript.
Vannak reszek, amiket build idoben vesz at a szerveroldal a kliens oldali konyvtarbol (de lehetne forditva is), mert a kod pontosan ugyanaz. Az ellenorzest vegre kell hajtani kliens oldalon is es szerveroldalon is. Miert lenne kodduplikacio?

Olyan szinten nincs, hogy a build azzal kezdodik, hoyg atcopyzza a kliens oldali konyvtarat a szerver oldalra, es ugy fordul.

Amugy a node.js-t le lehet nezni, de rengeteg modulja nativ kodot fordit (pl. bcrypt),
a sebesseggel igy csak nincs gond:)

Ugyan meg nem irtam jatekot, de nem hiszem azt, hogy ne lehetne node.js alapon megirni.

Foleg ugy nem, ahogy Gabor mondta, hogy horizontalisan skalazodjon. Akkor igazabol tok mindegy, hogy ugyanaz a szerveroldal 50 vagy 100 instance-on fut (ha lenne kulonbseg javascript vs. java kozott).
Egyszeruen osszemerhetetlenul olcsobb tobb gepet berelni, mint fizetni mondjuk egy programozot egy honapig.

En inkabb afele az irany fele probalok elmozdulni, hogy minden componens kapjon egy kulon gepet (en esetemben: linux kontener), es azok egymassal http alapon kommunikaljanak (rest api).
Igy egy adott feladatreszt ki lehet adni php programozoknak vagy java programozoknak.

Szerintem ez a helyes irany, nem pedig az, hogy mindenkit atteritsunk a sajat programozasi nyelvunkre. Egyszeruen nincs annyi ido ra.

Persze a javaval nekem mindigis fenntartasaim lesznek. Hosszu evek rossz tapasztalata... :)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A törekvést értem, csak azt szerettem volna jelezni, hogy a webes játékok divatja elmúlt, mobil játékok vannak. Felőlem lehet bármiben fejleszteni, csak ne csodálkozzunk, hogy a kutya se játszik majd a játékkal vagy nem fizetnek egy vasat se. Részemről a témát befejeztem, van elég tapasztalt szakértő itt, akik játékokat adnak ki...

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Hat tudod, ha tenyleg olyan emberek ulnek a kulonbozo jatekok szervereinek fejlesztoi kozott, akik csak a Java EE 7 for dummies konyvon ragtak at magukat, akkor igazabol az egesz IT-t fel kene gyujtani a g*c*be. Avagy csak az uzemeltetok hosies kuzdelme tartja eletben ezeket a cegeket.
--
Blog | @hron84
Üzemeltető macik

"Hat tudod, ha tenyleg olyan emberek ulnek a kulonbozo jatekok szervereinek fejlesztoi kozott, akik csak a Java EE 7 for dummies konyvon ragtak at magukat, akkor igazabol az egesz IT-t fel kene gyujtani a g*c*be."

Mióta is van Java EE 7? Hmm... kicsit több mint egy éve. Biztos, hogy az utóbbi egy év Java-s technológiájáról beszélsz? Volt a kezeid között Java EE 7 alkalmazás? Tudod, hogy milyen egy Java EE 7 alkalmazás?

Szerintem nem.

"Avagy csak az uzemeltetok hosies kuzdelme tartja eletben ezeket a cegeket."

Ó... láttam én is ilyet, és? Egyszerűen ugyanannyi balfasz van a fejlesztők és az üzemeltetők között is.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Felreertettel, nem a Java EE 7-et kritizaltam. A "for dummies" cimu kiadvanyok ritkan melyenszantoak, professzionalis tudasra szert tenni beloluk aligha lehet. Es a Java EE 7 nem csodaszer, attol, mert ismerem a keretrendszert, meg nem fogok eroforrashatekony programokat irni, ahhoz - legalabbis remelem - kell egy "kis" gyakorlat. Ennyi erovel mondhatnank azt is, hogy aki elolvasta a Spring Framework getting started tutorialjat, az mar odaallhat jatekot fejleszteni. Hat nem, nagyon nem.
--
Blog | @hron84
Üzemeltető macik

"Es a Java EE 7 nem csodaszer, attol, mert ismerem a keretrendszert, meg nem fogok eroforrashatekony programokat irni, ahhoz - legalabbis remelem - kell egy "kis" gyakorlat."

Nem azt írtam, hogy random járókelő elolvassa a Java EE 7 tippeket és tud szerver oldalon fejleszteni, hanem azt, hogy átlagos Java fejlesztő elolvassa és tud szerver oldalon fejleszteni. Az egész Java EE azért készült, hogy ne kelljen sok és mély szakértelem a szerver oldalra, a Java EE 7 pedig pláne sokat tett ezért.

Egy esetben lehet elrontani a szerver oldalt, ha elolvasod a Java EE 7 for dummies könyvet, majd félrerakod, hogy "ez faszság, én jobban tudom" és megpróbálod jobban tudni, na ez utóbbiból lesznek az üzemeltethetlen termékek, minden más esetben stabil termék jön létre.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Mm-hm, az a plusz egy szó"

Aha... tehát az alábbi mondatban (ami be is idéztél) nem lehetett rájönni, hogy a kontextusban végig Java programozókról van szó?

"nem kell egy rakás profi Java programozó, csak átlagos programozók"

Most komolyan így kellett volna fogalmaznom?

"nem kell egy rakás profi Java programozó, csak átlagos Java programozók"

Nekem ez a szóismétlés bántja a szememet, mert a mondat kontextusa egészen jól meg van határozva. De ha ilyen szintre kell lemenni Veled szemben, mert ilyen szinten van a szövegértésed, akkor Nálad majd külön lemegyek ilyen szintre, jó?

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

C#-ban lehet fejleszteni mobilra (tényleg nem annyira olcsó, de viselhető), de pl. az IIS szükségességéről nem vagyok meggyőzve. (Főleg, hogy éppen most építek fel egy nagyobb – nem játék – rendszert, ahol a szerveroldal egy jelentős része C#, és nginx van előtte.)

"A kérdés kifejezetten böngészős játék volt."

Ezt értettem, ezért írtam a kiegészítést, hogy már egy ideje nem a PC és a böngésző az elsődleges platform casual játéknál, ott elkezdeni a fejlesztést HTML5 eszközökkel technológiai zsákutca.

"Nyilván manapság mobilos kliens fontos, de nem azzal kezded."

Miért nem? Játékot akarsz írni, amivel játszanak, nem? Az egyetlen valós döntésed az, hogy iOS first vagy Android first.

"Plusz én senkit nem ismerek, aki Javaval kezdte a webet. El kell jutni oda. :)"

Nem webről van szó. Értem, hogy Neked az első gondolatod a web és ott adja magát a Javascript, de manapság már mobilfejlesztők irányából érkeznek a backend-re az emberek és én sok embert ismerek, aki Android-dal kezdte a fejlesztést...

Technológiai ujjgyakorlatnak jó bármelyik HTML5 WebGL keretrendszer, de ha pénzt akarsz keresni, akkor irány a mobil... ott pedig kukázhatod a teljes HTML5 WebGL tudást...

"De a válaszvideódra kiváncsi vagyok. :D"

Nem videózok, grafomán vagyok... :)

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Miért nem? Játékot akarsz írni, amivel játszanak, nem? Az egyetlen valós döntésed az, hogy iOS first vagy Android first."

TBH ez igy ebben a formaban nem igaz. Ott az agar.io, lehet, hogy most mar van mobil kliense, de egyebkent igazabol browser-only jatek. Ott van a 2048, bongeszos jatekkent kezdte. Ott van az a rettenetesen sok farmos (FarmVille, Farmerama, stb) jatek, mind-mind bongeszos jatekkent indultak, es az erdeklodes novekedese triggerelte a mobilos alkalmazas megszuleteset.

Az az ember, aki az irodaban szamitogepen dolgozik, marpedig manapsag a legtobb ember ilyen, nem fog mobilt elovenni azert, hogy elusse az idot, raadasul a bongeszos jatekot konnyebb is hatterbe rakni, ha jon a fonok, mint egy mobilos alkalmazast.

Rettenetesen sok jo bongeszos, vagy bongeszore is elerheto jatek van, amivel emberek szazezrei jatszanak. Szoval nem, a valos dontesed az, hogy bongeszo first vagy mobil first. Azutan lehet donteni minden masrol.
--
Blog | @hron84
Üzemeltető macik

+1, ráadásul ha eddig webfejlesztéssel foglalkozott (amiről a csatorna szól), akkor könnyebb a böngészős oldalon kezdeni. Plusz nagyon sok alapelv (izometrikus ábrázolás, stb) ott is érvényes és nem fogsz nekiállni nulláról game enginet írni. ha mobilra akarsz fejleszteni, akkor egyértelmű, hogy megpróbálsz egy mobilost keresni. Szerintem.

--
Pásztor János
Üzemeltető Macik

"TBH ez igy ebben a formaban nem igaz."

Ez ebben a formában igaz... felsoroltál pár kivételt...

Az agar.io például egy technológiai demonstrációnak indult, ami függővé tett embereket, a rettenetesen sok farmos játék pedig mind évekkel ezelőtt indult... mondj példát idei webes játékról, ami akkora siker, mint mondjuk a Clash of Clans, amin szintén mobilra jött ki először több mint két éve... :)

Egyébként is mindegyiknek mobilon jön a bevétel döntő többsége, amelyiknek van web is, az másodlagos. Ez van.

"es az erdeklodes novekedese triggerelte a mobilos alkalmazas megszuleteset"

...évekkel ezelőtt igen. Egy-két éve megfordult... aki nem kövek alatt él, az látja. Tényleg nézz már körül, hogy a casual játékok többsége milyen platformon jelenik meg először. :/

"Az az ember, aki az irodaban szamitogepen dolgozik, marpedig manapsag a legtobb ember ilyen, nem fog mobilt elovenni azert, hogy elusse az idot, raadasul a bongeszos jatekot konnyebb is hatterbe rakni, ha jon a fonok, mint egy mobilos alkalmazast."

Hát pedig de, mert irodában erősen tiltják a játékokat a tűzfalon, ezért mindenki mobilon tolja... :)

"Rettenetesen sok jo bongeszos, vagy bongeszore is elerheto jatek van, amivel emberek szazezrei jatszanak."

Nem mondtam azt, hogy nincs. Azt mondtam, hogy ha most nem mobilra hozod ki először, akkor halott a dolog. Tekintsünk már el a véletlenül összehozott játékoktól, azok üdítő kivételek és a rettenetesen sok böngészős játék is évekkel ezelőtti.

"Szoval nem, a valos dontesed az, hogy bongeszo first vagy mobil first. Azutan lehet donteni minden masrol."

http://prezi.javaforum.hu/gacivs-startup/images/prezi/gacivs-unique-vis…

Tavaly október 12-én került ki a Play-re a játék, előtte fél évig volt csak webes felület. Meggyőztél, nem volt jó a mobil first döntés, csak azt nem értem, miért jön kb. ötvenszer annyi felhasználó a mobilra, mint a webre... azt sem értem, hogy a Supercell miért volt olyan hülye, hogy iOS-ra adta ki először a Clash of Clans-t, amikor webre is kiadhatta volna... milliárdokat kereshettek volna, a jelenlegi milliókkal szemben... mindegy, hagyjuk, egyszerűen jobban tudod.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

En elhiszem neked, hogy jateknal mobilra kell kijonni eloszor,
es mobilon kulonbseget lehet tenni egy bongeszobe agyazott jatek es egy nativ jatek kozott.

Viszont szerintem ez nem all ok-okozati viszonyban a szerveroldallal.

Elolvastam a gacivs-startup -os prezentaciodat, igazabol az oldalad egy informacios aranybanya:)
(btw, a youtube-os link benne nem mukodik, raadasul nekem missing plugin-t irt ki, forrasban kellett megnezni, hogy mi az, de a youtube-os link se megy:)

Azt is elhiszem, hoyg szamodra a cassandra, wildfly es a java volt a legkenyelmesebb.

De szerintem mas technologiakkal is ossze lehet hozni egy clusteres mukodo rendszert.

Mondjuk engem a jatekok abszolut nem foglalkoztatnak,
igy valoszinu gyakorlatban nem tudlak cafolni, amit en irok,
az meg szerintem bongeszoben eleg, hoyg fusson.

Egy kerdest feltennek neked privatban, ha lehet:)

Szerk: Ezen az oldalon: https://test.gacivs.info/frontend/
Ugy nez ki jobb oldalon, mintha fizetos lenne a jatek (15$-t ir ki)
Ugyan Indigogo kampanyra mutat, szerintem jobban kellene prezentalni.
Pl igy: http://udoo.org/
"Support Gacivs on Indigogo [Back us now! ]"
Es a gomb (Back us now!) egyben lehetne egy progressbar is.

De ez csak egy 5let, nem vagyok marketinges.

Szerk2: Ez nem megy: https://portal.gacivs.info/
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"Viszont szerintem ez nem all ok-okozati viszonyban a szerveroldallal."

Akkor van ok-okozati viszonyban, ha egy fős a "cég".

"btw, a youtube-os link benne nem mukodik, raadasul nekem missing plugin-t irt ki, forrasban kellett megnezni, hogy mi az, de a youtube-os link se megy"

Ahja, közben töröltem azt a Youtube videót és lett újabb, csak ebben nem cseréltem ki, felírom a todo listára... :)

"Azt is elhiszem, hoyg szamodra a cassandra, wildfly es a java volt a legkenyelmesebb. De szerintem mas technologiakkal is ossze lehet hozni egy clusteres mukodo rendszert."

Igen, lehet. A hangsúly azon van, hogy ha Android first a játék, akkor a Java adja magát szerver oldalra. Ha nem Android first, akkor mindegy, mi van a szerver oldalon. Egy fős "cég" esetén.

"De ez csak egy 5let, nem vagyok marketinges."

Indiegogo csak úgy ott van, de nemsokára leszedem.

"Szerk2: Ez nem megy: https://portal.gacivs.info/"

Jah, tudom, van metrikám, kb. két napja nem megy, a Vultr a VENOM frissítést tolta ki a gépeire és a portál alatti VPS előtte is beteg volt, most is az, még nem javítottam meg, mert éppen egy másik munka közepén vagyok, de majd holnap megoldom a portált is. One man show. :)

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Hát pedig de, mert irodában erősen tiltják a játékokat a tűzfalon, ezért mindenki mobilon tolja... :)"

A virusszeruen szaporodo oldalakat tekintve ezeknek a gyakorlatoknak inkabb csak jelzeserteku jelentosege van, a legtobb ilyen tiltast anyam ki tudna kerulni, pedig o aztan messzebb van az IT-tol mint en a kotes-horgolastol.

"Tényleg nézz már körül, hogy a casual játékok többsége milyen platformon jelenik meg először. :/"

PC-n meg Facebookon. Legalabbis, a flashes-HTML5-os jatekdomping szinte folyamatos, szazaval jelennek meg, mas kerdes, hogy ezek nem igenyesebbek a kinai tamagocsiknal, amik ettek meg aludtak, de attol meg jonnek. Jon jopar mobilra is, nem mondom, hogy ezek nem nepszeruek, de egyszeruen ketlem, hogy ez lenne a tobbseg, foleg annak fenyeben, hogy ahogy irtad, azert mobilra nem egyszeru jo teljesitmenyt ado, jo grafikaju jatekot csinalni. Marpedig ha valamibe tudast kell tenni, akkor azt nem lehet futoszalagon fosni.

Gacivs... en megertem, hogy te csak ezt ismered, de ettol meg nem lesz hitelesebb. Honnan a tetubol tudjam, hogy a _te_ jatekod miert nem lett sikeres? Talan nem hirdetted elegge, talan a mobilos megjelenessel jobb lett a jatekelmeny is, ki tudja. Attol, hogy _neked_ ez a tapasztalatod, egyszeruen merezz kovetkeztetes azt mondani, hogy akkor a vilag igy mukodik. Azert, mert szedulok, meg nem korulottem forog a vilag.
--
Blog | @hron84
Üzemeltető macik

"PC-n meg Facebookon."

Igen, vannak kis számosságú példák, ahol csak PC-re és Facebook-ra jön ki a játék. A trend viszont a mobile first. Ha tetszik, ha nem. Ha elhiszed, ha nem. Próbálj már legalább értekezni más játékfejlesztőkkel vagy mérd ki, én megtettem mindkettőt.

"foleg annak fenyeben, hogy ahogy irtad, azert mobilra nem egyszeru jo teljesitmenyt ado, jo grafikaju jatekot csinalni"

HTML5 alapokon nehéz. A végtelen számú OpenGL keretrendszerrel könnyű. Tényleg nem érted vagy nem akarod érteni?

"Gacivs... en megertem, hogy te csak ezt ismered, de ettol meg nem lesz hitelesebb."

Nem csak ezt ismerem... de annyival többet tudok Nálad, hogy nekem legalább van élesben két játékom is, amivel több százan játszanak és több ezren kipróbálták... :)

"Honnan a tetubol tudjam, hogy a _te_ jatekod miert nem lett sikeres?"

Leírtam egy csomó helyen: mert még nincs kész és tervezetten tartom alacsonyan a játékosok számát, hogy a support és operation feladatok helyett a development legyen a hangsúlyos, mert kevés időm van és azt hatékonyan szeretném eltölteni. Másrészt én sikernek tudom értékelni, hogy egy félkésznek se mondható játékkal is játszanak és követelik a fejlesztést:

'This app is in development. It's still fun to play and see it change, give feed back etc. If you are new to it be patient as it is still in development. Have fun playing.'
'I wonder why no one made many handheld MMOs before. Because this is great! It really reminds me of the PC classics, only now in the palm of my hand.'
'Hmm... I'm getting a good feeling that this game will soon be successful... Please keep updating it, don't just abandon it. I really like this kind of games... Don't let us down ;)'
'Dear developers add the application Russian language is very interesting application.'

Nem sikeres? :)

"Azert, mert szedulok, meg nem korulottem forog a vilag."

Ezen gondolkodj el Te is.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Ezen gondolkodj el Te is.

most komolyan ezt varod hrgy84-tol? :-) En amugy elvezem a vitatokat: amikor hrgy84 a fogalmatlankodasaval megcsinalja a napomat, az priceless.

--
"Tudom én hogy nem biztonságos, de le van szarva az egész [...] A WoW jelszavam maradjon titokban csak az a lényeg!" (BlinTux)

"Nem webről van szó"

Sztem a Webtudor nevű csatornán eléggé a webről van szó. :) Mi webbel foglalkozunk, ehhez értünk. Ha valakinek van mobilfejlesztési csatornája / blogja, én leszek az első, aki ajánlani fogja, mert ahhoz nem értek, nem tudok róla videót csinálni.

--
Pásztor János
Üzemeltető Macik

( lzrd | 2015. 05. 15., p – 20:09 )

IMHO yó!
--
unix -- több, mint kód. filozófia.
Life is feudal