Jump to content
php.lv forumi

j2b

Reģistrētie lietotāji
  • Content Count

    39
  • Joined

  • Last visited

About j2b

  • Rank
    Māceklis
  • Birthday 02/28/1975

Profile Information

  • Gender
    Male
  • Location
    Riga
  • Interests
    Web development, Web design, Web technical/server solutions, PHP, Java, Python, Ruby, JS, Windows, Mac, Linux, VMware, RedHat virtualisation, XenServer, Stikpoint.com

Contact Methods

  • Skype
    janisbalodis
  1. Ne vienmēr ir svarīgi kurš, bet gan kā. Lai gan profilus nepētu. Lai arī man ir problēma ar liekvārdību, taču savā virzienā cenšos pēc iespējas vienkāršāk tikt līdz risinājumam :) Par šo jautājumu neko nevari pateikt? http://php.lv/f/topic/18048-mysql-geospatial-optimizacija/
  2. Es citreiz brīnos (lai gan arī pret sevi varētu tādas šaubas izteikt), kādēļ nevar tajos manuāļos uzrakstīt tā, kā tu tagad uzrakstīji. Un viss uzreiz ir skaidrs un saprotams. Vismaz man :)) Paldies par sīkāku paskaidrojumu.
  3. Zinu, ka jābūt. Mana prakse liecina, ka dikti dziļi jāsāk urbties tajās lietās iekšā, kamēr sāc iegūt patieso manuāļa vērtību. Tādiem kā es šāds manuālis ir vēl lielāks murgs, jo komentāri jau arī ir diezgan specifiski un vairumā gadījuma "pavelk" līdzi vēl vairāk jautājumu. Subjektīvi vērtējot php.net tiešām ir kvalitatīvs, bet ir jābūt kādam līmenim, lai varētu saprast, kas tur rakstīts. Iepriekš strādāju ar Lotus Notes Domino skriptiem, un tikai pēc tam, kad "izkodu" jēgu, sapratu arī manuāļa nozīmi. Vēl, protams, ir būtiski, cik ātri tas ir lietojams. Tādēļ saku, ka PHP.net ir OK, tikai jātiek līdz tam līmenim. Man vēl viss priekšā, bet īsti nezinu, vai man to vajag. Ja būtu kas sarežģītāks, vērstos kaut vai pie Tevis. Man ir nākamais jautājums: http://php.lv/f/topic/18048-mysql-geospatial-optimizacija/ Var būt šo vari nokomentēt? Negarantēju jautājuma sakarību :))
  4. Nākamais jautājums: Vai ir specifiski jākonfigurē MySQL datubāze geoproximity meklēšanas vajadzībām? Cik daudz tagad esmu izgājis cauri neta resursiem, saprotu, ka ar MySQL 5.1x+ un vēl labāk ar PostgreSQL extensions tagad ir iespējams DB līmenī veikt ģeolokācijas un proximity aprēķinus. Vai lai tas darbotos, db ir kaut kā speciāli jāuzstāda? Kā to varētu nokonfigurēt, ja ir jau esoša DB? Vai kāds to izstrādei ir darījis uz MAMP?
  5. :) Tā pat, kā jebkuras citas profesijas pārstāvim, kuru ver vaļā, kad jau viss pārējais ir izmēģināts :))) Bet paldies par linku. Citreiz man ir grūti "iebraukt" tehniskākos tekstos, tādēļ vienkāršāk uzdot tādus jautājumus, un ir iespēja ātrāk uz tiem saņemt atbildes, jo citiem (kas to zin) par to nav jālauza galva. Tā nu mēs viens otru uzturam pie dzīvības :)))) Tankjū!
  6. Negribu. Vienkārši jau galva kūp, un laikam jāmet miers, bet šis sīkais jautājums mani dikti kaitināja :). Manuāli neskatījos, bet domāju, ka tur būs aprakstīts par mainīgo veidiem, to konvertācijas iespējām, statusiem, utt. Katrā gadījumā izskatās, ka esmu domās uz pareizā ceļa.
  7. Vai šis mainīgais varētu būt jebkāds? Piemēram $output_general, vai tomēr tas ir kā vispār pieņemts fakts, un labāk to ieturēt, nekā veidot savu? Otrs, vai šī mainīgā saturs ir tikai string, vai arī var būt citi datu veidi?
  8. [sOLVED] Kaut kā sāku dziļāk rakties, un (par tik par cik PHP nav mana stiprā puse) mēģināju apjēgt dažādus teksta (string) izdošanas mehānismus no php koda. Sapratu no visa lasītā, ka labāk lietot echo, nevis print, jo pirmais maķenīt ātrāk apstrādā pieprasījumu. Taču uzdūros vienam kodam, kur tiek izmantots $output .= xxx. Vai kāds var nokomentēt kas ir $output? Mainīgais (variable)? To vienkārši izvēlas vispārējas sapratnes dēļ, vai PHP tam ir sava nozīme? Un .= ir tas pats, kas ņemam jau iepriekšējo $output vērtību un liekam klāt jauno?
  9. Ja rūteris pielieto NAT (Network Address Translation) tehnoloģiju atdalot ārējo tīklu no iekšējā, tad jā - noteikti būs viena adrese. Ir varianti, ja datoriem liek ārējās adreses un to laiž caur rūteri dažādu citu iemeslu dēļ (sakaru kanālu rūtēšanai, vai specifiskai datu plūsmas kontrolei vai citiem iemesliem). Tādā gadījumā katram datoram būs viena atšķirīga adrese. Piekrītu viedoklim, ka 99.99% būs viena IP. Ja skripts ir domāts web aplikācijai, tad sesijas ID būs vienīgais, kas attiecīgi atdalīs tos lietotājus. Sesijas ID tiek izmantots arī tādiem mērķiem, ja lapas aplikācijā ir paredzēts izdot kļūdas paziņojumu vai kādu atbildes reakciju uz lietotāja darbībām. Respektīvi, ja sesijas ID netiktu uzskaitīts, tad web aplikācija nevarētu zināt, kuram no lietotājiem, kas atrodas aiz viena rūtera, uzrādīt šo atbildes reakciju. Domāju, ka sesijas ID būs diezgan korekts. Lai gan pieļauju domu, ka to varētu arī aizstāt ar spoofing, bet tad ir jautājums par drošību vairāk, nekā par lietotāju atdalīšanu.
  10. Varētu būt tev taisnība. Ar spēļu serveriem neesmu ņēmies, vien domāju, ka varētu pamēģināt. Nezināju, ka tiem ir savi protokoli. Reverse proxy varētu paķert DNS vārdu, tad forwardēt. Var būt strādā. Tiešām tad nezinu. Nav arī kur pašlaik pamēģināt. Vai tajos spēļu serveros nav pašiem iebūvētas tādas lietas? Būtu interesanti, ja visi spēļu serveri skrietu tikai uz viena fiziskā servera bez jebkādiem klāsterēšanas un load balancing mehānismiem. Vai nav attiecīga OpenSource risinājuma arī priekš šīm vajadzībām? Tiešām nezinu pat kā meklēt, jo esmu svešs spēļu sfērā.
  11. Apache Reverse Proxy režīmā. Var izmantot arī citus risinājumus - Squid, Nginx, Varnish, utt. DNS-ā novirzi visus domēnus (domēni un sub-domēni tomēr būs vajadzīgi) uz Reverse Proxy serveri, kur attiecīgi tas tālāk novirza kaut vai pēc IP un portiem. Ja lieto SSL savienojumus, tad gan tik vienkārši nebūs, jo katram SSL saitam vajag savu IP adresi. Tomēr ērtāk tev būtu darboties ar VPSiem, nevis ar shared hostiem, jo kaut kur tev ir jādabū kontrole gan pār DNS, gan arī pār Reverse Proxy. Nezinu nevienu shared hostētāju, kas Reverse Proxy dod kā servisu. Līdz ar to būtu jātaisa pašam.
  12. Vari apskatīties vēl skriptus no Drupal moduļa (http://drupal.org/project/email_verify), bet tie vis ticamāk nav uzreiz izmantojami custom PHP aplikācijā. Tomēr gribētu brīdināt par sekojošo: Jau marrtins un briedis norādīja, ka rezultāti nebūs 100%. Ir tā, ka pēc sintakses SMTP serverim ir jāatbild uz telnet pieprasījumu, kas pateiktu vai tāda adrese ir/vai būs relejota, vai nē. Tomēr problēmas rada citi apstākļi. Korekti un pilnīgi konfigurētas meila sistēmas iekļauj ne tikai korektu mail hederu un HELO funkciju pārbaudi, bet vēl talkā nā DNS Lookup, Reverse DNS Lookup, DNSRBLi un tādas liets. Līdz ar to, lai tiktu līdz maila pārbaudei no sākuma ir jāpanāk, ka tavs web serveris, kurā griežas aplikācija faktiski ir nokonfigurēts kā pilnvērtīgs SMTP serveris ar visām no tā izrietošām sekām. Tā pat būtiski ir apstrādāt Gray listing sistēmas un arī nodrošināt, lai šis web serveris (tā IP adrese) nav spam listingos. Vis ticamāk uz Shared hosting to izdarīt nevarēs. Būs jāņem VPS/Collocation vai jāīrē fizisks serveris vai vismaz IP adrese savām vajadzībā. Visi šie papildus pārbaudes mehānismi un DNS pārbaudes ir tās, ka padara elementāro funkciju mail to: neiespējamu skriptiem, ja šis web serveris nav tā nokonfigurēts. Tieši šī iemesla dēļ šādām meilu pārbaudēm ticēt nevar. Vienīgais variants būtu izmantot meilinglistes softu, kurš vairāk vai mazāk secina, ka atkārtoti meils uz konkrētu pastu nav aizgājis, bet tur, savukārt, var apstrādāt SMTP atbildes - nav tāda konta, pārpildīta kvota, utt. Bet tas ir pēc tam, nevis tagad uzreiz. Ja vēlies veikt pārbaudes e-pasta esamībai reģistrācijas procesā, tad rēķinies ar to, ka daudzas reģistrācijas būs neveiksmīgas un zaudēsi apmeklētāju. Esmu to mēģinājis kaut vai ar apollo.lv pastiem - nekā. Protams, serveris bija dev stadijā, un nekādas SMTP fīčas tam nebija konfigurētas. Tāpēc izvēlies tad citus mehānismus, kā nočekot, vai pasts ir pareizs.
  13. j2b

    CMS Flash lapai

    Googlē šādi tādi linki ir atrodami, tomēr kaut cik sakarīgi risinājumi izskatās ir tikai maksas. Pats gan neesmu meklējis un testējis. Alternatīvs risinājums ir izmantot Flex, kuru var sasaistīt kopā ar kādu esošu CMS. Ir risinājumi to darīt uz Drupal bāzes - Drupal kā backend, Flex interfeiss - kā frontent. Pieļauju domu, ka līdzīgu draudzību var izveidot arī ar citām CMS, vai rakstīti pašam pamatu uz kāta PHP freimworka bāzes. Lielu daļu efektu un knifiņu var veidot ar js (protams, ne tik plūstošā un efektīvā veidā, kā Flash).
  14. Ik pa laikam sekojou līdz tam, kas notiek šajā diskusijā. Ņemot vērā to, ka pirmais posts bija faktiski bez konkrēta jautājuma, kā arī konkrētas atbildes šajā tēmā droši vien nav iespējamas/paredzētas, kā arī gan ar manu, gan ar citu iesaistīto cilvēku komentāriem atkal esam pamētājušies no vienas galējības otrā, un no teorijas līdz pat konkrētākiem gadījumiem, atskatījos uz sākotnējo rakstu un to, kas tālāk izvērsās sarunās... Man radās iespaids, ka šajā diskusijā piedalās dažādu zināšanu līmeņu un specializācijas speciālisti, un ceru, ka šajā kontekstā mēs spējam cienīt katrs savu darbu un citu paveikto, ja tas dod labumu nozarei un patērētājam. Mazliet atsvadzinošu domu šajā kontekstā ieguldīja šodien Mr.Kay (komentārs #45). Jāatzīst, ka arī manos komentāros var būt ir pavīdējusi subjektīvā emociju problēma, bet kur tad ir sāls? Mēs varam rast atbildes uz konkrētiem jautājumiem. Bet tie, kas vairāk teoretizē (daļēji arī es), var arvien plašāk paskatīties uz problēmu un rast kaudzi ar citiem jautājumiem. Un tad sākas nebeidzamais process... (sākotnēji līdzīgi kā postā: #56). Ir vairāki risinājumi: Vienkārši patērēt savu laiku par to diskutējot un nenonākot ne līdz kam; Izveidot šo tēmu par php.lv foruma rekordu (varat izvēlēties: vis vairāk komentāru vai vis ilgstošākā (laika ziņā) diskusija); Var būt tomēr kaut ko mēģināt panākt un izdarīt soli (lai arī neefektīvu, bet tomēr tas būs solis mums visiem lai paceltos no saviem darba krēsliem un vismaz kaut ko (kaut arī ne līdz galam pareizu) bet izdarītu). Lai arī pastāv viedoklis, ka tirgu vai iespējas veido "augstāki spēki" (tie, ja kas, vienmēr būs "Pret") :) (ar to es domāju veiksmīgākos uzņēmumus/cilvēkus, kas spēj savā virzienā novirzīt lielu daļu IT/web izstrādes programmatūras budžetu), es tomēr gribētu tam visam oponēt. Mans viedoklis (subjektīvais) ir tāds, ka tirgus esam mēs paši. Nav jau noslēpums, ka mēs katrs vienmēr atrisināsim savas sāpes un atradīsim iespēju pelnīt 500 - 1000 - xxx - ...Ls mēnesī. Tomēr šeit vairāk diskusija ir par to, ka paši veidojam to tirgu, kurā arī kūņājamies (vai arī čakarējam viens otru). Paskatieties, kā, piemēram, Zviedrijā celtniecības lietās arodbiedrības "lavierē". Lai arī daudziem liekas, ka tas tikai sarežģī vienkāršas lietas, vai arī bremzē komerciju (it īpaši "jaunajiem monstriem") tomēr vai tad no tā nav labums nozarei un tās dalībniekiem - mums pašiem (un arī klientiem)? Protams, ka tādā ziņā būs kāds "tuvāks" vai "tālāks" dalībnieks, bet labums ir daudziem, nevis vienam. Tā pat arī potenciālie pārmetumi tiem, kas būtu "tajā" arodbiedrībā un vienkārši saņemtu algu par darbu, neko nedarot (neprogrammējos/neizstrādājot)... Bet ja rezultāts ir, vai tas tomēr nav labi? Viss jau ir pašu rokās un tajā, kā darbs tiek strukturēts, definēts vai atdalīts. Teoriju par darba dalīšanu mēs neesam izdomājuši paši. Tas ir aizņemts mantojums. Tomēr savs racionāls grauds tajā ir. Problēma ir tikai tajā, vai LV tirgus tiešām ir gatavs uzņemt tādus piedāvājumus, jo par katru posmu kādam ir jāmaksā (klientam). Un te nu tehnoloģijas/risinājumi/pieejas dara savu (šeit nedomāju atklātu nepatiesu dempingu). Piemērs ir kaut vai tas pats MS (visu - visiem) - kur gala rezultātā gala produkta cena nav atbilstoša konkrētam tirgum un gala produkts jau vairs nedara to, kas tam bija mērķis. Ja padomājam - MS Office pilnā versija ap 400Ls gala lietotājam. Skaidrs, ka tajā ir iekļauti ekonomiskie aprēķini, bet vai tas ir atbilstoši tam, ka lietotāji no tā visa izmanto tikai 10%. Un galvenais, ar to ir "saslimuši" un cenšas izdarīt visu, itkā MS Office būtu vienīgā programmatūra uz pasaules, ar ko vispār var strādāt. Te ir apvienotas intelektuālās iespējas ar poligrāfiju, dizainu, maketēšanu, dokumentu apstrādi, webu, datubāzēm, versiju kontrolēm, zīmēšanu (galu galā - tas no personīgās pieredzes, ka saņēmu grafisko izklāstu telpas izkārtojumam MS Excel formātā :) ), utt. Bet vienalga - tas viss (pareizais un sadalītais) sadārdzina gala cenu. Sorry atkal aizrāvos... Vai tiešām mēs cīnamies viens pret otru, vai arī tomēr ir iespēja vienoties par "kopēju dziesmu" un ieviest vismaz vienu standarta oficiālās informācijas kanālu/arodbiedrību/asociāciju/da-jeb-kas? Un vai to vajag? Vienu brīdi minēju, ka runāt ir viens, bet darīt - cits. Man ir bijusi reāla pieredze vienas asociācijas tapšanā, kur sākotnēji arī bija tie paši noliedzošie motīvi. Tomēr pie efektīva darba 7 gadu laikā tas tomēr ir kļuvis par spēku/viedokli, ar kuru jārēķinās arī ir iepriekš minētajiem "augstākiem spēkiem". Un ja ne visiem, tad daudziem no tā ir labums. Tas ir process, kuram jāiziet cauri. Un ja arī tādu precedentu šobrīd nav, tad mums, kā LV ir iespējas tajā izcelties. Jautājums tikai - vai tam ir atbalsts. No praktiskā viedokļa man ir viens risinājums, bet vai to vajag, to definēs Jūsu atbalsts vai komentāri - arodbiedrība/asociācija. Pagaidām tas ir teorētisks murgs, bet jebkurā gadījumā mēs vismaz nedalīsimies tajos, kas diskutē php.lv forumos, vai kur ārvalstīs, un būs tomēr kopējs oficiāls viedoklis. Kā tas varētu izpausties - vēl nezinu, neesmu par to domājis. Bet manuprāt tas ir virziens. (vismaz viens - no manas puses. Ko Jūs piedāvātu?) Tas protams nerisinās naudas jautājumus (drīzāk sarežģīs), tomēr tas varētu vienot un izskaust vēlmi "apčakarēt" vienam otru. Drīzāk palīdzēt, izglītot. Es brīnos kaut vai par to pašu Drupal (kuri daudzi nosoda). Tur tomēr ir sabiedrības atbalsts. Aptuveni gadu atpakaļ manā rīcībā nonāca informācija par LV bāzētu IT projektu, kurš bija domāts kā Open Source ar sabiedrības atbalstu un attiecīgu paplašināšanu. Kā jūs domājat, cik tālu viņi ir tikuši? No LV - vispār neviena interesenta. Un kur tad ir tā vienotība? (Tā noteikti nav politiskā reklāma!!!) Un tā, manuprāt, ir tā lielākā problēma, ka mēs visi izglītojamies katras pēc savām iespējām un reģioniem, darām savu "mazo" darbiņu, un pēc tam vai nu raudam, vai arī priecājamies. Un, tā teikt, paši būvējam tādu tirgu, kurā katrs mazais ezītis mums var pasprukt apakšā un tad būs Ui! Un ja nu pēkšņi izrādās, ka Ezītis ir pārvērties par Lauvu, ar kuru pārējiem jārēķinās? Un ko tad mēs teiksim? Meklēsim Ezītim/Lauvai vājos punktus? Kuru tas interesēs? Es gribētu atvainoties, ja gadījumā neesmu korekti sapratis un šī diskusija ir domāta tieši programmētājiem. Pats tāds diemžēl neesmu, un arī pagaidām neredzu jēgu par tādu kļūt, jo ir tik daudz (tiešām) speciālistu. Bet domāju, ka ir jānovērtē visu cilvēku ieguldījums: Programmējot freimworkus Programmējot web projektus Adaptējot/pielāgojot CMSus Veidojot grafiku lapām/web projektiem Skriptējot Zīmējot grafiku tieši webam/web-aplikācijām Flešojot Flexojot, utt. u.t.j.p. (šis saraksts NAV izsmeļošs)... Ziniet, kur ir paradokss? Tajā, ka ja būtu tāda "vienība", kas aizstāvētu mūsu intereses, un ja kāds no "izredzētajiem lielajiem" piedāvātu apakšužņemējam izpildīt darbu, bet dēļ šādas "vienības" visi apakšuzņēmēji uzliktu Veto nepienācīgas samaksas dēļ,........ .....tad kāds no mums kļūtu stāvus bagāts. Un tur jau ir tā problēma, ka mēs vēl joprojām cenšamies atrisināt savas personīgās problēmas, nevis nozares jautājumus. LV tiek uzskatīta par perspektīvu IT personāla jomā. Bet vai zināt kādēļ? Diemžēl, mūsu asiņu un vēlmju dēļ mūsu spējas ir 2.lomā. Pirmajā ir tas, ka mums var atļauties maksāt maz un skriesim un darīsim. Tur jau ir tā bēda. Un ja paši to nemainīsim, tad tas ieies arvien lielākās galējībās.
  15. Piekrītu. Apvienībai ir jēga tikai tad, ja no tā ir labums, bet ja tas rada papildus birokrātiju vai "noslauc" naudu, neko nedarot, tad tiešām tā ir - nav jēgas. Par pārējo - problēma jau ir tur, ka klients tiešām neredz to, kādi ir tie "materiāli" un cik kvalitatīvs ir darbs. Tāda pati pieredze ir bijusi ar klientiem, kad viņi saka - re kur man ir lapa, vajag tikai papildināt ar dažādiem sīkumiem. Nu un tad, kad sāc rakties kodos, saproti, ka vieglāk ir uztaisīt jaunu, bet klients jau par to negrib maksāt. Nu un šādas institūcijas jēga varētu būt izglītošanā, tomēr tur ir ļoti šaura strīpa tajā visā darīšanā, un tiešām, visticamāk tas var aiziet neceļos.
×
×
  • Create New...