black

Tāpēc, lai būtu reuseable kods. Vinjsh varees uztaisiit metodi readDir(), kas atgriez masiivu ar failu vaardiem direktorijaa, un peec tam to izmantot daudz un dazaados veidos savos naakamajos projektos :)

Nebuus saistiits tieshi ar PHP, bet ar programmeeshanu kaa taadu: sheema sekojosha - 1) nolasaam foldera failu nosaukumus, ieliekam tos nosaukumus kaut kaadaa masiivaa 2) peec tam braucam cauri masiivam, un chekojam, vai tekstaa ir "29" 3) ja ir, izsaucam unlink. PHP manuaali var atrast sadalju par masiiviem (arrays), ar to vari saakt. Par unlink funkciju, raadaas, Tu jau zini. Protams, jebkursh to programmu var uzrakstiit kaadas minuutes laikaa, bet tad jau Tev vairs nebuus interesanti.

Drīz goldy mūs turēs par zagļiem, ja mēs regulāri (reizi mēnesī) nepirksim tos produktus, kas tiek reklamēti. Reklāmdevēji taču arī maksājuši naudu par reklāmām, cerībā, ka mēs pirksim viņi produktus (un viņiem arī ēst ta gribās), tāpēc tā vienkārši skatīties uz viņu reklāmām, un neko nepirkt arī nav smuki, vai ne?

Pieņemsim, ka Delfiem ir konstanti izdevumi par ziņām (Letai, BNS, whatever). Protams, tas ir vienkāršots modelis (Delfiem ir arī mainīgās izmaksas, daļa no kurām ir atkarīgas no reklāmas apjoma, utt, taču to šeit neņemsim vērā.) Tas ir, brīdī, kas ieņēmumi no reklāmas pārsniedz šos izdevumus, Delfi sāk pelnīt. Tātad no pašu Delfu pastāvēšanas viedokļa, reklāmas varētu būt krietni mazāk, nekā tas ir patreiz. Taču tas nenozīmē, ka viņi varētu vispār nelikt reklāmas, jo tad viņi vairs nevarētu samaksāt par ziņām, aģentūras šos iesūdzētu tiesā, un viņi aizietu pa burbuli, jo vairs nevarētu apmaksāt rēķinus par savu internet pieslēgumu. Būtībā, ieliekot pārāk daudz reklāmas, viņi paši grauj savu tirgu - sāk parādīties visādu advancēti useri, kas atslēdz reklāmas jau browseros, visādi filtrs.lv, kas piedāvā lasīt ziņas bez reklāmām, utt. Es negribēju teikt, ka viņiem vispār jāiztiek (vai ka viņi VAR iztikt) bez reklāmām, bet kā tajā latviešu sakāmvārdā - kas par daudz, tas par skādi.

Tas, cik daudz naudas nopelna cilvēki, kas raksta ziņas jau nav atkarīgs no reklāmas daudzuma. Ja vien ziņu aģentūrām nav ārkārtīgi interesanti līgumi ar Delfiem (piem., ziņu cena atkarīga no apgrozījuma), tad palielinoties ieņēmumiem par reklāmu, palielinās pašu Delfu peļņa.

Izrādās, šiem ir ļoti interesanta tehnoloģija - ziņa tiek parādīta ieksh iframe, bet saturs nāk no paša apollo print-friendly lapas. Un tas, kas ir mazliet smieklīgi - viņi Apollo reklāmas aizvieto ar savām (no Google Ads).

Robim iesaku to uztvert kā olimpiādes uzdevumu. Tā ir realitāte, ka daudziem nākas šādu fīču taisīt zem MySQL (ti, nav citas izvēles), ir tikai veiksmīgākas un mazāk veiksmīgas pieejas šai problēmai. Tas, ka Oracle ir iespējams CONNECT BY kverijs, vēl nenonzīmē tur tiek izmantots kaut kas cits kā parasta rekursija. Par draugiem.lv pieeju esmu informēts, diemžēl nevaru savu informāciju atklāt šeit.

