Mr.Key

Roze, es pieķēros pie šī punkta "Bet nevis vienkārši darbu deleģēšana, bet tāda striktāka, konkrēta apakš uzdevuma izpildes fiksācija, kas būtu kā gandrīz kā līgums." Ar to sapratu, ka problēma ir pušu neizpratne par to, kas skaitās pabeigts vai nepabeigts, jo manuprāt, darbu deleģēšanas sistēmas piedāvā workflowus, kas atbilst projekta vadības vajadzībām. Ja nebija zināms par JIRA vai Redmine, tas arī automātiski rada jautājumus par to, kāda pieredze tad ir vispār? Kas vēl cits nav zināms? Visu, protams, var atrast un saprast, un laikam ejot, pierast. Šeit kaut kā cauri spīd tas, ka nevis programmētāji organizē savu darbu un projekta vadītāji netraucēti komunicē ar klientu caur saviem kanāliem, bet ka ir kaut kāda neskaidrība vispār. Lielākā plāksnē. Par projekta vadītāja lomu - piekrītu, ka to var uzņemties arī programmētājs, taču nevajag novērtēt šo lomu arī par zemu. Ar to, ka nodrošina darbu izpildi, es domāju, ka ir nepieciešams vidutājs, kurš menedžē klienta ekspektācijas un neitralizē programmētāju pārliecību, piemēram, neļaujot sasolīt par daudz vai ierēķinot rezerves, kā arī krīzes gadījumā kaut vai vienkārši nomenedžēt overtaimu vai atgādināt par prioritātēm. Nē, es nedomāju skubināšanu un steidzināšanu, kaut gan arī tas reizēm var būt nepieciešams. Es neesmu pārliecināts, ka programmētāji paši var sevi vadīt, vismaz ne attiecībā pret gala klientu. Ja tā ir tehniska komanda, kas darbojas lielāka projekta ietvaros kā struktūrvienība vai apakšuzņēmējs, tad jā. Bet jautājums, vai šī komanda nav jau kāda iepriekšēja projekta rezultāts, kas izgājis organizētu apmācību un treniņus. Atkal sanāk atgriezties pie tā paša - katra situācija ir savādāka. Atvērtā koda projekti ir mazliet cits stāsts kā klienta projekts, kur klients no savas puses rēķinās ar sagaidāmu rezultātu un lielāku problēmu gadījumā sarunās iesaistās juristi vai vienkārši tiek stiepti norēķini. Tāpat, projekts, kur tehniskā nodaļa sēž uz algas un pilda citas nodaļas pasūtījumus, un kritiskais jautājums ir nevis par biznesa modeļa noturēšanu, bet par to, kā mazāk krist uz nerviem, ir cits stāsts. Par pirmspēdējo un pēdējo rindkopu - iemeslu var būt ļoti daudz. Liek domāt, ka darbojies vidē, kur jau esi atfiltrēs no daudziem iespējamiem ekscesiem. Piemēram, ne visiem ir zināms vai pat saprotams, ka sapulces varētu protokolēt, utt. Vai zini, kāda ir sajūta, redzot neizpratnes pilnu lūgumu nesūtīt "kaut kādus protokolus"? :) Vai zini, kāda ir sajūta, kad esi 3 reizes pateicis, kas "tas nebūs", un tad saņemt jautājumu, vai tas jau ir uztaisīts? Es ar šādām lietām esmu saskāries kā programmētājs un redzējis, kā to risina projekta vadītāji, un patīkamāk to ir risināt komandā ar labu projekta vadītāju. Tāpēc arī šeit izsakos, lai aicinātu padomāt. Var jau būt, ka visur viss jau ir sakārtots, visi domā vienādi un atliek tikai uzinstalēt sistēmiņu, lai viss ietu pa sviestu. Par tūļiem - bez minētajiem, tāpat projekta vadītāji izmanto Excel un epastu, Google Docs... anything, that works. Šajā gadījumā vērtīgi būtu palasīt grāmatiņas "Informācijas sistēmu projektu vadība", kur aprakstīts darba uzdevumu organizēšanas process (kad studēju, tādas noteikti bija), parunāties ar juristu (starp citu, nemaz nav dārgi un arī pašiem pašapziņa uzlabosies). Visdrīzāk, rezultātā līgums vai pielikums, kurā aprakstīta darba uzdevumu vadības plūsma, norāde uz sistēmas adresi, pieņemšanas - nodošanas kārtība. Piemēram, līgumos atrunā kontaktpersonas un e-pastus - tā nav informācija uzziņai, tā ir informācija par to, ka konkrētā kontaktpersona nevar pateikt "es neko nezinu", ja ir informēta par darbu norisi.

