nemec

Kas par murgu ar tiem cipariem? Pastāstiet tad kā tiek plānots uzņēmuma budžets? Normālajā gadījumā uzņēmums iedala amatam 500Ls (piemēram) un meklē pretendentu, nevis otrādi. Ja uzņēmumus plāno kaut kā savādāk, tad jau pirmā pazīme, ka kaut kas notiek nepareizi :)

Ja vēlies pārdod, tad jāsaliek mazliet vairāk par lapu: statistika (apmeklējums, pievienotās atsauksmes utt), kas par platformu (php, mysql utt), biznesa plāns (ja ir protams :)), biznesa plāna stadija (kas šobrīd tiek veikts - mārketings utt), ienākumi. Varbūt vēl kaut kas.

Pateikšu par sevi, es pilnīgi noteikti ignorēšu sludinājumu, kur nav norādīts atalgojums. Jau sanāk kādi 80% sludinājumi. Ja es nepazīstu uzņēmumu un nevaru ar to sīki iepazīties internetā, arī ignorēšu. Kopumā sanāk normāli sludinājumi ap 5%, kuri mani pašu interesēs un pie reizes arī ieteikšu iepazīties darbabrāļiem.Programmētāja meklētājam būtu no sākuma jāiegaumē viens fakts - ir jāprot rakstīt sludinājumu vai/un meklēt kolēģus. Ir arī cita monētas puse, kāds grib atrast labu darbinieku pa lēto, izmantot utt. Tieši pēdējā iemesla dēļ, daži nevēlas atsaukties uz diezgan apšaubāmiem sludinājumiem.

Neesmu liels geimeris, bet jau ilgu laiku sekoju šim projektam vai drīzāk spēlei. Sākumā viņiem tas izskatījās vairāk par demonstrēšanas spēli, lai pacelt popularitāti savam 3d engine. Pati spēle man ne īpaši patīk, tāpēc nepiekrītu, ka ir ideja. Protams var salīdzināt ar webGl, bet tas ir pavisam cits līmenis, tas ir flash, kas iespējams drīz mirs :)

Atradi?

headris man ir augšā noformēts ar css (position:absolute). Tikai htmlā tas atrodas pēc satura. Protams tā nav nekāda problēma, bet mazi ieguvumi ir, tāpēc arī lietoju.

Pirms gudroties pamēģini pats iestartēt vismaz ar kaut ko. Es pats esmu startējis jau vairākas reizes. Dažreiz veiksmīgi, dažreiz vispār neveiksmīgi. Bet kopumā krājas pieredze, zināšanas. Man pat grūti izstāstīt cilvēkam, kas ar šo nav saskāries, cik ir forši, kad Tavs projekts tiek kaut kādos apskates portālos un lapas skaitītājs vienkārši uzsprāgst. Tāpat kā šis spēles autors, arī ir gadījies saplānot nepareizi vai netrāpīt savai īstai auditorijai. Un tāpēc man prieks, ka Latvijā parādās cilvēki, kas kaut taisa un mēģina iestartēt. Diemžēl mūsu valstī nav īpaši attīstītas inovācijas un investori.

Piemēram es formēju tā: <div id="wrap"> <div id="content"></div> <div id="header"></div> <div id="footer"></div> </div> Jo man patīk, ka lietotājs saņem pirmo saturu, nevis kaut kādus headerus vai navigāciju. Un meklētājam arī tas ir mazliet draudzīgāk.

piemēram #_(adrese)&=(scroll position) Tātad es varu pieglabāt ne tikai adresi, bet arī piemēram scrolla pozīciju. Tas ir tāds parasts piemērs, var tur glabāt protams jebko. Ja ir interese, tad var papētīt mootools pluginu historymanager

Tāpēc, ka tajā anchorā var glabāt vairākus mainīgos piemēram _(.+) ir adrese, vēl vari piekabināt kaut kādus mainīgos (kam citam, nevis adresei)

Jā, tā tas ir. Novācu šo arī, bet cita iemesla deļ. Lietotāji bieži pārsūta saites, un tava dotā ir tieši tas nesmuks piemērs. Bet no navigācijas viedokļa nekas nemainās.

