Kaklz

Ja ir žēl pirkt īstos Mac dzelžus, tad vari skatīties hackintosh virzienā: http://www.hackintosh.com/ jeb likt MacOS uz citiem dzelžiem. Pats to neesmu darījis, bet zinu cilvēkus, kas ir darījuši. Ja tu iedomājies, ka viens pats uzbūvēsi superaplikāciju un kļūsi par miljonāru, tad labāk sāc domāt kādu citu plānu, kā tikt miljonāru sarakstā. Brīnumi nenotiek un Appstore 90% naudas ievāc 10% izstrādātāju, pārējos 10% naudas sadala 90% izstrādātāju, starp kuriem visticamāk būsi arī tu. Lasot starp rindām - tas ir mīts, ka ar aplikāciju izstrādi iOS var pēkšņi kļūt stāvus bagāts.

Visticamāk, ka tev varētu interesēt public_html saturs. Tur parasti liek publiski pieejamās lietas.

Nepierādāmus ienākumus nav grūti uzzīmēt :). Man bija doma piezīmēt kādu 5-10k algu, bet mazliet apžēlojos par aptaujas autoru.

Pārcēlu kārtējo klasisko darba sadaļas offtopic šeit: http://php.lv/f/topic/8291-darba-sadalas-offtopiks/page__st__300

6. testā bija pāris kļūdas manā pusē, kuru rezultātā netika pieņemti arī pareizie rezultāti. Šobrīd kļūdas ir novērstas un pāris cilvēkiem jau ir izdevies tikt galā. Ja nu tomēr vēl neizdodas, vajadzētu uzmanīgi apskatīties uz to, kā izskatās parauga dati.. Papildus autorizācijas mehānismi tiks ieviesti, ja būs iedvesma to pasākumu attīstīt tālāk. Teorētiski, ja iespringst un uztaisa koda pareizības pārbaudi arī servera pusē, tad varētu pat izvērsties un programmētājiem likt izmantot kādu SVN/GIT, lai stumtu savus risinājumus uz servera. Tiem, kas līdz šim nebūs lietojuši kādu versiju kontroles sistēmu tas varētu būt vērtīgi.

PHP Tester - zināšanu ieguves / pārbaudes risinājums PHP programmētājiem http://webtech.lv/phptester/ PHP Tester ir neliels eksperiments ar domu “fail early, fail often”, jeb ar minimāliem līdzekļiem un laika ieguldījumu radīts risinājums, kuram ir nepieciešams saprast publikas reakciju un nākotnes potenciālu, iespējams, globālā mērogā. Ko var darīt ar PHP Tester? Pārbaudīt un salīdzināt savas zināšanas ar citiem dalībniekiem. Šobrīd aplikācijā ir pieejami 6 testi, iebūvēts dalībnieku TOP, kurā var redzēt savu rezultātu attiecībā pret pārējiem dalībniekiem. Apgūt jaunas zināšanas. Ja kāda no problēmām iepriekš nav risināta, tad pilnīgi noteikti tiks iegūtas jaunas zināšanas, šobrīd gan ar testiem vajadzētu varēt visai vieglit tikt galā jebkuram kaut nedaudz pieredzējušam PHP programmētājam. Tā kā šai sistēmai var visai viegli pievienot papildus testus, tad arī testu kopa un apgūstamo zināšanu apjoms nav ierobežots. Atliek vien izdomāt pietiekami interesantus testus. Meklēt darbiniekus. Šobrīd programmētājiem, kas tiks galā ar vismaz 4 testiem tiks piedāvāts uzmeklēt kādu darba devēju Latvijā. Kāpēc lai šādu sistēmu neizmantotu arī citi uzņēmumi? Izdomā savu testu, nopublicē sistēmā un saki, ka runāsi tikai ar tiem, kas būs šo testu izpildījuši. Vai arī vienkārši saki, ka tevi interesē tikai darbinieki, kas šajā sistēmā būs izpildījuši vismaz X testus. Papildus - servera pusē ir iespējams redzēt programmētāju izmantotos risinājumus (programmas kods tiek sūtīts līdzi uz serveri). Tādējādi darba devējs var novērtēt, cik saprātīgi cilvēks ir programmējis un kāds tieši ir bijis izvēlētais risinājums. Atsauksmes laipni aicinātas.