Par jūsu piedāvāto risinājumu trūkumiem - id-parent-id gadījumā jātaisa rekursīva funkcija PHP galā, kas ne tikai nav smuki, bet dažreiz ir arī impossible (uzprasiet tiem, kas mēģinājuši kopēt draugiem.lv). Par parasto nested sets metodi - ievietojot jaunu nodi (ierakstu) ir jāpārkārto min-max vērtības citiem ierakstiem. Ja ir pietiekoši biežas izmaiņas, un daudz ierakstu, tad tas arī kļūst neiespējami. (Manā uzdevumā - Papa ir boss multinacionālai kompānijai, kur katru sekundi kādu darbinieku pieņem/atlaiž). Bet galu galā, jūs jau neesat Robis!!!

Aptuveni tā. Iepriekšējo problēmu Robis varēja atrisināt, izmantojot grāmatās apgūstamās gudrības, bet šeit standarta risinājumi nederēs. Gadījumā, ja viņš tiks līdz oriģinālai atbildei, viņš būs palīdzējis gan man, gan visai sabiedrībai kopumā. Man sevišķi interesētu tā daļa, kas saistās ar matemātiku - piemēram, setu apzīmēšana ar bezgalīgiem daļskaitļiem (http://arxiv.org/pdf/cs.DB/0402051v1)

Piedāvāju jaunu uzdevumu Robim. Piemērs iz dzīves - ir jāsaglabā informācija par firmas darbiniekiem. Pašā augšā sēž Papa, viņam ir trīs padotie (Jānītis, Pēterītis un Anniņa). Katrs no šiem padotajiem patiesībā ir lielas nodaļas vadītājs, tātad padotie zem viņiem ir vēl vairākos līmeņos. Par katru darbinieku (Papu ieskaitot), tiek saglabāta darba alga. Grāmatvedei (Anniņai) jāsaskaita, cik īsti katra nodaļa iztērē (tātad, kāda alga ir Jānīša, Pēterīša un pašas Anniņas darbiniekiem. Kāda būs tabulas(-u) struktūra, kurā glabāsi informāciju par darbiniekiem (vārds, uzvārds, alga, utt)? Kāds būs SQL pieprasījums, kas atgriezīs kopējo algu trīs uzņēmuma nodaļām (ti, Jānīša, Pēterīša, Anniņas padotajiem, pašus nod. vadītājus ieskaitot)? Jāpiemin, ka pats Papa nezina, cik "līmeņos" tiek organizēta viņa firma, ti, var būt, ka zem Jānīša nodaļas ir vēl 10 nodaļas, katrai no kurām 3 vai 4 apakšnodaļas, utt.

Es pats arī izmantoju Operu, kas lieliski bloķē reklāmas. Taču runa ir ne tikai par reklāmām, bet arī par ziņu apkopošanu vienā lapā (ne visām .lv ziņu lapām ir RSS atbalsts) Jautājums - vai tas, ko viņi pašlaik dara, viņiem negarantē rūtainu sauli uz kādiem 1-2 gadiem.

Tikko pamanīju vienu lapiņu, kas pārpublicē ziņas no TVNet, Delfiem un Apollo, izņemot ārā reklāmas. Kādi ir jūsu viedokļi par viņu izredzēm saisītbā ar copyright likumiem? Cik es saprotu, viņi netur ziņas uz saviem serveriem, bet gan tikai piedāvā 'advanced' lietotāja interfeisu minētajām ziņu lapām (neviens jau nevar aizliegt uzraksīt browseri, kas nerāda reklāmas, šajā gadījumā tas ir web serveris, kas piedāvā parveidot "jebkuru" (reāli tikai jau trīs minētās ziņu lapas) lapu, izņemot no tās reklāmas. Tātad no juridiskā viedokļa - vai tā skaitās pārpublicēšana (aizliegta ar autortiesību likumu)? Pats ar šo brīnumlapu neesmu saistīts.

Par to, ka alga ir konfidenciāla informācija. Manuprāt, tā ir no padomju laikiem iegājusies tradīcija, kas daudzās citās valstīs nepastāv, un cerams, viss palēnām mainīsies arī šeit. Ja nu vienīgi uzņēmēji tiešām cer iegūt kaut kādu 'competetive advantage' neizpaužot saviem programmētājiem to, ka viņu algas ir, piemēram, zemākas nekā vidēji nozarē... Ja algas ir lielākas, tad to diez vai ir jēga slēpt. Ja nevar ievietot atsauci uz uzņēmuma mājaslapu, tad noteikti var ievietot īsu aprakstu par uzņēmumu, darbinieku skaitu, specializāciju, utt. Par strādāšanu mājās - tam noteikti arī ir savas priekšrocības. Sazinoties ar e-pastu/IM, nav nepieciešams veikt kaut kādus pierakstus, par to, kas ir uzdots, un kad ir uzdots. Un, piemēram, manā uzņēmumā nav īpaši lielas izvēles par to, kā sazināties, jo lielākā daļa kolēģu tāpat atrodas ārzemēs.

Mani kā darba meklētāju parasti kaitina vairākas lietas darba sludinājumos: 1) Nav norādīta aptuvenā alga (vismaz kārta). To, ka "tiek piedāvāts konkurētspējīgs atalgojums" vispār var neminēt - tas atkārtojas gandrīz visos sludinājumos. Neminot atalgojumu, jūs zaudējat tieši labākos programmētājus, kuri jau saņem normālu algu pašreizējā darbā, un kuriem vienkārši nav laika iet uz 3 intervijas kārtām tikai tāpēc, lai noskaidrotu, ka saņems 2x mazāk. 2) Tiek piedāvāti "draudzīgi kolēģi" tieši neminot, kā šis draudzīgum varētu izpausties. Katram ir savi ieskati par to, kāds tieši ir draudzīgs kolēģis. 3) Prasību saraksts pārāk garš. Tiek meklēti ubermonstri, kas zina php, ajax, mysql, oracle, linux, javascript, pie reizes tiek ielikta arī java, utt. Atļaušos apgalvot, ka jau šeit minētās tehnoloģijas viens cilvēks nevar iemācīties perfektā līmenī (to vienkārši fiziski nevar paspēt iemācīties/apgūt), taču bieži prasību saraksts ir vēl pāris reižu garāks. 4) Trūkst informācijas par firmu. Ļoti retos sludinājumos ir atsauce uz firmas mājaslapu, kur varētu sīkāk iepazīties ar pašu uzņēmumu. Varbūt daži programmētāji arī iet strādāt "uz dullo", iepriekš par firmu nekā nezinot, bet nu pārsvarā tas tā nav. 5) Nosacījumi par strādāšanas laiku/vietu. Daži programmētāji grib strādāt birojā, citiem labāk patīk sēdēt mājās ar kafijas tasi pie rokas un mīļoto sunīti pie kājām. Daudzi nenorāda, vai ir iespējams strādāt ārpus biroja/noteiktā darba laika. Tikai mans viedoklis. Paldies par kritiku.

