101111

Mazliet resnākiem freimworkiem dokumentācijai ir nozīme, bet poplārajiem freimworkiem ar to pārsvarā nav problēmas. Piemēram tam pašam Symfony2 ir virkne labu komponentu, kas atrisina standartproblēmas, bet bez labas dokumentācijas daži no tiem būtu tiešām grūti izmantojami. Noteikti jāpiekrīt, ka projekta tehnoloģiju izvēlē lielāks svars ir komandas dalībnieku viedoklim nekā anonīmu "ekspertu" apgalvojumiem internetā. Ja komandas dalībnieki var vienoties par freimworku, ar kuru ērti strādāt un redzēt plusus un mīnusus konkrētā projekta kontekstā, tad tas jau ir daudz, arī, ja freimworks nav tik modīgs.

Ja tava produkta galvenā priekšrocība attiecībā pret linkedin ir tikai labāks vai skaistāks UI/UX, tad kaut vai minimālas tirgus daļas iekarošana ir bezcerīga. Piemēram tāda nesmuka miskaste kā ss.lv joprojām ir nepārspēts līderis savā sfērā. P.S. nosaukums tiešām neveiksmīgs.

Šie censoņi ir OK http://www.styleweb.lv/

Šī ideja ir ļoti attālināta no reālās pasaules apstākļiem. Ja tavus pakalpojumus izmanto puslīdz saprātīgi cilvēki, tad ātri vien tavi viltīgie nodomi nāks gaismā. Bet par to maksāšanu par izdarīto. Es esu pats piegādājis programmēšanas nodevumus gan izstrādes kantoriem, gan pa tasino klientiem. Vienmēr samaksa ir notikusi uz plānoto nodevumu bāzes. Pirms uzdevuma uzsākšanas vienojamies par paredzamo termiņu un samaksu. Klients ieplāno savā budžetā attiecīgus izdevumus, programmētājs savā darba plānā noteiktu laiku. Jāsaka, ka reālajā pasaulē, pēc šāda modeļa, tu nevis cītīgi kodējot izdarīsi darbu ātrāk par plānoto un baudīsi apmaksātu brīvlaiku atlikušajā laikā, bet gan pārtērēsi savu laiku stipri virs sākotnēji novērtā un samaksu saņemsi tādu pašu kā novērtējumā. Iemesls tam ir tāds, ka izdarot novērtējumu tu nevari paredzēt virkni nianses pie kurām būs jāpiestrādā pēc tam kad pamata prasības būs izpildītas (it īpaši pie lielākiem uzdevumiem). Vai arī vari, bet ieguldot rūpīgu analīzes darbu, pēc kura nāk klajā realitātei pietuvināts novērtējums, bet tas atkal uzrāda tik lielus izdevumus, kurus pasūtītājs nav gatavs maksāt. Kā arī ir vēl tāds apstāklis, ka programmēšana nav vienīgais kas patērē laiku. Prasību apkopošana, analīze, testēšana, kļūdu labošana un tikšanās ar pasūtītāju prasa ne mazāk laika. Ir noteikti kantori kas izmanto šo programmatūras izstrādes īpatnību, lai saviem pašu darbiniekiem maksātu mazāku atalgojumu to skaisti nosaucot par Performance Based Salary un pasniedzot kā iespēju pelnīt vairāk. Taču realitātē iznākums ir pretējs. Tapēc esmu priecīgs, ka varu pelnīt naudu vairs neesot iesaistīts pasūtītāja-klienta attiecībās.

So true

Primajā punktā visticamāk runa iet par Accenture Ļauno impēriju

Visas tās fīčas izklausās loģiskas un interesantas, bet vai vajadzīgas un izmantojamas reālās dzīves komandai reālos darba apstākļos, tas cits jautājums. Es tā padomāju, kas gan komandas darba organizācijai ir vairāk vajadzīgs bez uzdevumu vadības sistēmas, skype, dropbox un citiem labi zināmiem tūļiem... Droši vien nekas. Dizains arī varēja būt glītāks.

Koda kvalitātei ir nozīme tikai tad, kad projektam ir paredzama aktīva uzturēšana un regulāri papildinājumi. Vai zini kādu informatīvu lapeli vai blogu, kam tas viss ir vajadzīgs? Bāzšanās ar freimworkiem un labo kodēšanas praksi šādos projektos, tā vietā, lai paņemtu un uzinstalētu Wordpress, ir zemē nomests laiks.

Ko nozīmē šis? 'children' => '0' Tas ir skaits vai kas? Tas neatbilst tam serializējumam ko sākumā minēji.

Pārveido sarakstu koka struktūrā $allItems = $query->result_array() foreach ($allItems as $key => $value) { $allItems[$key]['children'] = array(); } $addChildrens = function($item) use ($allItems, & $addChildrens) { foreach ($allItems as $i) { if ($i['parent_id'] == $item['id']) { $i['children'][] = $addChildrens($i); } } return $item; }; $tree = array(); foreach ($allItems as $i) { if ($i['parent_id'] == 0) { $tree[] = $addChildrens($i); } }

Principā Roberts visu jau pateica. Ievērojams produktivitātes grāvējs ir neskaidri nodefinēts sagaidāmais rezultāts un nepārtraukta monotonu uzdevumu raušana noved pie izdegšanas. Vēl produktivitāi var ietekmēt neapmierinātība pret darbavietas specifiku (neadekvāts atalgojums, jāuztur nevīžīgu/paviršu/dumju kolēģu rakstīts kods, utt). Vispār jau gribētos teikt ka Pomodoro un tamlīdzīgas tehnikas drīzāk ir vajadzīgas tādiem kuriem darbs ir tik garlaicīgs, ka nepieciešams izdarīt ievērojamu piepūli, lai uz to piespiestos. Tas arī noteikti nepalīdzēs kad produktivitāte tiek zaudēta to iemeslu dēļ, kurus aprakstīju pirmajos teikumos.

Iesaku MPDF.

Iekārtojies kādā darbiņā. Strādāsi ar tehnoloģijām un metodēm ko nosaka projekta specifika. Tad būs citas tēmas par ko lauzīt galvu.

Kāda ietekme te vēl vajadzīga. Tas jau tikai tāds kārtējais vadlīniju komplekts vien ir - ja patīk tad izmanto to, ja nē tad meklē ko citu savai gaumei atbilstošāku. Manai gaumei tas lielā mērā atbilst, tāpat to izmanto respektabli PHP freimworki.

Pamatojums?