Lielos vilcienos - priekš kam lieki tērēt laiku (gan manu, gan head-huntera), ja es skaidri zinu, ka uz US tāpat nepārvākšos, jo tas nav mans aicinājums? :)

Zinu, un es lasu ne tikai saikļus, bet pilnus teikumus. Manas zināšanas C++, Java ne tuvu nav tādas, lai es sauktu tās par "expertise" (pāris vienkāršu algoritmiskas dabas uzdevumu atrisināšana universitātē nekādi tam nekvalificējas). Ja būtu prasība par PHP eksperta līmeni, tad es varētu domāt tālāk.

Es ar viņu aprunājos, bet tālāk par runāšanu neko nedarīju. Pēc sīkākas info pieprasījuma saņēmu atpakaļ šādu: Tā kā es nerunāju ne C++, ne Java (prasīts pie requirements), ne Python, ne arī Perl valodās, tad baigi mēģināt izpētīt situāciju tālāk nebija vēlmes.

Vienkāršākajā gadījumā: index.php: <?php $variable = 'test'; include('header.php'); header.php: <?php echo $variable Viss pārējais jau ir variācijas par tēmu - layouti, templeiti, mvc, hmvc, utt. Doma saglabājas iepriekšējā - tu reāli neizvadi headeri, pirms neesi izpildījis skriptu un piešķīris konkrēto vērtību.

diskusijam.lv ?

Ir vērts pievērst uzmanību pāris limitiem, piemēram: "Max uniq visitors per domain per 24h". Ņemiet vēl šos lieliskos hostingus. Radīsi labu saturu, kas kaut kur sāks iegūt kārtīgu trafiku un tad potenciālie apmeklētāji saņems pretī "account is suspended" tieši tajā brīdī, kad tava lapa būs "uz viļņa" :)

Es kaut kad esmu qmail krāmējis. Kopš tā laika visiem iesaku nečakarēties un izmantot lielisko iespēju mailu turēt Google Apps.

Tā kā pagājušajā nedēļas nogalē apmeklēju Agile Riga Day 2012, tad tīri intereses pēc pajautāju arī par reālās dzīves situāciju ar Scrum izstrādi. Tā kā man nav pieredzes ar formālu Scrum procesu, tad jautājumi bija tīri no sērijas "es zinu, kā tiek darīts pie mums, es zinu teoriju, bet kā tas reāli notiek uzņēmumā, kas seko šim procesam?". Mums nav ieviests formāls Scrum vai kāds cits no Agile procesiem, taču lielos vilcienos darbs mums norit visai tuvu šiem procesiem - backlog glabājas BaseCamp, ir regulāras koda relīzes uz produkcijas vidi - bieži vien pat n reizes dienā, ne tikai bugfix, bet arī jaunas fīčas. Mums nav konkrēti definētu sprinta periodu, tāpat mums nav daily standup meeting un vēl pāris citas procesu raksturojošas lietas. Pie katra jauna izstrādes procesa ieviešanas var sagaidīt kaut kādu programmētāju pretreakciju un manuprāt tas ir tikai normāli. Ja programmētājs nav radis ik dienu stāstīt un rādīt padarīto, tad pretreakcija noteikti būs.

Tāpēc es saku, ka viņam varētu būt uzņēmēja talants :)

Kad tev darbā priekšnieks iedos uzdevumu uzrakstīt prasību specifikāciju, arī forumā meklēsi cilvēkus, kas par maksu izdarīs to tavā vietā? Varbūt neesi izvēlējies īsto studiju programmu un tev vajadzēja doties studēt uzņēmējdarbību? Izskatās, ka tev varētu būt talants :)