nepieķēzīsim Robja darba sludinājumu ar offtopiku...

Ideja jau veca kaa maaja. Iesaku ievilkt lapu, tad apstraadaat ar HTML Tidy, tad paarkonverteet uz XML, un tad no XMLa vilkt laukaa visu, ko vajadziigs. Straadaas briiniskiigi, liidz kaads izdomaas lapu mazliet pamainiit. Tad nu saakas taadi briinumi kaa XML sadaliishana pa atseviskiem gabaliem (kokiem), un sho dalju hash saliidzinaashana, visaadi algoritmi, kaa atrast nemainiitaas daljas (XML-diff), utt. Noveelu veiksmi! http://www9.org/w9cdrom/312/312.html

Robis domā :)

Kaitniek, nosūtīju Tev meilu.

Man vajag, lai DIVam būtu jauki, apaļi stūrīši. Ir apmēram 101 veids, kuru var izmantot, bet es gribētu uzzināt, kuru veidu (un kāpēc) izmantojat tieši jūs. Daži populārākie 1) Izmantojam CSS3 (dažiem browseriem ies, citiem rādīs parastus stūrus) 2) Vajadzīgo DIVu ieliekam 4 citos DIVos, kuram katram ir norādīts savs background-image ar stūrīša attēlu 3) Izmantojam kādu no CSS-only metodēm - pozicionējam vairākus dažādu izmēru DIVus vienu virs otra, lai panāktu vajadzīgo efektu 4) Darām visu to pašu, ko 2) gad., tikai jaunos DIVus liekam ar Javascript (šādi tiek panākts, ka HTML satur tikai semantisku markup) 5) un tā tālāk. Kura metode jūsuprāt ir vislabākā?