Alnis, tas viss ir skaidrs, bet Tev nav skaidrs, ka projektā pietrūkst sakarīga projektu vadītāja. Tu esi iedomājies, ka izmetīsi šo posmu un aizvietosi ar sistēmiņu, kas nesīs automātiskus panākumus. Nebūs! Gaidi ziepes un nepatikšanas. Projekta vadītāja uzdevums ir vadīt komunikāciju ar klietnu, lai viņš saprot, kas tiks izdarīts, kas netiks, utml. Klasika - programmētājs ieurbies darbos, neatliek laika veselīgai komunikācijai, klients sāk nervozēt, programmētājs nemāk izskaidrot, cik daudz darba izdarīts, utml. Gadās, ka gala rezultātā projektu pārņem citi, atnāk sakarīgs projektu vadītājs, klients priecīgs, tas nekas, ka viss maksā daudz dārgāk, toties process notiek. Tāpēc arī minēju, ka nevajag tēlot, ka esi iemeties lielbudžeta projektā un kaisīt pērles cūkām. Ak jā, vēl arī tas, ka jo maksātspējīgāks klients, jo vairāk tolerē ar realitāti un mazāk sagaida, ka projekts par <10k (vai pat 1k) būs shopify vai ebay līmenī. Ne līgums, ne sistēma šo problēmu neatrisinās. No pieredzes daudzos projektos, ar dažādiem klientiem, dažādos uzņēmumos - uzdevumu sistēma pati par sevi nenodrošina darbu izpildi. To nodrošina projekta vadība, kas seko līdzi, kas reizēm izskatās, ka vispār dara nevajadzīgas lietas, bet beigās izrādās, ka tās ir pat ļoti vajadzīgas. Projekta vadības daļa tāmē ir 10-20%. Katrā projektā pret to ir atšķirīga attieksme - ja vienā klienta pusē ar uzdevumu sistēmu strādās 3 cilvēki un rakstīs komentārus, citā projektā var gadīties, ka sistēmu lietos paši programmētāji sava darba organizēšanai, jo klients negribēs/nevarēs "lieku čakaru".

Tu kas, diletants, vai? Parasti līgumā ir atrunātas kontaktpersonas vai piebilde, ka darbu organizēšanai izmanto kaut kādu sistēmu. Tālāk jau katrs gadījums ir individuāls. Ja lieta tiešām nopietna, tad var vienoties par darba uzdevumiem, kas tiek noformēti rakstveidā un ir kā līguma pielikumi. Jira un tamlīdzīgie kā iniciators un kad vienojas par darāmo - top pielikums, puses paraksta, utt. Īsi sakot, kā parasti. Ja jau strādāji terasē ar skatu uz Daugavu, tur tādām lietām bija jābūt ikdienai, ne? Taču šāda apjoma projektiem budžeti ir tādi, ka šos jautājumus risina dedicated jurists. Ja tas jābaksta forumā, tur kaut kas īsti nav. Visdrīzāk - projekta nozīmīgums ir pārvērtēts vismaz 10, ja ne 100x. Tomēr diezgan pamatīgs "management overhead" un ja projekts ir <100k, tad kaut kas nav līdz galam saprasts.

