gurkjis

Iespējamie iemesli, kāpēc vajag citā tabulā glabāt: * liela, universāla sistēma * ļoti daudz autentifikācijas mehānismu bet jā, parastai lapai/portālam nav vajadzības sarežģīt lietas. Pats sev cilpu liec ap kaklu.

Tai lapā, kur ir bilde, tur Tu esi ietērpies treniņtērpā ? Izskatās aizdomīgi. Bet profila avatars jau nedaudz nomierina.

dziļāk nemācēšu paskaidrot, bet uzmetot aci kodam, redzu, ka Tu variables izmanto bez dolāra zīmes.... varbūt tur tā problēma ? Bet man liekas,ka tad jāmetas PHP erroriem, ja šādi centies izmantot.

Parasti domēna īpašniekam palūdzu, lai nomaina nameserverus, un tas arī viss. Bet labi, man varbūt nav tik raiba pieredze ar šīm lietām. Ja vienkārši darbojas es vairāk neko necenšos tur filozofēt. Manā izpratnē savs nameserver izklausās pēc izvirtības.

Neredzu neko sarežģītu DNS ierakstu pārvaldē caur DO paneli. Kur vēl vienkāršāk var būt ?

subdomēniem liec CNAME ierakstus (caur DO DNS sadaļu) mail serverim vajag MX ierakstus https://www.digitalocean.com/community/articles/how-to-set-up-a-host-name-with-digitalocean#mx-record

https://bitbucket.org/ - pilnībā apmierina, neesmu citus skatījies. Privātos lieku uz bitbucket, bet publiskos uz github.

Nu es aizdomājos par tēmu globālie variabļi (ne-OOP) vs OOP pieeja un izklāstīju, kā to redzu. Tas ir - globālie variabļi ir pieejami analoģiski OOP praksē, kad lietojam singletonus, bet tie nav slikti dēļ tā,ka ir globāli pieejami, bet gan tāpēc, ka tiek sagāzti vienā čupā. Varbūt kādam var noderēt šāda info. Citādi ir buzz par to, ka ir globals ir slikti, a kāpēc tieši, tas var arī uzreiz nebūt skaidrs.... Ar to es arī apgalvoju, ka DAŽI globālie variabļi nav nekas slikts, piemēram, ja turi DB handleri.... Nekas reāli slikts nenotiks, ja Tev tagad nelielā sistēmā būs globāls DB handleris.. Tādas radīsies, kad sistēma paliktu liela, sastāvot no daudziem moduļiem, kas katrs kaut ko gāzīs iekš global namespace.

OOP gadījumā global variabļa analoģija ir - statisks lauks konkrētai klasei. Kas tad īsti izmainās ? Globālā pieejamība tiek saglabāta, tikai OOP variantā ir ļoti konkrēta, hierarhiska, sakārtota kokveida struktūra, kur kas glabājas. Namespace -> Class -> static variable. Tieši tas pats ir ar funkcijām. globālās funkcijas = OOP gadījumā statiskās metodes klasei. Parastajā gadījumā tas global var sliktums ir tajā, ka nav īsti kārtības, kur kas glabājas - ir viens global namespace ar čupu mainigajiem no visas aplikācijas, kas arī pie lielākām sistēmām rada haosu. Iesviežot konkrētā klasē, mums ir zināms konkrēts konteksts, kas pilda grupēšanas funkciju, kā rezultātā ir vieglāk atrast un sakārtot lietas sistēmā. Namespaces un klases ir tā kā mapītes priekš koda organizēšanas, bet protams, ļoti noderīga fīča ir vairāku objektu instanču veidošana, bet ne jau vienmēr tas ir vajadzīgs - var iztikt ar singletonu, kur nav nepieciešamības pēc multiple instances. Kompleksu lietu kaudzi vienmēr var izdalīt loģiskā hierarhijā, tā pat ir ļoti veselīga prakse. Ja ļoti gribas, hierarhisku koda organizāciju var izspiest arī bez OOP, bet nu ... tā būtu hakošana, nevis pareizo rīku izmantošana.

nepārprotami, detektē pievienošanas ātrumu un apjomu, balstoties uz statistiku par to, kā dara parasti lietotāji. Ja neatbilst vidējam lietotājam, radi ierobežojumus, piemēram, "preci varēsiet pievienot pēc 30 sek"

Es gan nelabprāt ar tiem darbojos, man gar acīm raibs metas, kad uz regexiem skatos - asociējas ar mašīnkoda lasīšanu. Parasto kodu ir vieglāk saprast - tur Tev ir vārdi un ar katru vārdu uzreiz ir konkrēta asociācija, kā arī struktūra ir pārskatāma. Nu jā, var iekalt, ko katrs simbols nozīmē, bet vienalga tas ir brutāli pret high-level nemazohistisku programmētāju. Tikko iedomājos, ka varbūt ir kāda abstraktēta programmēšanas valoda, kas kompilē uz regexiem... Bet savu uzdevumu jau pilda tie.

Tas gan tiesa - par to, ka rodas arvien jauni TLD.

