Endijs

Tā kā es pats no Jelgavas un birojs Jelgavā, tad nu nav ne mazākās vēlmes ķēpāties ar Rīgu :) Tā kā Jelgavā ir maz vietu, kur var kāds PHP koderis izvērsties, tad domāju, ka kādam LLU studentam noteikti vajadzētu būt ieinteresētam. Bet kas to lai zina.

Ping-pong. Piedāvājums joprojām aktuāls. Diemžēl ar tiem dažiem kas pieteicās nekas nesanāca. Lai nebūtu lieka zīlēšana, uzreiz pateikšu, ka problēma bija tajā, ka nevarēja zināt, ka attiecīgās personas varēs uzturēties ilgāk par 1-2mēnešiem. Bet gribās kādu uz ilgāku laika periodu. Nu ko - LLU studenti - lieliska izdevība jums :)

Paldies! Tu kā vienmēr māki salikt punktiņus uz i :)

Lasīju vēlreiz par licencēm un jo īpaši par GPL un esmu ticis līdz baigajai nesaprašanai. Ilustrēšu situāciju. Ir Web projekts, kurā gribu izmantot pChart ( http://pchart.sourceforge.net ), kas tiek piedāvāts izmantojot GNU GPL. Jautājums ir tāds - ja es neņemu nost sourcē nekādas lietas, neizplatu tālāk sourci, nepārveidoju viņu ( izmantoju tikai outputa ģenerēšanai )- vai man Web lapā kaut kur redzamā vietā ir jānorāda, ka tiek izmantots pChart ?

Šaubos, ka tev kāds uz šo jautājumu atbildēs. Jo diez vai kāds tagad tērēs laiku, lai izpētītu pilnībā visas funkcijas. Turklāt nav pat zināms, kādas ir admin panelis utt. Līdz ar to - ja nav zināmas visas funkcijas - kā var nosaukt izmaksas?

Ir jau iznākusi ZendFramework 1.6 RC3 versija - tātad arī fināla versija vairs nav aiz kalniem. Kāds jau paspējis notestēt vai viss strādā tā kā vajag? T.i. - vai nomainot 1.5 pret 1.6 iemetās kādas kļūdas/problēmas?

Wooohooo - esmu ticis līdz pakāpei "skripta bērns" (vai skriptu bērns?) Nice! Nav šajā virzienā nekas mainījies? Joprojām ir doma palikt pie šāda - neko īsti neizsakoša - apzīmējuma, vai ir plānots ieviest kaut ko reālāk situāciju aprakstošu? Varbūt ir kāds voting mehānisms, ar kura palīdzību citi lietotāji var vērtēt kāda cita izteikumus - attiecīgi jo labākus vērtējumus saņem, jo augstāks "rangs" utt.?

He he - pamanīji gan :D

Es ZF in Action dabūju ekskluzīvā kārtā - komunicējot ar autoru un izdevniecību. Bet nu šaubos, ka šādi vēl var izbīdīt kādu kopiju. Bet nu sources var dabūt arī ja nepērk grāmatu. Tās arī ir noderīgas. Tā teikt - var mācīties arī tikai pētot kodus. Bet cik sapratu no pēdējiem autoru paziņojumiem - drīz jau pasākums būs nofinišēts. Tā teikt - tagad tiek veikti pēdējie labojumi. Papildināts: Bet vispār interesanti, ka Latvija nav starp atbalstītajām valstīm. Nebiju pat iedomājies pārbaudīt.

Nezinu vai ir jēga pirkt, bet palasīt var "php|architect's Zend PHP 5 Certification Study guide". Iespējams, ka uzzināsi kādu iepriekš nezināmu sīkumu. Augstāk pieminētās arī ir labas. Nav gan sanācis viņas no A līdz Z izlasīt, bet cik aci esmu iemetis, tad "PHP in Action", kā arī "PHP Architect Guide to PHP Design Patterns" ir interesanta lasāmviela. Ja interesē Eclipse, tad var iemest aci "Zend Studio for Eclipse Developer's Guide". Lai gan grāmata vairāk orientēta uz Zend Studio for Eclipse, tā ir arī labs materiāls, lai vienkārši apgūtu EclipsePDT. Un, protams, kā jau tev iepriekš minēju - "Zend Framework in Action". Pēc apraksta šķiet interesanta "php|architect's Guide to Enterprise PHP Development", bet nav nācies pašķirstīt. Kāds varbūt ir lasījis un var kaut ko pakomentēt?

Kavacky - Un cik tu laiku tērē lai savu frameworku izstrādājot? Un ja nu vajadzēs kaut ko vēl klāt - tērēsi mēnesi lai attiecīgo komponenti uztaisītu? Redz, ar lielajiem frameworkiem ir tā, ka viņos jau būs 99% no tā ko tev vajadzēs. Turklāt ZF par labu runā kaut vai tas, ka aiz tā stāv smagsvari: Zend, IBM nu jau arī Adobe pieslēdzas. Un tas ir tikai sākums. Prognozēju ka ar laiku ZF būs standarts!

Emmm vispār jau offtopic aiziet... es gribēju dzirdēt tieši kaut ko par Zend_Search_Lucene nevis par alternatīvām... :) Tad nav neviena ZF kodera..?