Atpakaļ dabūt var ļoti vienkārši - sākumā to JS blāķi iepostējam http://www.prettyprinter.de, pēc tam - atveram ar kādu teksta redaktoru, kas supportē refactoring (ti, vienā vietā nomainot variable name, tas tiek nomainiits visaas vietaas, kaut kas ljoti liidziigs gudram search-replace). Un tad tikai braucam cauri kodam, un mainaam variable vaardus no 'kfsh33xc' uz 'showMessage', utt. Nu, ir pāris reizes tas kods jāpārlasa, lai saprastu, ko katra funkcija dara, bet vairāk par nedēļu tur parasti nevajag.

Tas būtu ideāls variants tiem, kas strādā grupās. Piemēram, varētu pārsūtīt kolēģiem interesantu linku ar iezīmētām svarīgākajām lietām, tāpat varētu kopīgi taisīt dažādus dokumentus (līdz šim esmu redzējis kaut ko līdzīgu ārzemju likumi.lv versijā - ti, katrs var izteikties par likuma redakciju, pakomentēt to vietu, kas nepatīk). Galu galā - tā var arī programmēt - piemēram, lapā stāv k.kāds programmas kods, un katrs iesaka vietas, ko varētu pamainīt. Visu tekstu īsti negribas glabāt, mani vairāk interesētu idejas/algoritmi, par to, ka saglabāt pašu vietu, pie tam, veidā, kas pieļautu (nelielas) lapas satura izmaiņas. Pašlaik domas ir divas: saglabāt to pozīciju kā DOM koku (piem, komentārs par html>body>table>tr(0)>td), vai arī saglabāt tieši tekstu, kas ir komentēts, un tad nākamreiz meklēt tekstu, un to vietu iezīmēt ar citu krāsu, utt. Bet nu es mazliet ceru, ka kādam ir kaut kāda mazliet ģeniālāka ideja par manām, citādi tiešām nav jēgas pūlēties. Esmu jau izpētījis, kā dara Wizlite, un kā dara vairāki citi līdzīgi projekti. Es gribu uztaisīt labāk :)

Ir doma uztaisīt kaut ko līdzīgu http://wizlite.com, kur var paņemt jebkuru weblapu, iezīmēt lapas daļu, un pievienot savu komentāru. Nu aptuveni kā wiki, tikai tāds, kurš strādā ar jebkuru lapu. Piegājiens varētu būt aptuveni šāds: 1) Vieglākā daļa - ņemam, uzrakstam HTTP proxy, kas pieliek katras lapas augšā 'highlight' javaskriptu. 2) Uzspiežot/iezīmējot kādu lapas daļu (piem., paragrāfu vai teikumu), tiek mainīta tās daļas krāsa (teksta background paliek dzeltens), un atveras neliels popup lodziņš, kur var ievadīt savu komentāru. Lielā problēma - kā uz servera/datubāzē saglabāt to vietu, kas ir komentēta? Tas ir, es gribu, lai nākamie lapas komentētāji varētu redzēt komentārus, ko ievadījuši lietotāji pirms viņiem. Ideja būtu kaut kā atzīmēt to lapas elementu, kuru lietotājs ir nokomentējis, un nākamo reizi to rādīt dzeltenu jau defaultā. Diezgan murgaina doma sanāca, bet ceru, ka kāds saprata.

Tā arī nāksies darīt, lai gan gribētos, protams, lai varētu kaut kā uztaisīt bez cronjoba...

Shito jau biju iedomaajies, tachu ir viena probleema - produktu expire_date. Tas nozīmē, ka pieejamo produktu skaits mainās atkarībā no pašreizējā datuma. :(

Nested setam gadījumā nebija jāmaina apmēram puse no kategorijām pie inserta? Tad pie katra kategorijas inserta 10K updeiti... Brr...