JS mainīgos padod ar JSON. Padod skriptam vienu objektu, kurā ir pilnīgi visi frontendam nepieciešamie mainīgie, un miers. Un taisi kā ērtāk, nevis kā optimālāk no performances viedokļa, jo priekšlaicīga optimizācija ir dirty ļaunums. Tev vajag pēc iespējas vairāk darbojošos rezultātus dabūt, nav svarīgi, kā tas apakšā darbojas. Dators ir Tava k*ce, no kuras ir jāizspiež labums, nevis otrādi, ka Tev viņam ir jāizpatīk, noņemot slodzi. Tev ārējs rezultāts ir - tātad darbs ir padarīts. Ja projektā paliek brīvs laiks vai garlaicīgi, var vienkāršotos risinājumus sākt optimizēt. Vai arī - ja ir apzināti bottlenecki un tie rada reālu problēmu projekta darbībā. Es pats cenšos pa vidu balansēt, par optimizāciju domāju jau pirmajā koda versijā, bet tikai tik daudz, lai man par to nav baigi daudz jāaizdomājas. Citreiz sākumā izdomāju "kruto" risinājuma versiju, bet tad ieraugu vienkāršāku versiju, un ja es to uztaisītu, tad ātrāk varēšu par šo problēmu aizmirst un jau nākamo ņemt priekšā. Ar pieredzi nāk arvien lielāka spēja optimizēt, daudz nedomājot.

Nu tur nav nekādu citu variantu, kā plaintextā nomatchot patternu "domens.tld" - tas ir - 2 teksta segmenti, kur pa vidu ir punkts , jo arī parastā tekstā šādi patterni var gadīties, kas reali nav domāti domēni. Tāpēc vajag TLD sarakstu, lai vismaz zināmos TLD šādi nomatchotu.

Nu labāk, lai ieliek, ka pa ofisu lidinās vairākas jaunas sekretāres, tad varētu jau apsvērt iespējamību. Bet nu tā jau tikai ekstra. Ekstras nav pamatfaktors, pēc kā izvēlēties darba vietu, skatamies jau visu lietu kopsummu.

Tā ir Tevis paša custom sistēma, kurai to vajag ? Saprotu, pārtaisīt varbūt būtu apjomīgs darbs, bet es nekad, nekad nečakarējos ar htaccess rulēm, vnk paņemu vienu nemainīgu htaccess failu, kurš nodod kontroli uz PHP skriptu, un PHP skripts pats analizē padoto adresi un dara ko vien vajag... Var lietot Wordpress variantu http://codex.wordpress.org/htaccess Man šāds ir http://pastebin.com/wHvaHUN4 PHP iegūst URL ceļu: <?php $path = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH); var_dump($path);

Vai tad kādreiz nebija vēl ekstrēmāk pie datorekrāniem, kad CRT monitori bija aktuāli ? Salīdzinoši, LCD ir nekaitīgi un maigi acīm.

Nē nu es skaidri zinu, ko vēl gribu izdarīt, lai ir absolūtais minimums, ar ko esmu apmierināts pats.

yup ideja, protams, laba, bet es tak pats zinu, ka tur pilns ar lietām ko varētu vēl slīpēt. Es tā strādāju, ievelku quick'n'dirty skici, ka tikai konkrēta ideja vienkāršotā veidā strādā un tad, ar nākamajām iterācijām pievelku detaļas / izskaistinu. Tur vēl daudz darba. Bet jā, šajā forumā noteikti ielikšu kaut kad, tas ir pilnīgi skaidrs.

Es jau rakstīju, ka fworkam paredzēts saits ar tutoriāļiem un dokumentāciju. Protams, sākotnējiem projektiem varu nepublisku dokumentāciju līdzi iedot. Cik gan bieži realitātē klienta projekts Tev ir jāapdeito ? Procentuāli, cik gadījumos ? Ne jau visi. Web lapām parasti ir tā, ka uztaisa re-dizainu pēc kāda laika. Un bieži klientiem neinteresē, kas tur par tehnisko risinājumu ir apakšā - viņiem interesē kā izskatās UI. Jauniņais programmētājs var ielikt arī PHP spageti kodu ar labu dizainu un visi būtu laimīgi.

Ok bet tad jau sanāk tā, ka es pusi no piedāvātas standarta funkcionalitātes neizmantoju, bet pierakstu klāt, beigās bloats baigais ? Bet nu labi tas ir tā - piekasišanās. Katram jau savs. Tās lietas, ko aprakstīju piem. navigācija - domāju,ka tam ir jābūt standartā un bez nekādas konfigošanas, kopā ar frameworku automātiski lai darbojas. Vēl nevienu reālu saitu uz citām platformām neesmu kompilējis - tas viss jātestē, bet cik patestēju - PHP targets darbojas. Performance gan jāsalīdzina. Izskatās, ka PHP neatbalsta in-memory objektu kešu. APC grib serializēt kā stringu. Žēl. Bet nu socket servera gadījumā varēs arī in-memory kešot objektus. Bet memcached papildinājums neatbalsta kompleksus PHP objektus - tikai simple vērtības, t.i. stringus, integerus, tātad objekti arī būtu jāserializē. Pati valodas sintakse ir līdzīga Javascript, tā kā piešauties nebūtu problēmu. Haxe komūna lēnām, bet aug. Man pat ir doma uztaisīt online Haxe IDE, kur tu piereģistrē kontu un turpat browserī jau kodē augšā savu saitu, lai jauniņajiem nav visi tie scary svešu sistēmu instalācijas procesi "jābauda". Par templeitu valodu - ja gribi palikt pie PHP, tad Tavs ieteikums strādā. Es dodu cilvēkiem iespēju tikt prom no PHP - tie kuri grib. Nav tur overheads, jo noparsētais templeits glabājas in-memory kešā kā gatavs, lietojams objekts. Re-parse tikai pie faila modifikācijām. Bet performances es testēšu vēl.

