Kaitnieks

Es par pirmo variantu, ja vien nav tā, ka nagi niez kaut ko darīties :)

Tehnoloģija, kas tevi interestē, saucas "stemming" - resp., vārdu pārveidošana normālformā, apgraizot galotnes un priedēkļus. Cik zinu lucene un elasticsearch piedāvā latviešu valodas celmošanu

Šeit rakstīts, ka teksta-runas programma ir pieejama bez maksas visiem Latvija svājredzīgajiem: http://www.tilde.lv/produkti-un-risinajumi/masintulkosanas-risinajumi/balss-tehnologijas Es ieteiktu sazināties ar Tildi vai Latvijas Neredzīgo biedrību un noskaidrot detaļas. Iespējams, ka viņi piedāvā kaut ko labāku par visvari.

Man nav, bet iegādāties var, piemēram, šeit: http://www.semicom.lv/Datoru_aksesu%C4%81ri_UPS/Programmat%C5%ABra/Tilde/Tildes_Birojs_2008_m%C4%81jas_versija_ar_abonementu_uz_1_gadu_Retail__194025_381.html Domāju gan, ka jaunajā birojā arī ir līdzīga iespēja, tikai saucas savādāk.

Vai ir iespēja kaut kur (newsletter/twitter/forum/whatever) sekot līdz šīs idejas attīstībai? Konkrēti par sevi runājot, man, protams, patiktu atsevišķs kabinets (ha! nu labi, vismaz kubiciņš) un vieta, kur glabāt mantas. Par izmaksām runājot - tā, lai tas sanāktu lētāk, nekā paņemt mazu biroju.

Vai tu centies sitienus noteikt vispārēji dažādos mūzikas failos vai tieši konkrēti šajā?

Nu, labi, palīdzēšu darbam. Kādas ir jūsu asociācijas, domājot par šo uzņēmumu? Ņemot vērā, ka man ir pazīstams programmētājs iekšpusē, manas asociācijas ir daudzpusīgas. Piezīmēšu tikai, ka uzņēmums taisa daudz produktus, ne visi ir kārtējie portāli, daži no tiem ir ne tikai interesanti un no izstrādes viedokļa izaicinoši, bet arī praktiski un vajadzīgi. Kā jūs raksturotu Draugiem.lv brendu darba tirgū (pm. prestiža vieta, kur strādāt; es nevienam neteiktu, ja esmu daļa no uzņēmuma utt.) Drīzāk salīdzinoši prestiža Vai, jūsuprāt, Draugiem.lv ir konkurētspējīgs uzņēmums darba tirgū (tieši priekš IT speciālistiem), salīdzinot ar Google, Apple, Microsoft, Intel un citām kompānijām, kuru darbība balstīta uz IT? Latvijas mērogā viennozīmīgi konkurētspējīgs. Vai esat lasījuši Draugiem.lv veidotus (nevis pārkopētus) darba sludinājumus arī ārpus viņu mājaslapas? Ja jā, tad kur? Iespējams, ka kādā žurnālā. Vai jūs atsauktos uz darba sludinājumu Draugiem.lv? Ja meklētu darbu, tad jā, draugiem.lv varētu būt viens no variantiem. Kāda, jūsuprāt, ir šī uzņēmuma iekšējā atmosfēra? Vai tā sakrīt ar radīto tēlu? Man personīgi mazliet par publisku un uzbāzīgu, bet es pieņemu, ka katrs var savu kluso stūrīti atrast, ja vēlas. Jā, ar tēlu sakrīt.

Kāds ir viedoklis par šo? http://www.sitepoint.com/europe-website-cookie-privacy-law/ Vai no kāda foruma dalībnieka sekos (vai jau ir veiktas) izmaiņas mājas lapā, lai pielāgotos šim likumam, vai arī tas tiks pilnībā ignorēts?

Tajā pašā laikā, celtniecībā ir stingri noteikts, ko var būvēt sertificēti izpildītāji, un ko nē, kā arī kādi būvprojekti un kādā veidā tiek pieņemti. Atkārtošu, ka man pašam patīk brīvība un nesertifikācija, bet tajā pašā laikā nedzīvoju ilūzijās, ka šāda sistēma ir neiespējama - ja ir nauda un griba, tad iespējams ir daudz kas. Runājot par pasūtītāja spējām nodefinēt - iesaku kādreiz izlīst no programmētāju pulciņa, un paskatīties, kā cilvēki dzīvo firmās un iestādēs, kur pat e-pasta klienta konfigurēšana ir milzīgs piedzīvojums. Šiem cilvēkiem tik tiešām palīdzētu kaut kādi nebūt objektīvi kritēriji, pēc kā izvērtēt potenciālos projekta izstrādātājus, bet pašlaik privātfirmas izlīdzas ar paziņu ieteikumiem un paveikto darbu analīzi, savukārt valsts iestādes, kam obligāti jārīko konkursi un jāizvēlas lētākie, mokās kā nu kurā spēj.