Ja ir kāds ZF koderis - jautājums - vai izmanto Zend_Search_Lucene? Ja tā - padalies ar info kā ir ar ātrdarbību utt. Es uztaisīju saitam search uz Search_Lucene bāzes. Atklājās interesantas lietas. Piemēram, lai gan search index sastāvēja tikai no kādiem 50 dokumentiem, meklēšanas laiks bija ~3 sekundes! Taču pēc index optimizēšanas ($index->optimize()) meklēšanas laiks nokritās līdz 0.15-0.2sek. It kā pieņemami - bet kā būs, kad dokumentu skaits būs pārdesmit tūkstoši? Lasīju, ka citi indeksē pat simtus tūkstošu dokumentu, bet īsti nekur neatradu cik daudz laika prasa search, kā arī cik daudz RAM tiek tērēts tik liela indexa apstrādē. Turklāt kā ir ar queriju rakstīšanu? Ir kādi labās prakses ieteikumi? Piemēram, vai Boolean querijiem ir kāda nozīme tam kā savada subquerijus? Vai arī viņš pēc tam pats visu tāpat pārorganizē kā vēlas?

Jā - tas ir ar PHP versiju saistīts. Līdz 5.2.x versijām reizēm metodes neatgriež datus pēc konteksta, bet vienkārši objektu idus. To it kā var apiet izsaucot vēl speciālu maģisko metodi, bet īsti nav vēlmes iet visiem templeitu failiem cauri un veikt labojumus. Turklāt kas to lai zina - varbūt ka vēl kaut kur uzrodas kādas problēmas. Trakākais ir tas, ka ZF it kā oficiāli atbalsta 5.1.6, bet īstenībā tā īsti stabili strādā tikai ar 5.2.x.

Galvenais iemesls kāpēc es piesējos kodam ir tāds, ka ja autoram vajadzēs veikt izmaiņas dizainā. Nu pēkšņi klients izdomās kaut ko kaut kur pārbīdīt - gribu redzēt cik koderis būs laimīgs no šī murga izlobīt ārā visu HTML un pārlikt visu citur. Neiet runa par to kādus querijus rakstam vai kādus ciklus/iebūvētās funkcijas izmantojam. Bet tas, ka ja ar lapu gribam nopelnīt naudu, tad lūdzu esam tik labi un sadalam visu pa daļām: queriji atsevišķi, datu apstrāde atsevišķi un html atsevišķi. Jā - sākotnēji tas ir grūti izdarāms, jo nodalīt var tikai ja ir jau zināma pieredze. Bet tas būtu tas uz ko vajadzētu tiekties, nevis pateikt "klientam nav svarīgs kods" vai arī "ja ir smuks dizains, tad kods var būt nejēdzīgs". Runājot par OpenSource -kāpēc lai to neizmantotu? Klasiskās firmu lapas, kur ir dažas info sadaļas + kaut kāds custom dizains. Kāpēc lai kaut kam tādam kodētu visu no 0? Lai teiktu "o šitam apakšā ir mūsu superduper CMS"? Muļķības. Klients būs laimīgāks, ka ir to CMS, kas ir viņa lapai zina vēl daudzi daudzi cilvēki. Un ka jebkurš students mācēs veikt uzlabojumus/uzlikt pluginus utt., ja tas būs nepieciešams. Nevis tērēt laiku lai iebrauktu kādā spageti CMS. Atceros sevi kad biju tāds kā autors. Bet zini - nāks laiks un mainīsies domāšana. Tici man!

Negribēju taisīt jaunu pavedienu, ja jau šis ir ticis līdz aizmirstībai. Jautājums - vai kādam ir sanācis normāli piešķilt ZF uz PHP 5.1.6? Man kaut kā mēģinot izvadīt datus ar Zend_View tiek izvadīti nevis stringi, bet objektu idi. Ja kāds ir saskāries - kā visērtāk šo apiet?