Nu man ir kaudze ar idejām, kuras nezin kādēļ nav citos frameworkos, un tā mana izpratne, kā lietām vajadzētu būt, ir tāda nu tiešām nestandarta. Daļu tās esmu aizguvis no custom sistēmām, pie kurām esmu strādājis, taču OSS frameworkos neredzu. Pamatideja - automatizēt uzdevumus, kuri ikdienā bieži jādara ar roku - labāk lai tos dara sistēma! Datoriem ir jākalpo cilvēkiem, nevis otrādi. Piemēram, kas man liekas absolute MUST have, bet frameworkos tāda fīča nav iebūvēta (ja nu vienīgi ar kādu pluginu): CSS un JS failu inkludošana un dependenciju pārvaldīšana. Kāpēc man ar roku jāiet uz templeitu, kur atrodas HEAD tags, un jāliek manuāli iekšā? Un ja nu man ir gigantiska sistēma, kur ir 100 moduļi,kas izmanto dažādus CSS un JS failus, es tak nelikšu visus HEADā manuāli. Kuru moduli inkludējam, tad tas arī inkludē nepieciešamos CSS un JS. JS failu aliasi - es izsaucu includeJS('jquery'), bet configā ir norādīts links uz konkrētu JS failu. Nodrošina vieglu versijas izmaiņu vai ceļa maiņu. Templeitu sistēma: man vajag programmējamus templeitus ar custom tagiem, kurus pēc nepieciešamības var pieprogrammēt klāt. Tas ir - paņem servera pusē ielasa custom markupu, apstrādā datus un beigās izdrukā ārā rezultātu. Piemērs, kā templeits izskatās: http://pastebin.com/M2XxRun8 - šeit piemērā ir Form objekts, kurš ielasa tagus un ļauj tos modificēt (ielasa, validē laukus), pēc tam to tagu vietā izvada attiecīgus HTML tagus ar aizpildītiem atribūtiem. Vēl - kāpēc man būtu jāizmanto oldschool AJAX , ja mūsdienu browseri atbalsta socketus ? Servera pusē, piemēram, Node.js. Protams, fallback mehānisms jānodrošina. Visiem skatiem ir servera ViewController, + arī klienta pusē ir attiecīga ViewController klase, un tie savā starpā var komunicēt ar eventiem. Eventus, protams, transportē ar mehānismu, ko pārlūks nodrošina (socket.io, AJAX). Routings - nepatīk man definēt ar regexiem. Man ir tā, URL path sadala pa segmentiem, un tad tos padod RouteController.dispatch() , kas attiecīgi pats izlemj, vai izmest 404 statusu, veikt redirektu, vai inicializēt konkrētus skatus. Vai padod dziļāk uz citu RouteController. HTML5 navigācija - es izmainu URLi bez pilnas lapas pārlādes - sistēma pati izrēķina, kurus skatus vajag pārlādēt vai kurus izmest ārā, vai arī, ja vajag, tomēr veic pilnas lapas pārlādi. Protams, fallback, lai darbojas bez JS/HTML5. Visu rakstu Haxe valodā, bet target platformas ir PHP, Neko, un var arī Node.js sataisīt. Visos gadījumos socket serveris vai parastā metode - ar Apache moduli (izņemot Node.js).

Labdien! Pieņemu gabaldarbus, bet var arī pastāvīgu, man tikai vajag nepārtrauktu plūsmu ar web projektiem. Ir 5 gadu pieredze ar web tehnoloģijām. Ir tikai viens nosacījums: es strādāšu ar sevis rakstīto web framework un CMS, attiecīgi man vajag projektus, kuri jāraksta no nulles. Ir doma frameworku attīstīt tālāk un kaut kad palaist tautās bez maksas, nu tā normāli - ar skaistu saitu, dokumentāciju, utt. Sūtiet PM.

Domāju,ka php.net sākumlapā vajadzētu labi pamanāmu linku uz saprotamu MVC tutoriāli. Bet vispār jau es tāpat rakstīju daudzus gadus atpakaļ. Un es parasti neko nedaru kaut ko , jo tā ir rakstīts, pašam vajag šos te klikšķus smadzenēs.

Tur kaut kas nav tīrs !!!!