Jump to content
php.lv forumi

Atrasts internetā


briedis
 Share

Recommended Posts

Saprotu, ka CV var būt arī LinkedIn vai ka ir pārrunas, un arī ka var būt jāizvēlas no vairākiem, vienkārši neuzskatīju to par vajadzīgu uzskaitīt. Interesanti, kas ir tie kritēriji? Tie ir kaut kādi īpaši vai, kas man liekas pašsaprotami, atrašanās vieta, darba laika iespējas, darbavieta, projekti, utt. Un ko gan tas viss dod, ja rezultātā tāpat jāstrādā ar WP? Izklausās, ka sākumā tas nebija zināms. Un vai ir pārdomas par to, cik lielas iespējas tagad ir nokancelēt esošo izvēli un iet uz otru vietu? Ja lasa rakstus, tad uzņēmumi ļoti cīnoties par talantiem, tad jau tikai viens zvans un aidā, un viņi priecīgi, un arī tu priecīgs.

Atrašanās vieta/darbavieta, protams, ir pats pirmais, jo braukāt ar sabiedrisko uz, piemēram, Pļavniekiem katru dienu netaisos, daudz laika dienā zaudētu tādējādi. Tāpēc izvēlos vietas, kur ofiss ir max. 30 minūšu attālumā.

Darba laiks - pats par sevi, diezgan brīvs. Esmu baigā pūce, man 9-17 neder.

Projekti gan mani nekad nav interesējuši. Es jautāju konkrēti par izmantotajām tehnoloģijām/freimworkiem, un kad lieku pats savus darba sludinājumus, tur konkrēti minu, ka ar Wordpress netaisos strādāt. Šeit faktiski sanāca, ka čaļi bija to punktu ignorējuši, kaut gan pat intervijā es to minēju.

 

Mani "custom search parameters":

1) PHP versija (ja < 5.5, tad nav labi, nav progresīva kompānija)

2) Development environment (tā kā pārsvarā esmu ieinteresēts darbā no mājām, tad kaut kas tāds kā "visiem darbiniekiem kods ir uz centrāla servera" ir nepieņemams variants; vēl, protams, skatos IDEs/editorus, varbūt kkādus tūļus, cik nu atklāj info - piemēram, ja viņi saka, ka izmanto daudzās vietās kkādu softu, kurš prasa specifiskas zināšanas, un man par to nav vispār nekādas sajēgas, tad tas ir mīnuss manā skatījumā)

3) Code style (starp citu, Dyninno internal code style bija tīri tā neko, tikai neviens reāli viņu neieturēja :D)

4) Commit workflow (visi kommito masterā un merdžo paši (potenciāls mīnuss, atkarībā no team size - 1 cilvēkam jau tā kā pofig), vai arī katram savs branch/fork + pull requesti (pluss))

5) Code reviews (vai kas tāds vispār notiek, cik bieži, kas to dara - IMO ideālā variantā katru nedēļu kopā savācas un reviewo padarīto, iesaka cits citam uzlabojumus, iemācās kko jaunu, lasot svešu kodu - reāli pēc manas pieredzes Latvijā neviens neko tādu nedara, kas ir gaužām skumji)

6) Testing (vai tas notiek, kas to dara, cik bieži/cik nopietniem uzdevumiem - bija viena darba vieta, kur testēšanu veica dedicated cilvēks, un pirms viņš nebija apstiprinājis izmaiņas, nedrīkstēja pat kommitot, kas man bija reāls WTF moments; tas čalis bija reāls bremze, sīkākās izmaiņas testēja vairākas dienas, bija reize, kad mēnesi uz 1 tasku gaidīju)

7) Alga (tikai pašās beigās, jo alga man nav tik svarīga, kā tas, lai man darbs patiktu)

Edited by jurchiks
Link to comment
Share on other sites

  • Replies 546
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Pateikšu, kas te mainījies kopš vairs neesi pie mums

 

1. un 2. nebūs.

 

3) code style vismaz frontendam vairs nelaiž cauri gitā, ja nav pēc standartiem, backendam man liekas, joprojām vienalga

 

4) tagad visi projekti ir gitā un visi kommito savos branchos  un tad merge request uz master, kur kāds augstāks pārskata visu vēlreiz

 

5) visi ir sadalīti pāros (regulāri mainās) un katram merge request ir jātaisa review

 