Tīri intereses pēc pāris jautājumi par Scrum un projektu: *) cik cilvēku ir komandā? *) cik garš jūsu gadījumā ir sprints? *) Jums produkta relīzes uz produkcijas vidi notiek tikai sprinta beigās, kad teorētiski viss sprinta backlog ir pieveikts, vai arī relīzes uz produkcijas vidi notiek neatkarīgi no sprinta sākuma/beigām? Teiksim viena sprinta laikā ir iespējama arī situācija, ka 2 nedēļu laikā ir piemēram 10 relīzes uz produkcijas vidi? *) ko darīt ar steidzamajiem darbiem? Teiksim sprints ir 2 nedēļas, sprinta backlog ir sakrāmēts un tad tu izdomā, ka ir kāda supersvarīga fīča, kuru vajadzētu ieviest ASAP. Vienkārši metam iekšā sprinta backlog un upurējam kaut ko citu? Ko darīt, ja šādas situācijas kļūst regulāras? *) vai jūs veicat ikdienas kopā sanākšanas ar mikro-atskaitēm par padarīto / plānoto? Ja jā, tad vai nav tā, ka daļu no programmētājiem tas kaut kādā veidā kaitina, viņi to uzskata par nevajadzīgu? Ar domu - "es jau 3. dienu kodēju šito un liec tu mani mierā, ļauj strādāt." *) Kas ir tie rīki, kā jūs pārvaldat scrum procesu? Kādi web bāzēti rīki?

Nepārlasīju visas 4 lapas, bet vai tu esi sapratis, kas tieši ir tas, kas tev neļauj justies apmierinātam darbā? Pats darbs, ko dari, priekšnieks, kolēģi? Kas ir tas, kāpēc tieši tu negribi no rīta celties un iet uz darbu?

Un ja nu nerada, tad vēlviena vientuļā māte ar nelaimīgiem bērniem?

Gudriem.lv, piemēram, runā ar visiem satura īpašniekiem, lai tie piedāvā savus datus viņiem ērtā un vienotā formātā. Kā rezultātā programmētājam darbs būtiski tiek atvieglots. Tā būtu pirmā lieta, ar kuru ir jāsāk un no kuras ir būtiski atkarīgs gan projekta izstrādes laiks, gan arī to, vai kāds vispār to būs gatavs uzņemties darīt, cik ilgu laiku tas prasīs un galu galā kāda būs gala produkta kvalitāte. Ar domu - ir ļoti liela starpība, vai dati ir jākasa ārā no parastas web lapas, vai arī katram apstrādājamam portālam dati ir pieejami vienotā formātā.

Lielos vilcienos izskatās, ka bez kardinālām pārmaiņām nekādā jēgā tu netiksi. No malas klausoties izskatās pēc klasiska cilvēka izdegšanas (burnout) gadījuma, kas starp programmētājiem nav nekāds retums. Vienīgā nianse, ka reti kurš ir spējīgs to atzīt un pateikt, "jā, esmu izdedzis". Nezinu vai mūsu valstiņā ir kāds speciālists kas ar to nodarbojas, taču ja ir, tad droši vien ir vērts parunāties. Tāpat ir arī dažādi cilvēki, kas saucas "karjeras konsultanti", kas palīdz saprast, ko tieši tu varētu darīt un kur tu gribētu virzīties. Jāatzīst, ka man pašam arī ir bijuši brīži, kad esmu palasījis gan vairākus rakstus, gan arī pāris gudras grāmatas par šo tēmu, bet pagaidām (iespējams, ka lasīšanas/izglītošanās dēļ) liekas, ka viss ir daudz maz mierīgi.

nu gan tu stāsti pasakas. DNS maiņa nu ne tuvu neaizņem nekādas pāris dienas. Lielai daļai lapu var pilnīgi mierīgi nomigrēt visu tā, ka klients pat nepamanīs.

Cita starpā es attiecīgās metodes tavā piemērā sauktu getList(): class News_Model extends Model{ public function getList(){ } } class Page_Model extends Model{ public function getList(){ } } Tad pēc tam nebūtu jādomā par to, kāds nu kurai metodei nosaukums, jo objekta nosaukums jau ir klases nosaukumā - News/Page: $pages = new Pages_Model(); var_dump($pages -> getList());

Slēdz droši iekšā. short_open_tag nav nekas slikts.

short_open_tag kopš PHP 5.3.x liekas ir izslēgts pēc noklusējuma. http://php.net/manual/en/ini.core.php