Nevienam browser funkcionalitāti atņemt nevēlējos :) Biju piemirsis, ka ctrl+click ir arī jauns tabs, tāpēc tas jau ir labots. Kavacky laikam skatījās caur chrome, tur arī izlaboju vidējo pogu. Vēlams turpmāk pievienot pārlūku+OS, lai var operatīvi konstatēt kļūdas. Par tām metodēm ar jaunu tabu (vidējo pogu, ctrl+click), var arī pārmest pārlūkam (nevis man :)). Piemēram FF, uz vidēja clicka, JS vispār nestrādā, jo tiek izsaukta browser fukcionalitāte - jaunas tabs. Dīvaini ir ka uz ctrl+click tiek izsaukts javascripts, un tikai tad nostrādā browser funkcionalitāte. Ar chrome viss iet caur JS. Un piemēram tādam pārlūkam kā Opera, nav tāda ctrl+click - jaunais tabs. Katrs pārlūks darbojas pa savam, to gribēju teikt :) Paldies par kļūdām!

Es nemaz neiespringstu uz datu apjoma. Šeit vairāk jau darbojas loģika, kāpēc man ir jāparsē šablons uz servera, ja to var darīt uz klienta pārlūka. Man patīk atslogot serveri, pie tam tik elegantā veidā. Priekš kam, tad tantes pērk tos dual core :) Nu un protams, loģiski, ja lietotājs salādē šablonus un tikai tad staigā pa lapu, saņemot tikai nepieciešamos datus.

Back poga nebūtu tā lēnā. Ja attaisa firebug, tad var redzēt, ka atbilde atnāk ~ 0.1sek. Problēma ir lielu datu parsēšanā iekš JavaScript šablonizatora. Gandrīz katrā lapā tiek parsēts viens šablons priekš 10 foto, tur arī rodas tā aizture. Šeit vienkārši vajag optimizēt JavaScript daļu :)

Pavisam nesen saražoju ielu modes lapu. Varbūt saturs nebūs jums interesants :). Bet ceru, ka interesēs izstrāde. Tātad lapa pilnībā darbojas uz ajax pieprasījumiem. Ja uzspiežam uz kādas saites, tad ar javascriptu tiek nolasīts href atribūts, pielikts klāt ?j parametrs (kas nozīmē, ka tiek pieprasīti json dati). Tātad piemēram http://stylewish.lv/55-casual/?j , šeit var redzēt saturu, kur ir "template" (šablons), un "context" (atbild par šablona aizpildīšanu ar datiem). Pēc šī pieprasījuma <div id="dyn-cont"></div> blokā tiek ievietots jauns šablons ar apstrādātu saturu. Šabloni priekš javascripta izskatās sekojoši http://stylewish.lv/design/js/d/template.js. Viss būtu vienkārši, bet tieši tāds pats šablonizators strādā arī iekš PHP (servera pusē). Ja es uztaisu jaunu šablonu un aizpildu to ar kaut kādiem datiem, tad man tas ir jādara vienā vietā (bet strādās AJAX versijā un parastajā). Tādai pieejai ir vairākas priekšrocības: 1) Ja lietotājam ir JS atbalsts, tad tiek dzenāti ļoti maz datu (ja pamanījāt, tad nav html tagu). Šabloni tiek apstrādāti ar JavaScript - tātad lietotāja resursi. 2) Tas pilnībā neskar lietotājus bez JS atbalsta. 3) Izstrāde notiek, kā parasti tikai PHP pusē. Tā kā dati tiek dzenāti caur javascriptu. Tad pastāv arī iespējas kešot datus iekš javascripta. Forši vai nē? :) Atšķirībā no kešošanas uz servera, tad klienta pusē nav vajadzīgi lieki pieprasījumi (dārgais laiks), dati ir uzreiz gatavi. Protams pastāv jautājums cik daudz lietotājs spiež uz vienas un tās pašas saites, ja šis skaitlis ir mazs, tad no tādas kešošanas dižas jēgas nebūs. Ja runājot par pašu template engine, tad tas darbojas līdzīgi http://beebole.com/pure/. Manā versijā ir viss daudz vienkāršāks js (mootools plugins)