Parasti tas notiek tā, ka puses vienojas par darba organizēšanu. Nepastāv tāds mehānisms, kā "kaut kāda sistēma, kurā ievadītie uzdevumi kļūst par tādu kā līgumu". Darbs tiek paveikts tad, ja to dara, un to, lai tas tiktu izdarīts, nodrošina vienošanās un savstarpējā komunikācija. Ja vienošanās būs abām pusēm izdevīga, darbi tiks darīti, norunas tiks pildītas. Ja ar šo nesokas, tad problēma ir citur, nevis tajā, lai sistēmā būtu uzraksts, ka "katrs darba uzdevums ir tāds kā līgums". Man nojauta liek domāt, ka risinājums būtu darbu organizēšanu uzticēt kādam citam. Izskatās pēc diezgan mazas pieredzes. Ātri saiesiet konfliktā.

Ok, nezināju, kas ir NWJS. Tagad zinu, kas ir Electron. sqlilte pusei nevajag skatītis uz kaut kādu replication fīču? failu mapītēm - uz kaut kādu folder upload? https://www.npmjs.com/package/remotecp Interesanti vispār. Mazliet nesen briedu līdzīgam projektam, bet iestājās taimauts, jo nav laika, bet kā reiz šāda vajadzība bija, tikai cita specifika.