Protams, ka tā būtu papildus birokrātija. Mērķis ir dot kritērijus, kas atdala tos izstrādātājus, kurus laiž pie kritisku sistēmu izveides (jo no daudzu sistēmu darbības ir atkarīga cilvēku dzīvība, veselība, produktivitāte vai vismaz labklājība), un tos, kurus nelaiž. Ikdienišķām sistēmām šis kritērijs ir nebūtisks un lielāko daļu php programmētāju, īpaši freelanceru dzīvi sertifikācija neietekmētu, jo tie tāpat valsts pasūtījumos nepiedalās. Problēmas varētu rasties, ja pieņemtu pārlieku aizsargājošus likumus, kas noteiktu obligātu sertifikāciju arī projektiem, kuros tai maza jēga, un, ņemot vērā, ka ierobežojošu likumu izstrāde bieži vien ir izdevīga lielajiem lobētājiem, manuprāt tas Latvijā ir būtisks risks, tāpēc es priecājos, ka IT jomā nav sertifikācijas.

Manuprāt mēs vēl neprotam atdalīt celtnieku no būvinženiera no būvuzrauga no arhitekta, ja saproti, ko es ar to domāju.

Šo domu Makonnels mēģina jau gadiem aktualizēt (sk. grāmatu Professional Software Development) (pie tam, nevis vienkārši piedāvājot sertifikāciju, bet gan licenzēšanu, ar domu, ka profesionāli ar IT izstrādi drīkst nodarboties tikai licenzētie speciālisti), bet, ja godīgi, tad mūsu profesija tam vēl nav gatava un vispār šī ir ļoti pretrunīga tēma. Pašlaik vispraktiskākais vienotās sertifikācijas pielietojums varētu būt iepirkumu konkursu kritērijos valsts iestāžu pasūtījumos. Diez vai tas garantētu, ka cilvēks ir produktīvs speciālists, tāpēc uzņēmumi joprojām veiktu kandidātu pārbaudes, taču iestādēm, kas no IT vispār nekā nesaprot, vismaz būtu kaut kādi salmiņi, pie kā pieķerties.

No uzņēmuma viedokļa veidot akciju ar neprognozējamu cenu ir problemātiski.

Tavā gadījumā nodokļi parādīsies tajā brīdī, kad ķeksēsi naudu no SIA laukā (kā algu vai peļņu). Varu ieteikt grāmatvedi, ja interesē, raksti privāti.

Es visā neiedziļinājos, taču manuprāt neviens nenosauca pašu būtiskāko iemeslu PHP popularitātei (vismaz Latvijā). Vēl pavisam salīdzinoši nesen atrast hostingu, uz kura ietu Python un Ruby nebija nemaz tik viegli. Liela daļa no mums taisa visādas lapeles un portālus un ko tik vēl ne dažādiem klientiem, kas lieto dažādus labus un lētus hostingus, reizēm pat hostējot risinājumu paši. Gandrīz vienmēr var rēķināties, ka PHP lapa darbosies arī uz klienta īpaši superīgā labā un lētā hostinga, ko nevar teikt par citām valodām, lai gan nu jau kļūst labāk.

Vēl nevaru izlemt. Esmu uz "varbūt" pagaidām.

Runājot par phpredis, tagad aktīvākais laikam ir https://github.com/nrk/predis

Es varbūt kļūdos, jo neesmu ar šo API darbojos, bet manuprāt tur darbība notiek ar skaņu kanāliem paredzētā veidā, resp., skaņa tiek iegūta no ienākošajiem kanāliem (mikrofona, line-in) un padota pa izejošajiem. Tas, kas sarežģī konkrēto projektu, ir nepieciešamība "uzsēsties" uz izejošā kanāla un apstrādāt visu no jebkuras citas programmatūras padoto signālu. Līdz ar to, ja ir ļoti liela vēlme darboties tieši ar Java, tad tik un tā jāmeklē vai jāveido draiveris, kas spēj pārtvert skaņas signālu un padod to Javai.