Man apmēram izstrāde notiek sekojoši: 1. posms Ideja. Apdomāju, ja nekas nemainās 1-2 nedēļas laikā (relatīvi protams), tad pāreju pie nākošā posma vai palieku te pat un turu tālāk prātā :) Ideju ir daudz visiem, tāpēc nevajag ciklēties uz vienas; 2. posms Konkurenti, Tirgus statuss, Potenciāli klienti, Monetizācija, Perspektīvas. Te var arī viss beigties, bet var arī turpināties; 3. posms Tehnoloģijas. Tehnoloģiju izvērtēšana, iespējama pielietošana. 4. posms Prototipēšana. Mazus prototipus, lai patestēt izvēlētās tehnoloģijas. Te arī var viss beigties. 5. posms Plānošana. Šis ir visgarākais posms. Parasti mēģinu visu vienkāršot, neliekot klāt liekas lietas. Šajā posmā jau sāku mest uz papīra un pārdomāt aplikācijas struktūru un darbības. Ir noteikti jāparedz aplikācijas attīstība turpmāk, lai nevajadzētu beigās atgriezties uz šo posmu, jo tas varbūt ļoti sāpīgi. Tiek sastādīts arī timeline, man tā ir vieglāk, pat ja kavē visus termiņus, timeline noteikti ir jābūt. 6. posms Dizains. Tā varbūt mysql struktūra. Lietotāju interfeiss utt. Aplikācija iegūst jau vizuālu izskatu. 7. posms Izstrāde. Liekam visu kopā - prototipi, plānošana un dizaini. 8. posms Testi. Testējam ar draugiem kopā. Meklējam pieļautās kļūdas 5., 6., 7. posmā. Atgriežamies pie 5. posma un vēlreiz izejam līdz 8. posmam (izvērtējot pieredzi 8. posmā), kamēr aplikāciju varēs laist tautās. 9. posms implementācija. Nu te varbūt visādi mārketinga posmi. Kaut vai tajā pašā php.lv/f/ mājas lapu novērtēšana utt.

Man liekas mēs nesaprotamies. Tātad serveri nr. 1, es biju domājis apmēram tādu http://www.code2design.com/forums/php_xml_socket_server . Kas atbild par ielogošanos, par istabām utt. Bet serveri nr.2 biju domājis pašu spēli, kas tieši tādā pašā lūpā (kā socket servera gadījumā) tikai rēķina spēles karti. Ja spēle ir klients. Tad palaižam serveri nr. 1, un tad serveri nr. 2, kas pieslēdzas serverim nr. 1. Serveris nr. 2 paliek ciklā un rēķina kartes darbības (tobiš spēli) un komunicē ar serveri nr. 1 vajadzības gadījumā. 2. variants būtu apvienot serveri nr.1 un serveri nr.2. Tad sanāk, ka kartes pārbaudi jāiebāž kaut kur arī tajā pašā ciklā. Vai tā tu biji domājis?

pagaidām nē, nav tur vienkārši piereģistrēties. īsti nesapratu. Tu domā taisīt pašu spēli stand-alone? Es domāju veidot atsevišķi spēles skriptu un pašu servera skriptu (serveris būtībā arī sanāk, ka ir mūžīgs cikls, kas pārbauda vai no lietotājiem nav kas atnācis). Tieši šī iemesla dēļ, sanāk ka jābūt diviem mūžīgiem cikliem. Vai arī jāskatās man uz multiprocessingu labāk? Vēl iedomājos, ka spēle varētu būt kā klients, kas padod serverim komandas vai saņem. Man tomēr patīk savādāks modelis: lietotājs nospiež komandu (piemēram uz augšu), sūtam uz serveri, serveris visiem klientiem sūta ka lietotājs kustās (uz augšu), serveris (pēc 10sek) sūta, ka lietotājs apstājies pie sienas (var ar koordinātēm, lai izlīdzināt kartes izskatu). Sanāk diezgan mazs trafiks un tur nav par ko uztraukties. Zoles gadījumā, kaut kāda aktivitāte notiek tikai tad, ja kāds izdara kādas kustības (gājienu). Ja neviens neko nedara, tad serveris arī neko nedara un nerēķina. Bet manā gadījumā serverim ir visu laiku jārēķina. Var protams raustīt serveri, bet manuprāt tas ir perversi :)

1. pagājušā gada beigās šī problēma tika atrisināta ar websocketiem. Ja ir vēlme var izmantot flash tuneli priekš pārējiem "moderniem" pārlūkiem. 2. to sauc par cometu, šo tehnoloģiju nav vērts izmantot, izejot no 1. punkta Pastāstīšu vairāk. Tātad klienta pusē man ir <canvas>, kas atbild par kartes attēlošanu (pašas spēles). Klients slēdzas serverim caur websocketiem (twisted jau ir tāds modulis, kas nevar nepriecināt :)) vai flash tunelis, bet tas neko daudz nemaina. Šeit problēmu lielu nav. Sūtam komandas uz serveri. Saņemam komandas no servera un attēlojam rezultātu. Serveris klausās komandas un rīkojas. Ja salīdzina ar zoli, tad tur bija soļu spēle. Lietotājs izdara gājienu, serveris izskaitļo un nosūta atbildi. Šajā gadījumā arī viss diez gan vienkārši. Bet ja ir action spēle. Lietotājs nosūta komandu kustēties, tad pēc kāda laika (piemēram 10 sek) viņš var atdurties sienā un viņu ir jāapstādina. Serveris šajā gadījumā nevar momentā izskaitļot un atbildēt, tad ir jāatbild pēc 10 sekundēm (ja nekas nemainās protams). Karte tiek apstrādāta uz servera, tāpēc to ir visu laiku jālaiž pārbaudēs un nebeidzamos ciklos (while). Tāpēc jautāju, kā to labāk realizēt? Interesē kāda pieredze ir citiem, kas taisa multiplayer spēlītes? Pagaidām esmu apstājies pie viena varianta. Tātad jātaisa divi serveri. 1. ir parasts, kas atbild par lietotājiem - ielogošana, istabā ielogošana utt (tur kur nav vajadzīgs cikls). 2. serveris ir pati spēle. Tātad 1. serveris nosūta komandu 'uztaisīt karti'. Tad tiek uztaisīta karte, tiek palaists cikls (while) un pārbauda kas tur notiek, sanāk, ka atbild par pašu karti un tur notiekošo. 2. serveris sūta 1. serverim komandas, piemēram lietotājs 1 ir atduries pret sienu utt. Lietotājs komunicē tikai ar 1. serveri, tad 1. serveris pēc vajadzībām pieprasa datus 2. serverim un arī saņem kādus datus par kartes stāvokli no 2. servera.