CREATE TABLE product_categories id, name, etc. CREATE TABLE product_category_links category_id, parent_id, <-- NULL pirmā līmeņa kategorijai, product_categories.id 2. un zemāka līmeņa kategorijām. position etc <-- kārtošanai Pirmā līmeņa kategoriju atlase: SELECT pc.* FROM product_categories pc JOIN product_category_links pcl ON pc.id = pcl.category_id WHERE pcl.parent_id IS NULL; Otrā līmeņa kategorijas: SELECT pc.* FROM product_categories pc JOIN product_category_links pcl ON pc.id = pcl.category_id WHERE pcl.parent_id = $this->id ORDER BY pcl.position; ORM gadījumā - jāpēta FW dokumentācija, bet idejiski: class Categories. ... { // relations public function getParents() { return $this->hasMany(Categories::className(), 'id' => 'parent_id')->via( ... kur norāda, ka 'category_id' = this.id) } public function getSubcategories() { return $this->hasMany(Categories::className(), 'id' => 'category_id')->via( ... kur norāda, ka 'parent_id' = this.id) } // utt. } Tad attiecīgi: $category = new Category(); $category->parents .... $category->subcategories + statiska metode top level kategoriju atlasei, atkarībā no ORM. Tas pats many()->via(), kur parent_id IS NULL. Glabāt atsevšķā tabulā 1. līmeņa un 2. līmeņa kategorijas nevajag. Kādā brīdī gribēsies 2. līmeņa kategoriju izcelt pirmajā līmenī. Ar šo variantu tas iespējams tā, ka viena kategorija var būt gan 1., gan 2. līmeņa kategorija: Augļi Akcija! Āboli Banāni Etc. Konfektes Akcija! Akcija!

Sazināsimies ar tiem kandidātiem, kuri tiks aicināti uz 2. atlases kārtu

Pilnīgi piekrītu - zinošs cilvēks zinās kas un kā! Un prieks, ka ir neliela pieredze ar SEO! Un noteikti, ka ir kāds, kas zinās labāk! Sadosimies visi rokās, lai viss notiek labi!

Šodien vienkārši cilvēki saprot, ka darot darbu, ir jāpelna un jāpelna ir darot darbu. Nevis jānodarbojas ar gadiem ilgu priekšspēli - visu laiku mācīties un pierādīt sevi un tad, kad beidzot saņem drosmi, tad atklāt, ka viss jau sen ir atdzisis. Šodien jaunie tāpat arī apgūst visu, tikai par to saņem algu. Iespējams, lielāku, nekā tu tagad ar visu savu pieredzi. Un tie tavi klienti tevi pašu izmetīs kā kaķēnu uz ielas, kad viņiem pieklauvēs labāks piedāvājums. Vienīgais, kādēļ viņi ar tevi sadarbojas, ir tas, ka visur citur viņiem prasa pavisam citas summas (ja ne 10x, tad vismaz 5x lielākas). Augstākminētie secinājumi ir pārbaudīti praksē.

Laravel un Yii ir radikāli savādāks, sākot no koda, turpinot ar dokumentāciju, community, projektiem un autoriem, droši vien arī to, ka daudz kas no tā, kas Yii ir Yii, Laravelī ir komponente. Labāk nesalīdzināt - man personīgi ātri uznāk depresija, ja salīdzina. Vienkārši, jāpārslēdz domāšana.

Šis ir tiešām atmaskojošs fakts. Visa pasaule sāk pāriet no Laravel uz Yii. Vairāku pilsētu pašvaldības jau izlēma pāriet uz Yii. Priekšrocības ir neizmērāmas.

+briedis Bet vispār, meklēt jau neviens neliedz... (diez vai lapa ir kaut kas, kas pasaulei līdz šim pietrūka)

Eloquentam nav nekādu īpašu priekšrocību, turklāt composite PK atbalsta trūkums ir smieklīgs! To atbalsta pat arhaiski brīnumi. Eloquent ir reliģisks, nevis praktisks risinājums. Vajadzības pēc viņa nav, ja neskaita to, ka daži autori apmierina savas ambīcijas.

Diezgan nepievilcīga situācija - ļoti zema likme (freelance pašam par sevi jāmaksā, pašam jāmācās, utt), kādam līst samudžinātos projektos - why? Why? WHY? Pats vispār reāli tici tam, ka kāds jaunietis tagad atnāks un pilnā nopietnībā turpinās tavus snauduļojošus projektus? Tur darāmā ir tik pat un vēl vairāk, cik, veicot pareizas izvēles, ir līdz kaut kam šādam: https://twitter.com/taylorotwell/status/754473140323966977 Why iesācējam apgūt kaut kādus vecus kodus? Bezjēdzīgi... Domāju, ka vari pat nesapņot.

Tāpēc, ka retro manta. Īstā klaviatūra no laikiem, kas pirms plēves darinājumu ēras. Principā, mehāniskā klaviatūra skaitās vērtība. Pats arī uz jautājuma zīmes turu Mitsumi 90-to gadu laika klaviatūru. Nevaru saņemties izmest, lai gan Ebayā tādas pa 5 EUR.

Ja nepareizi saglabāti pašā datubāzē, tad var konvertēt, mainot kolonnas collation. Precīzi neatceros, bet šajā gadījumā bija jāmaina 2x. Vienreiz no utf8_general_ci uz to swedish, kas defaultais (latin1_swedish_ci vai kaut kā tā), tad atpakaļ uz utf8. Šis vairāk kā pavediens. Dažas DB esmu tādā veidā salabojis. Ja ir vēlme, tad jāpēta sīkāk. Piemēra failu man nav, bet izdarīt to var.

Nu jā, bet kur tu viņu redzi pareizi un kur- nepareizi? Web lapā? Konsolē? phpMyAdmin? Ja web lapā, tad visticamāk, nav pareizs connection charset. Ja pieslēdzies ar mysql funkcijām, tad jāmeklē, kur pieslēdzies pie DB un tur konfigurācijas parametros jānorāda, ka connection charset ir utf8 (nevis utf-8). sk. mysqli_set_charset().

Kas ir tas, kur viņi ir redzami normāli, un kas ir tas, kur viņi ir redzami otrajā variantā?

Neesmu eksperts šajā ziņā, bet par pašsaprotamu uzskatu, ka: 1) ORM ir lēns. Datubāzes SELECT tur ir pati mazākā daļa, jo apkārt ir baisi daudz visa kā, kas saliek datus objektos, ņemas ar metadatiem, utt. 2) PDO prepare utt ir lēnāki par tiešu SQL. Man šķiet, ka PDO nolasa saistīto tabulu metadatus (struktūru), lai zinātu, kādi ir lauku tipi, un izveidotu statement. 3) SELECT no indeksēta lauka būtu jābūt dažām milisekundēm. Kā arī man ir iespaids, ka Tu ne pārāk labi orientējies datubāzēs. Sāc ar to, ka pastrādā ar RDBMS vispār bez PHP vai jel kā cita. Piemēram, RDBMS pasaulē nav tāds "find one". Ir atlase pēc unikāla lauka, kur pēc definīcijas ir iespējams tikai viens vai neviens rezultāts, vai arī atlase ar LIMIT 1. Nākošais solis ir welcome to the world of different DBs, kur katrai datubāzei un arī katras datubāzes dažādām konfigurācijām ir atšķirīgi plusi un mīnusi. Ir vesela joma, kuru sauc par performance tuning (vai performance optimization), kas ir DB pieskaņošana konkrētajai aplikācijai. Pilnīgi normāla un pašsaprotama procedūra. Pilnīgi normāli un pašsaprotami, ka ar standarta iestatījumiem veiktspēja nav ideāla.