Cik saprotu, tad šeit ir vajadzība pēc draivera, kas apstrādā pilnīgi visu uz skaņas karti padoto (resp., nepieciešams draiveris), atšķirībā no konkurenta, kam ir tikai iTunes plugins, kas apstrādā tikai no iTunes padoto skaņu? Tādā gadījumā Java ir pilnīgi izslēgta no potenciālajām vidēm, pie tam draiveru (ne funkcionālā daļa) bus kardināli atšķirīga visās 3 sistēmās (XP, Vista+ un Mac OS). Šis ir ļoti sarežģīts projekts, ja vien programmētājam nav gatavi šabloni audio draiveriem visās 3 sistēmās un attiecīga pieredze.

Man liekas, ka tas ir tikai defaultais kodējums (kodējumus var paslēgt pašā phpMyAdminā). Man vismaz pat ar it kā pareizi uzslēgtiem kodējumiem nekas prātīgs nesanāca, bet ar veco versiju sanāca. Tiesa, šie eksperimenti man bija jau krietnu laiku atpakaļ, kad notika maiņa no MySQL 3 uz 4.1. Ja oriģinālajam autoram izdodas, tad pamāj šeit forumā, lai es zinātu, ka šī metode darbojas.

Uztaisi php skriptu, kas nolasa datus ar SET NAMES UTF-8 un ieraksta jaunajā ar SET NAMES UTF8. Otrs variants - lieto ļoti vecu phpMyAdmin versiju datu izvilkšanai, bet es no galvas nepateikšu sākot no kuras versijas uz leju bija derīgas. Piekrītu, ka šitādas problēmas ir "baigais černis".

Ja backends jau ar rakstīšanu vien netiks galā, tad būs baigās problēmas. Vari veidot spēli iekšēji tā, lai DB serveris netiktu visu laiku raustīts. Piemēram, izveido starpnieku pirms php (vai atmetot php vispār), kas nodrošina konekciju apstrādi no flash un kešošanu. Tas būtu kā serviss, kas saņem konekcijas, veic spēles mehāniku atmiņā un ik pa laikam ieraksta spēles stāvokli datu bāzē. Piemēram, visa spēlētāju informācja glabājas atmiņā, līdz ar to, konekcija, kas pieprasa spēlētāja informāciju, piemēram, naudas daudzumu, datu bāzi nemaz neaiztiek, jo serviss to atgriež no atmiņas. Serviss paralēli darbina threadu, kas visu informāciju cikliski pārstumj uz datu bāzi. Bet ja tas ir pārāk darbietilpīgi, tad vienkārši izstrādā gameplay tā, lai nebūtu masīva nemitīga ierakstīšana. Parasti jau spēlēs rakstīšana ir tad, ja veic kādu darbību - pārējais ir apskatīšana/lasīšana. Vienīgi action spēlēs rakstīšana ir vismaz tikpat intensīva kā lasīšana, ja taisi tādu, tad backends jāraksta līdzīgi kā aprakstīju augstāk - varbūt ne visai spēlei, bet vismaz nemitīgi mainīgajai daļai.

Kopumā nevar, jo pastāv anonīmie proxy, kas nekā neatzīmnē sevi kā proxy. Neanonīmos var detektēt pēc headeriem: http://www.roscripts.com/PHP_Proxy_Detector-75.html Principā var mēģināt slēgties klienta IP portiem klāt, lai pārbaudītu, vai tas nav proksis, bet tur ir tāda problēmu jūra, ka tas ir pilnīgi nepraktisks un neprofesionāls risinājums. Vēl vari mēģināt ar cookie sekot līdz vai vienam un tam pašam lietotājam nemainās visu laiku IP adreses... Bet ja lietotājs uzreiz ienāks caur proxy un nemainīs to, tad tu viņu neatklāsi. Kā arī tad, ja viņš iztīrīs cookies pirms proxy maiņas. Toties tu nepatiesi noķeris kā proxy lietotājus tos, kas tādi nemaz nav, piemēram, laptopus, kas pieslēdzas dažādiem bezvadu tīkliem. Īsā atbilde: nevar.

Jautājuma zīmes regeksos ir jāizbēdzina (?) $s = preg_replace("/\\?pager=[0-9]*/", '', $_SERVER['REQUEST_URI']);

Tā nav tipiska metode un, protams, ka uzkrājot datus un liekot datu bāzē visus uzreiz, būs aizture. Mēģini strukturēt sistēmu tā, lai nebūtu milzīga rakstīšanas slodze uz vienu DB serveri. Veic testus, lai pārbaudītu, vai vispār tagad nav veltīgs satraukums - varbūt pie korekti izplānotas datu bāzes tā slodze nav tik liela, kā liekas. Varbūt vari pastāstīt konkrētāk par projektu un ierakstāmajiem datiem? Sarežģītus, skeilojamus risinājums vajag diezgan reti.