6) Testing - pilnīgi visiem taskiem, visiem uzdevumiem, pirms merge request uz master, jāapstiprina testeru komandai, kas tieši tā, ka daži vienkārši taski iet pat nedēļu un beigās atnāk ar no tavām izmaiņām neatkarīgu bugu (jau esoš, globāls or whatever) un tā nu tev tas tasks ar hotfixu ir vēl 2-3 nedēļas, jo tu mēģini kaut kādus kreisos, unrelated to the task bugus taisīt

 

Ķip labāk un siktāk viss ir

Link to comment
Share on other sites

ha, vienbrīd gandrīz aizgāju strādat uz DYNINNO (labi ka noturēja). Freimworkus tur neizmantojot jo tas esot pārāk liels overheds, viss plain php. Svarīga esot katra mikrosekunde. Nodomāju, nu ok, itkā jau makes sense.

Tai pat laikā, cik dzirdēju no insaidera, 700 db kveriji uz katru ielādi tur ir norma. 

Tur izmanto Symfony komponentes; knapi pirms es aizgāju, kaut kāds ģēnijs tur izdomāja uztaisīt "Dyninno framework", kurš bija vāji salipināts no kādām 4-5 Symfony komponentēm.

 

700 db kveriji tad droši vien ir lielos projektos, pie tiem es vēl nebiju ticis; servisostik traki cipari nebija, bet, protams, sūdu tur pietika arī bez tā. Projekts > Commons library > PEAR library, PEAR vispār apdeitot drīkst tikai izredzētie, un attiecīgi viss pārējais tādēļ stagnē.

Link to comment
Share on other sites

Pateikšu, kas te mainījies kopš vairs neesi pie mums

 

1. un 2. nebūs.

 

3) code style vismaz frontendam vairs nelaiž cauri gitā, ja nav pēc standartiem, backendam man liekas, joprojām vienalga

 

4) tagad visi projekti ir gitā un visi kommito savos branchos  un tad merge request uz master, kur kāds augstāks pārskata visu vēlreiz

 

5) visi ir sadalīti pāros (regulāri mainās) un katram merge request ir jātaisa review

 

6) Testing - pilnīgi visiem taskiem, visiem uzdevumiem, pirms merge request uz master, jāapstiprina testeru komandai, kas tieši tā, ka daži vienkārši taski iet pat nedēļu un beigās atnāk ar no tavām izmaiņām neatkarīgu bugu (jau esoš, globāls or whatever) un tā nu tev tas tasks ar hotfixu ir vēl 2-3 nedēļas, jo tu mēģini kaut kādus kreisos, unrelated to the task bugus taisīt

 

Ķip labāk un siktāk viss ir

Nu 1. un 2. nav mainījies, tā bija arī pirms tam.

3. Jā, frontendā tā Elvīra vismaz normāls cilvēks bija, tā kā tur kvalitāte vismaz kaut kāda bija.

4., 5. - wow.

6. Doing it wrong, jes. Tas, ka viņi nespēj unrelated bugu atšķirt no buga konkrētajā izmaiņā, arī ir pasakaini.

Link to comment
Share on other sites

1. punkts depends. Ne visu var vienmēr pārcelt uz pēdējo versiju overnight. 2. lieto kādu ide/tūļus gribi. Kuru tas vispār interesē? Codebase ir vcs, a kā tu jamo raksti - da kaut ar kreisās kājas īkšķi. Par to, ka kāds izmanto tūļus, par kuriem tev nav nekādas sajēgas - tas jau tomēr akmens tavā lauciņā. 3. koda stila kontrolei ir attiecīgi instrumenti. Pirms atvērt pull requestu, neviens vairs buildus netaisa, testus nedarbina, neko, nē? Wtf? Kam visi tie CI un build serveri, kaķiem? 4. Merge request uz master? Tātad integrācija ir produkcija, un testējam produkcijā? WTF? 5. kādos nafig pāros? Katram pull requestam review (no >=2 cilvēku signoff, svarīgām izmaiņām arī no lead). 6. WTF? What is this? Did you loose a bet?

 

Lai gan ko es te vairs komentēju... Problēma ir acīmredzama. Un jamā ir abās pusēs. Ko tad gaida uz kaut kādu pasakainu vidi ar tādu attieksmi...

Link to comment
Share on other sites

ha, vienbrīd gandrīz aizgāju strādat uz DYNINNO (labi ka noturēja). Freimworkus tur neizmantojot jo tas esot pārāk liels overheds, viss plain php. Svarīga esot katra mikrosekunde. Nodomāju, nu ok, itkā jau makes sense.