Labs priekš manis - labas krāsas, ergonomiska izšķirtspēja (bilde lielāka), LCD tehnoloģija kaut kā vieglāk acīm. To atšķirību var just, ja mēra nogurumu pa dienām un nedēļām. Un tik mazs nav, pietiek vieta tieši vienai lietai, uz kuru fokusēties. Daudzos logos vienlaicīgi nespēj strādāt neviens. Cilvēki vienkārši izliekas, lai izskatītos kruti.

jurchiks, nav vērts, Tu un es viņus nesapratīsim. Tas vienkārši ir citāds cilvēku tips. Viņiem tiešām tie 2 un 3 monitori palīdz. Man šobrīd vispār ir 2004. gada 19'' 1280x1024 lcd un tas speciāli.

Tad Tu esi iemācījies spāņu valodu? Tas D-Eiropas zemēm raksturīgi, ka ja runā vietējā valodā, tad jau ir baigi forši, bet ja nē, tad es pat nezinu. Biju reiz aizbraucis ciemos pie paziņas, kurš labi iekārtojies citā D-Eiropas valstī, viņam viss patika un brīnījās, kāpēc neesmu gatavs tur palikt. Bet viņš tur tik tekoši runāja, un arī vizuāli izskatījās tā, ka vietējie neticēja, ka viņš nav tur dzimis un audzis. Tā nu viņš tur uz ielas ar ikvienu varēja sadraudzēties un garlaicīgi nebija. Man gan gluži pretēji, tomēr jūtos kā vēss ziemeļnieks.

Dārgāk ir kā šeit. Pēc tagadējā iespaida, ja gribētu atrast Rīgas centrā, ar kādiem 500 EUR būtu jārēķinās, ārpus Rīgas jau tā izvēle arī nav liela, bet 200-300 EUR varētu iekļauties. Ja Latvijā nebārstās ar $, tad vispār var ļoti labi dzīvot kaut vai bāzējoties šeit un par summu, ko citi atstāj piektdienas vakarā krogā, nedēļu paceļot, izmantojot LV pases priekšrocības. Un, par algām runājot, vēl nupat paskatījos, ka nekādus zelta kalnus jau nekur neber. 2,8 - 3,5 K ir 32-42K gadā, kas uz Eiropas fona ir normālā līmenī.

Ja tas ir uz rokas, tad labs cipars. Kas piedāvā? Spānijā vispār dzīves dārdzība ir +/- LV, nezinu par īri.

Kā kas liedz? Aizspriedumi liedz. Vispār jau, daudz kur dzīvē pietiek, ja kāds pasaka - "Tu to vari! Dari! Būs labi!". Bet tas var tiešām cilvēku aiznest ļoti tālu, tāpēc mazie cilvēciņi viens otru nievā un velk uz leju, lai kāds neuzrāpjas par augstu. ;) Kā iemācīties? Rēķinies, ka vajadzēs laiku un dienas, nedēļas paies bez būtiska progresa. Kaut ko nopietnāku varēsi rakstīt tikai pēc mēnešiem. Bet sāc tagad un ej uz priekšu. Mozilla Developer Network var būt labs sākums.