Man ir viens serveris, kas saņem komandas no lietotājiem (ieiet serverī, ielogojas, ieiet kādā istabā). Viss ir ok līdz šim brīžam. Spēle ir action, tas ir notiek kustības un darbības nepārtraukti. Lietotājs nosūta komandu, ka viņš kustās pa kreisi. Tad man šis te jāpārbauda un jāaizsūta viņam atpakaļ apstiprinājums (nu un protams visiem pārējiem istabas biedriem). Pēc kāda laika lietotājs var atdurties sienā, tātad serverim šis te ir jāizskaitļo un visiem jānosūta, ka šis lietotājs jāapstādina pie sienas. Tā principā notiek visa spēle. Sanāk, ka visu karti izskaitļo uz servera, lietotāji tikai sūta komandas - pa labi, pa kreisi, šaut utt. Serveris visu koordinē! Tad sanāk, ka man servera pusē jātaisa lūps (while), kas visu laiku pārbauda vai kāds kustīgs objekts jau ir pietuvinājies sienai (tas ir piemēram). Kādi ir varianti tādu realizēt? Ja par pamatu ņemam python twisted.

droši vien kāds ir iegājis un atstājis pārlūku vaļā. Ņemšu vērā un pielikšu pogu izmest neaktīvu lietotāju. Uz ie8 un ie7 arī vajadzētu strādāt, bet 100% galvot nevaru. Tiklīdz būs pa rokai ietestēšu tā kārtīgi.

mefisto es jau biju vienreiz teicis, ka position:absolute neatjaunojas uz dinamiskā satura iekš IE6. Ielādē savu lapu, un tad ar javascript sabāz saturu lielāku (ar kādu pogu), uz IE6 footer paliks tur, kur bija lapas ielādē.

var arī iztikt bez lieka elementa <div style="width:100%;overflow:hidden;"> <div style="float:left;"> kreisais </div> <div style="float:right;"> labais </div> </div>

<div style="min-height:100%"> super saturs </div> <div style="margin-top:-200px;height:200px"> super pisiets apakšā </div>

Nepagāja pusgads, kā termi ir saražojis mini versiju zole. Pati spēle atrodas šeit. Pēc ielogošanas lietotāju automātiski iemet brīvajā istabā. Zolei ir mazliet specifiski noteikumi, tāpēc pirms spēles iesaku iepazīties. Zole ir rakstīta javascriptā. Komunikācijai ar serveri tiek izmantots tas pats tunelis (par ko stāstīju iepriekšējā topikā). Serveris ir rakstīts uz PHP (visiem JAVA faniem varu teikt, ka PHP forši strādā un rij ļoti maz resursu). Statistika nekāda netiek vākta un pat mysql netiek darbināts. Zoles variantā (vai arī citai kāršu spēlei) ir diezgan maz datu jāpārsūta, tāpēc ja visu normāli sakodēt, tad tāds serveris var turēt nu ļoti daudz klientu. Izstrādes laiks protams ir daudz mazāks par pusgadu, varētu būt ap +/- 2 nedēļām (ja skaita darbadienās). Pagaidām tā nav produkta versija, bet iepazīšanai es domāju pietiks, lai var redzēt ka var arī ar Javascriptu foršas lietas taisīt. Izstrādes laiks bija tik tiešām interesants un iedvesmojošs. Kaut kad nākotnē ir doma uzblenzt kādu multyplayer battlecity (vai kādu līdzīgu spēli) uz javascripta.