Tai pat laikā, cik dzirdēju no insaidera, 700 db kveriji uz katru ielādi tur ir norma. 

Atkarīgs kurā nodaļā trāpies - priecājos, ka aizgāju no Fronta prom.

Link to comment
Share on other sites

1. punkts depends. Ne visu var vienmēr pārcelt uz pēdējo versiju overnight. 2. lieto kādu ide/tūļus gribi. Kuru tas vispār interesē? Codebase ir vcs, a kā tu jamo raksti - da kaut ar kreisās kājas īkšķi. Par to, ka kāds izmanto tūļus, par kuriem tev nav nekādas sajēgas - tas jau tomēr akmens tavā lauciņā. 3. koda stila kontrolei ir attiecīgi instrumenti. Pirms atvērt pull requestu, neviens vairs buildus netaisa, testus nedarbina, neko, nē? Wtf? Kam visi tie CI un build serveri, kaķiem? 4. Merge request uz master? Tātad integrācija ir produkcija, un testējam produkcijā? WTF? 5. kādos nafig pāros? Katram pull requestam review (no >=2 cilvēku signoff, svarīgām izmaiņām arī no lead). 6. WTF? What is this? Did you loose a bet?

 

Lai gan ko es te vairs komentēju... Problēma ir acīmredzama. Un jamā ir abās pusēs. Ko tad gaida uz kaut kādu pasakainu vidi ar tādu attieksmi...

1. Es vēlos strādāt ar modernām tehnoloģijām, un ja jau es meklēju jaunu darbu, tad man ir tiesības izvēlēties vietu, kura izmanto tās modernās tehnoloģijas.

2. Ir uzņēmumi, kuros ir preferred IDEs/editori/workflowi. Ja uzņēmums ofisā sponsorē PhpStorm (jo tas tomēr ir maksas produkts), tad tas arī ir liels pluss. Par tūļiem - atvaino, neviens nevar zināt visus tūļus (un nevajag arī).

3. Koda stilu neietur ar formatētāju uzstādījumiem (jo formatētāji katrai IDEi/editoram savi galu galā, neviens neies uzturēt up-to-date configus visiem editoriem), ir teksta dokumentācija, kā būtu jābūt. Kāds testiem/buildiem/pull requestiem sakars ar koda stilu? Kodam būtu jābūt noformatētam pareizi jau pirms tā.

4., 5. Dyninno ir tā - ir standarts. Nenormāli sūdīgs standarts, bet standarts, un tam ir jāseko, jo tā ir pateikts. Apstrīdi - vācies prom.

6. Dzērumā priekšnieki izsapņoja, 100%.

 

Bet vispār, atkal jau tu te ar savu augsto tehnoloģiju un complex workflow domāšanu...

 

Atkarīgs kurā nodaļā trāpies - priecājos, ka aizgāju no Fronta prom.

Ko tā?

 

Yup, BO viss daudz mierīgāk man liekas jums tur ir

BO ir fucking garlaicīgi, monotons darbs. Reizēm ir steidzami taski or w/e, bet pat tad ir garlaicīgi.

Edited by jurchiks
Link to comment
Share on other sites

3. Koda stilu neietur ar formatētāju uzstādījumiem (jo formatētāji katrai IDEi/editoram savi galu galā, neviens neies uzturēt up-to-date configus visiem editoriem), ir teksta dokumentācija, kā būtu jābūt. Kāds testiem/buildiem/pull requestiem sakars ar koda stilu? Kodam būtu jābūt noformatētam pareizi jau pirms tā.

 

Šo ir elementāri atrisināt, jo ir vispārpieņemti standarti.

Piemēram, mēs uzliekam Stormam, lai tas lieto PSR1/PSR2 stilu. Visi koderi lieto IDĒ auto-format.

Ja kāds lietotu citu editoru (dies` pasarg, nāktos konvertēt), tad noteikti arī tam varētu iestatīt konkrētu, vispārpieņmetu standartu.

Link to comment
Share on other sites

 

Šo ir elementāri atrisināt, jo ir vispārpieņemti standarti.

Piemēram, mēs uzliekam Stormam, lai tas lieto PSR1/PSR2 stilu. Visi koderi lieto IDĒ auto-format.

Ja kāds lietotu citu editoru (dies` pasarg, nāktos konvertēt), tad noteikti arī tam varētu iestatīt konkrētu, vispārpieņmetu standartu.