Es gan īsti nedabūju izpētīt brīnumus, kurus esi sataisījis. Bet pirms mēģināt noskaidrot cenu - vai tu vari pateikt kas tavā lapā ir tāds, ko nenodrošina bezmaksas! WordPress? T.i. - kāpēc maksāt par tavu darbu kaut vai 5Ls, ja ir pieejams WP? P.S. Vēl cenu vari padomāt aprēķināt pēc modeļa - cik laika prasa attiecīgo lietu uztaisīt un cik izmaksā viena stunda. Ja tur ir tikai rakstu likšana + apskate, tad tāds darbs ir kapeiku vērts. Ja kāds ir par to gatavs maksāt 300Ls, tad viņš ir ļoti liels labdaris. Ak jā - paskatījos koda piemēru ko tu iemeti (kur prasi par cauruma labošanu)... Par to varu pateikt, ka ja uztaisīsi lielāku projektu kodējot tādā pat stilā, tad tam nabagam, kuram vajadzēs attiecīgo lietu papildināt/labot, tu būsi radījis kārtīgu "pain in the ass".

Šķiet, ka man tuvākie burtiņi tad būs MIT

Esmu mazliet apjucis visās licenču lietās. GPL, MIT utt. Varbūt kāds zina, kura no visām ntajām licencēm ir tāda, kura ļauj produktu izmantot komerciālā aplikācijā, tajā pat laikā nekur nenorādot, ka attiecīgā lieta tiek izmantota. Jāpiebilst, ka komerciālais gala produkts ir slēgtā koda produkts.

andrisp - Nu pa taisno jau loģiski ka vajadzētu būt bremzei. Padomā - viņam tak ir jāizanalizē visi faili, kas ir uz servera un iekļauti projekta. Jāuztaisa db priekš auto complete utt. Turklāt FTP nav tas pateicīgākais protokols žiperīgākai pārlūkošanai - īpaši, ja ir viss pa vairākām direktorijām (vairākos dziļumos) izmētāts. Piemēram, kamēr Eclipse caur FTP iekačā ZendFramework ... var paspēt vakariņas paēst :D Tāpēc ja izmanto remote pieeju, tad jāņem kaut ko citu nevis FTP. Bet ja gribās ar FTP - tad import/export vismaz man strādā perfekti (vismaz ar TM 3.0 versiju uz eclipse 3.3.2). Tāda vismaz mana pieredze.

Pievienojos andrisp par to, ka xfr33 tev Eclipse par agru vēl. Bet ja gribās "pačakarēties" http://downloads.zend.com/pdt/all-in-one/ andrisp - a kuru metodi tu izmanto? Edito pa taisno vai edito lokālu kopiju + izmanto import/export ? es kad mēģināju pa taisno editot, tad bij bremze, bet man likās, ka tas vairāk ir tāpēc, ka ftp bremzīgs, jo ārzemēs. Bet import/export piegājiens gan visai žiperīgs.

xfr33 - vari jau tagad apskatīties kādu no citu veidotajiem screencastiem: andrisp: Ar ko tu slēdzies pie FTP? Es aktīvi izmantoju: http://www.eclipse.org/dsdp/tm/ un nav pilnībā nekādu problēmu.

andrisp: Kopš esmu noņēmis auto colapse - ne reizi pēdējo pāris mēnešu laikā nav uzkāries. :) BTW - šķiet, ka šodien uztaisīšu screencast par Eclipse (varēs redzēt kas tas par zvēru tie, kam nav nojausmas)

Atdalīts no http://php.lv/f/index.php?showtopic=11105 Eclipse apgādāts ar pluginiem nodrošina pilnībā visu ko vien vajag izstrādes gaitā. Syntax check, auto complete, debugging, remote servers access, revisions, version control utt. Ja tev vajag, lai iekrāso un ir auto complete - kāpēc neizmantot Komodo Edit: http://www.activestate.com/Products/komodo...modo_edit.mhtml ?

Mana pieeja šim procesam ir sekojoša. Paņemam 1k Ls - ejam pie zināma hostinga kantora cilvēkiem un sakam: "Šeku reku 1k Ls - gribu par to kādu sakarīgu kasti". Domāju, ka viņi zinās ko ņemt un ko neņemt. Galvenais, lai kantora cilvēki ir tādi, kuriem var uzticēties. :)