http://cs.sensiolabs.org- you are welcome :P Mēs lietojam arī kā pre-commit huku, pasaka ja kaut kas nav noformatēts kā vajag pirms komita. Man papildus tam šis ir arī post-save hūks. Galvenokārt tāpēc, ka mums lieto kas katram ērtāk - IDEA, Atom, Vim, etc. Gala rezultāts - visiem viens. Plus ja ir dažādi stili dažādos projektos, ir .php_cs, kur var sakonfigurēt kā ienāk prātā.

 

1. Es vēlos strādāt ar modernām tehnoloģijām, un ja jau es meklēju jaunu darbu, tad man ir tiesības izvēlēties vietu, kura izmanto tās modernās tehnoloģijas.

2. Ir uzņēmumi, kuros ir preferred IDEs/editori/workflowi. Ja uzņēmums ofisā sponsorē PhpStorm (jo tas tomēr ir maksas produkts), tad tas arī ir liels pluss. Par tūļiem - atvaino, neviens nevar zināt visus tūļus (un nevajag arī).

3. Koda stilu neietur ar formatētāju uzstādījumiem (jo formatētāji katrai IDEi/editoram savi galu galā, neviens neies uzturēt up-to-date configus visiem editoriem), ir teksta dokumentācija, kā būtu jābūt. Kāds testiem/buildiem/pull requestiem sakars ar koda stilu? Kodam būtu jābūt noformatētam pareizi jau pirms tā.

4., 5. Dyninno ir tā - ir standarts. Nenormāli sūdīgs standarts, bet standarts, un tam ir jāseko, jo tā ir pateikts. Apstrīdi - vācies prom.

6. Dzērumā priekšnieki izsapņoja, 100%.

 

Bet vispār, atkal jau tu te ar savu augsto tehnoloģiju un complex workflow domāšanu...

1. Right. Good luck then.

2. Jā, ir tādi uzņēmumi. Saucas bedres, kam vairāk interesē internal policy kā produktivitāte. Ja cilvēks ir 10 gadus nolietojis VIM, kāpēc forsēt jamo lietot ko citu? Un Jetbrains tā kā sen jau vajadzētu sponsorēt visiem, by default.

3. Kāds testiem buildiem un pull requestiem sakars ar koda stilu? Tāds, ka viens no build stepiem var būt koda stila pārbaude. Piemēram, mums katrs pull requests iet caur CI serveri - atver pull requestu, post hooks painformē Jenkins, ka ir jauns pull requests. Jenkins novelk izmaiņas, automātiski samerdžo ar mērķa branchu (vai nu tā ir integrācija, vai produkcija), izpilda testus un novalidē mainīto kodu - tiesa, mums nepārbauda koda stilu, jo par to rūpējas pre-commit huki - so neglīts kods repā vispar nenonāk, nekad - taču man ir zināmi konkrēti kantori kur koda stils un lint, utt utjp tiek darbināts pret katru buildu, lai izvairītos no dajebkāda regresa. Visbeidzot Jenkins noreportē build statusu kā komentāru pie pull request. Tas viss automātiski, katru reizi kad upteito pull request un nulle interaction no programmetāja puses. Tu to zinātu, ja vismaz pacenstos apzināt tos tūļus, ko "nevajag arī".

4.5. PHP ir de-fakto stils, saucas PSR. Python, Java, HTML, JS, CSS, LESS, SASS ir savi standarti. Ja tas kantoris izmanto kaut kādu ļevu pašizdomātu figņu, nav brīnums, ka operē tur jefiņi, jo neviens normāls cilvēks uz to neprarakstīsies. Un ja atbilde uz pozitīvām izmaiņām ir "vācies prom", jebkurš, kurš vēl nav aizvācies ir jucis.

Edited by F3llony
Link to comment
Share on other sites

 

Šo ir elementāri atrisināt, jo ir vispārpieņemti standarti.

Piemēram, mēs uzliekam Stormam, lai tas lieto PSR1/PSR2 stilu. Visi koderi lieto IDĒ auto-format.

Ja kāds lietotu citu editoru (dies` pasarg, nāktos konvertēt), tad noteikti arī tam varētu iestatīt konkrētu, vispārpieņmetu standartu.

Ne visi izmanto tos "vispārpieņemtos" standartus. Man, personīgi, daļa no PSR noteikumiem liekas stulba un es tos netaisos ievērot.

Link to comment
Share on other sites

1. Right. Good luck then.

2. Jā, ir tādi uzņēmumi. Saucas bedres, kam vairāk interesē internal policy kā produktivitāte. Ja cilvēks ir 10 gadus nolietojis VIM, kāpēc forsēt jamo lietot ko citu? Un Jetbrains tā kā sen jau vajadzētu sponsorēt visiem, by default.

3. Kāds testiem buildiem un pull requestiem sakars ar koda stilu? Tāds, ka viens no build stepiem var būt koda stila pārbaude. Piemēram, mums katrs pull requests iet caur CI serveri - atver pull requestu, post hooks painformē Jenkins, ka ir jauns pull requests. Jenkins novelk izmaiņas, automātiski samerdžo ar mērķa branchu (vai nu tā ir integrācija, vai produkcija), izpilda testus un novalidē mainīto kodu - tiesa, mums nepārbauda koda stilu, jo par to rūpējas pre-commit huki - so neglīts kods repā vispar nenonāk, nekad - taču man ir zināmi konkrēti kantori kur koda stils un lint, utt utjp tiek darbināts pret katru buildu, lai izvairītos no dajebkāda regresa. Visbeidzot Jenkins noreportē build statusu kā komentāru pie pull request. Tas viss automātiski, katru reizi kad upteito pull request un nulle interaction no programmetāja puses. Tu to zinātu, ja vismaz pacenstos apzināt tos tūļus, ko "nevajag arī".

4.5. PHP ir de-fakto stils, saucas PSR. Python, Java, HTML, JS, CSS, LESS, SASS ir savi standarti. Ja tas kantoris izmanto kaut kādu ļevu pašizdomātu figņu, nav brīnums, ka operē tur jefiņi, jo neviens normāls cilvēks uz to neprarakstīsies. Un ja atbilde uz pozitīvām izmaiņām ir "vācies prom", jebkurš, kurš vēl nav aizvācies ir jucis.

1. Kā tad, jāsamierinās ar vecu softu, vai ne?

2. Es teicu preferred, nevis required.

3. "var būt koda stila pārbaude". "Tu to zinātu, ja vismaz pacenstos apzināt tos tūļus" - except man nevienā darbā nav nācies tos izmantot. Kad nāksies, tad iepazīšu.

4. Visiem jau tāpat ir skaidrs, ka tu ienīsti visus citus koda stilus, kas kaut nedaudz atšķiras no PSR. I don't give a fuck, es neesmu robots, man ir savs viedoklis un savs stils. Un es nebūt neesmu vienīgais. Nāksies vien deal with it.

Link to comment
Share on other sites

Ne visi izmanto tos "vispārpieņemtos" standartus. Man, personīgi, daļa no PSR noteikumiem liekas stulba un es tos netaisos ievērot.

Tāpēc jau tavs kods izskatās tā, itkā mans 3gadnieks būtu vienkārši nomaucis pa pogām ar plaukstu.

 

1. Kā tad, jāsamierinās ar vecu softu, vai ne?

2. Es teicu preferred, nevis required.

3. "var būt koda stila pārbaude". "Tu to zinātu, ja vismaz pacenstos apzināt tos tūļus" - except man nevienā darbā nav nācies tos izmantot. Kad nāksies, tad iepazīšu.

4. Visiem jau tāpat ir skaidrs, ka tu ienīsti visus citus koda stilus, kas kaut nedaudz atšķiras no PSR. I don't give a fuck, es neesmu robots, man ir savs viedoklis un savs stils. Un es nebūt neesmu vienīgais. Nāksies vien deal with it.

1. How about fucking fixing it?

3.4. Nenāksies. Jo tevi vienkārši nevienā pieklājīgā darbā ar tādu attieksmi nekad neņems - pietiek kandidātu, kam patiesi arī interesē ko pie velna viņi dara. 

Link to comment
Share on other sites

Tāpēc jau tavs kods izskatās tā, itkā mans 3gadnieks būtu vienkārši nomaucis pa pogām ar plaukstu.

 

1. How about fucking fixing it?

3.4. Nenāksies. Jo tevi vienkārši nevienā pieklājīgā darbā ar tādu attieksmi nekad neņems - pietiek kandidātu, kam patiesi arī interesē ko pie velna viņi dara. 

1. Vot davaj, aizej uz Dyninno un salabo. I dare you.

3., 4. Sure. Jo tas, ka es nezinu 1 tūli, nozīmē, ka es neesmu ieinteresēts to iemācīties, ja tas nepieciešams darbam...

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share


×
×
  • Create New...