codez

@Wuu, parādi savu veidu kā tu "pareizi" lieto React.

@jurchiks, es izmantoju webpack un visu pakoju pie izstrādes, tur notiek less kopilācija vienā vai vairākos css, kurus pēc tam iekļauj kopējā bundlē, ES6/React JSX -> ES5 translācija, minimizācija un nesmukošana(uglify). Parasti viss (gan css, gan js, tāpat arī 3d pary bibliotēkas) tiek sabundlēts vienā js failā, kurš ir minimizēts. Ja projektā ir vairākas mazāk saistītas daļas, ar webpack var smuki sataisīt, lai sabundlē vairākās bundlēs un ielādē tās pēc vajadzības. Tā kā visa izstrāde notiek ES6 moduļos, tad webpack ļoti labi zin, kurš kods no kura atkarīgs un kurā brīdī, kuru bundli ielādēt.

@briedis, agrāk izmantoju Webstorm, kurš +- strādāja, tagad izmantoju Atom ar pluginiem - strādā diezgan perfekti. Priekš React-a JSX sintakses ir vairāki plugini: https://atom.io/packages/language-babel, https://orktes.github.io/atom-react/ (lapā ir video kā strādā autocomplete). Ja item ir objekts, tad to var mierīgi padot, teiksim <UserAvatar user={this.user} />, respektīvi, tas, ko raksta starp {}, ir jebkāda js izteiksme.

@briedis, vienkāršotā variantā tas būtu šādi: https://jsfiddle.net/uwu5hwj7/2/ Kompleksākā aplikācijā, atkarībā no arhitektūras, dati glabātos atsevišķā storē un tādas manipulācijas kā "setActive" tiktu veiktas uz store, nevis view elementu. Bet galvenā domā kodā tāpat redzama, setActive funkcija nemaina dom-u, bet gan tikai datus, par dom-a izmaiņu atbild React bibliotēka. @Wuu, enkapsulācija ir vajadzīga, lai rakstītu no aplikācijas neatkarīgas, vairākkārt izmantojamas komponentes, ko redux gadījumā nav triviāli izdarīt, jo viss aplikācijas stāvoklis glabājas kopējā storē. Ļoti bieži ir daudz ērtāk un vienkāršāk izveidot pilnīgi neatkarīgu komponenti ar kuru tad galvenā aplikācija komunicē, it sevišķi, ja pie lielāka projekta strādā vairāki cilvēki. Saprotams, ka arī reduxā un tā iedvesmas avotā elm-ā ir atrasti dažādi paterni kā enkapsulēt komponentes, bet tie ir par kārtu sarežģītāki un nav tik atstrādāti un praksē pārbaudīti kā klasisks OOP.

Wuu, kā tu bez OOP realizē enkapsulāciju un polimorfismu? Vai tavi projekti ir pārāk vienkārši un šāda abstrakcija nav nepieciešama? Briedi, ģenerēt dom-u pirmo reizi ir vienkārši. Efektīvi to mainīt laika gaitā, jau ir pavisam ir kas cits un šo problēmu React atrisina ļoti labi. Kā, piemēram, ar vanilla js jūs maināt teiksim 100 elementu list-a piecu item-u klasi un tekstu?

Man ē-pastā pēdējais piedāvājums no rekruiteriem tajā reģionā (Beļģija) Frontend, React 400 - 480 eur/dienā.

Pirmais filtrs ir pozīcija atalgojuma apmērs. Ja šis skaitlis par mazu, vai nav norādīts, potenciālais darbinieks tādu sludinājumu laiž garām.

Īstais orģinālraksts: http://www.gamasutra.com/view/news/269725/Sponsored_22_Dos_and_donts_when_fighting_cheating_in_online_games.php

Pieliku arī Scala Play freimworku: https://www.google.com/trends/explore?q=Yii2,%2Fm%2F0jwy148,%2Fm%2F09cjcl,%2Fm%2F02qgdkj,play

Vai tu savā uzņēmumā tā dari? Visiem darbiniekiem maksā vienādus procentus no peļņas? Kādā nozarē darbojas tavs uzņēmums un cik viņam ir darbinieku? Ir konkrēta problēma. Vidējais darbinieks nav pārāk ieinteresēts radoši strādāt un ir nepieciešama sistēma, kas viņu motivētu strādāt radošāk un ar atdevi. Latvijā mantojumu tiesības ir ļoti labi aprakstītas Civillikuma 2. daļā un pilnībā pārklāj visus tavus uzdotos jautājumus.

Kaut kur lasīju, ka Orākls nopirka Mysql, lai lēnām un klusi nogremdētu, bet pateicoties Mariadb, viņiem visi plāni izjuka.

Sistēmu neizdomāju, uzzināju no paziņas, kurš darbojas tajā pašā nozarē, kur es. Bet jā, ir doma, ka varētu šādu sistēmu izmantot un tā dotu daudz labākus rezultātus kā parasta algu sistēma.

Nu vai tad šī sistēma tiešo to arī nedara, kad tavi procenti ir atbilstoši tavam nostrādātajam laikam? Šī sistēma atrisina uzreiz daudz speciālgadījumus, attiecībā pret statiski noteiktiem procentiem. Piemēram, kāds no darbiniekiem pamet projektu ātrāk - šajā gadījumā pārējiem procenti pieaug, vai, piemēram, projekts aiziet daudz labāk nekā cerēts un tā attīstībai jāpiesaista vēl programmētāji. Pirmie saglabā savu daļu, kura lēnām samazinās, kamēr pārējiem daļa lēnām aug no nulles uz augšu. Gadījumā, ja jau visas daļas būtu izdalītas statiski pirms tam, jaunajiem piesaistītājiem programmētājiem nevarētu piedāvāt daļas, tādā veidā piesaistot labākos, projektu nevarētu attīstīt un zaudētāji būtu visi.

Kāpēc, lai darbinieks, kurš tikko atnācis strādāt projektā saņemtu tikpat procentus no peļņas, cik, piemēram, darbinieks, kurš strādājis jau 2 gadus pie projekta?

Nu tik stulbus darbiniekus, kas nesapratīs, arī nevienam nafig nevajag - lai iet rakt grāvjus. Normāls programmētājs saprot, ja projektam ir X lietotāji un vidēji projekts var pelnīt C naudiņas uz lietotāju mēnesī un, ja ir vidēji 5 darbinieki projektā, tad viņam ir 20% no žetoniem un viņš saņems 0.2 * 0.3 * (ien - izd), kur ien = XC, bet izd = summa no visām izmaksām. Un pēkšņi darbinieku jau tiešā veidā sāk interesēt, kā palielināt X, kā palielināt C, kā uztaisīt efektīvāku kodu, lai būtu vajadzīgi mazāk serveri un izmaksas būtu mazākas, utt, nevis tupi atstrādāt todo listi.

Problēma jau nav tajā, ka uzdevumus nepilda, bet kā viņus pilda - imitē pildīšanu. Uz papīra uzdevumu var izpildīt, bet realitātē tas izdarīts ātri, pavirši, nepārdomāti, ar bugiem, nenotestēti, neoptimizēti, utt. Programmētājs ir viena no tām profesijām, kur diena beigās 2 programmētāji it kā abi ir izpildījuši uzdevumus, bet viens ir radījis 10 vai pat 100 reizes vairāk pievienotās vērtības kā otrs. Nākošā lieta ir, cik no programmētājiem, kas saņem tikai algu, ikdienā strādā radoši - iesaka idejas kā produktu reāli uzlabot, lai tas nestu lielāku peļņu. Un nevis iesaka atkal imitācijas pēc, bet reāli ikdienā par to domā. Saprotams, priekš kam viņam to darīt, ja viņam algu maksā tāpat - par izdarītiem punktiem todo listē. Savukārt, ja no rezultāta izrietēs tas, ka viņš var saņemt 10 reiz vairāk kā nopelna ar algu, attieksmei vajadzētu būt pavisam citai. Nākošā lieta - arī vadītājs ir algota persona un var imitēt darbu un arī šeit, ja programmētājam maksā tikai algu, šāds vadītājs ir ideāls, jo var pats imitēt darbu, savukārt, ja no rezultāta atkarīga viņa labklājība, tad arī ierindas programmētājs ātri sāks protestēt pret šādu vadītāju.

Man šķiet, ka iemesls varētu būt, lai atlasītu tos potenciālos darbiniekus, kas gatavi strādāt uz rezultātu no tiem, kas grib tikai algu un tālāk jau atsēdēt un imitēt darbu.

Lai nebūtu par un ap - kompānija darbojas datorspēļu jomā un viņai jau ir portfelis ar populārām spēlēm, tāpēc piesaistīt lietotājus ir dažu dienu jautājums. Tāpat arī šķiet, ka spēles 4 gadu laikā paliek stipri neaktuālas (protams ar retiem izņēmumiem). Taču, ja spēle turpina palikt populāra un darbinieki turpina to uzturēt, tad viņu žetonu proporcija +- saglabājas nemainīga kaut 10 gadus. Nav jau daudz sistēmu ar ko šo varētu salīdzināt. Galvenā būtu stoki. Stoku gadījumā, ja daudzprojektu kompānija, darbinieks saņem daļu no visiem projektiem, kas darbinieku ne pārāk motivē attīstīt labi tieši savu projektu. Tāpat stokus parasti dod daudz, daudz mazāk, kas darbiniekam atsevišķos gadījumos var dot kaut ko ilgtermiņā, bet dod mazāk īstermiņā, jo bieži stoki ir opciju veidā, kurus var vestēt pēc 1-3 gadu termiņa. Otra sistēma ar kuru var salīdzināt ir LV klasika, kad maksā tikai algu. Manuprāt, šādā sistēmā, vienīgais, ko darbinieks ir motivēts darīt, ir imitēt, ka kaut ko dara (kas dažreiz prasa arī kaut ko reālu izdarīt).

Starp kolēģiem nekādu sacensību šī sistēma nerada, jo katram darbiniekam pienākas noteikts žetonu skaits mēnesī par kuru viņš ir vienojies uzsākot darbu, taču darbinieks ir tiešā veidā ieinteresēt, lai citi kolēģi neslinko. Neko nošmaukt citam darbiniekam nevar. Vairāk vai mazāk, ja komanda sakomplektēta, katrs darbinieks var diezgan precīzi prognozēt, kādu daļu no peļņas viņš saņems teiksim, piemēram, pēc 6 mēneši, kad projektu palaidīs vai pēc 2 gadi, kad projekts ies pilnā sparā. Vienīgi, ja projekts izaug lielāks nekā paredzēts un nepieciešami papildspēki, tad žetoni var nedaudz atšķaidīties, bet tas ir tāpat kā ar jebkuru stoku variantu, kad ienāk jauni investori un darbinieku stoki var vienā dienā atšķaidīties 2,3 vai pat 5 reizes. Es šai sistēmai redzu vienu būtisku trūkumu - darbiniekiem tiek doti pārāk lieli procenti. Ja projekts nes pietiekamu peļņu, tad principā darbinieku pie citiem projektiem nedabūsi, jo no saviem procentiem viņš jau saņems vairākas vai pat vairākus desmitus algas. Visur iepriekš, kur esmu sastapies ar aptuveni tāda izmēra startupiem, darbiniekiem parasti dod stokus procentu desmitdaļās vai pat simtdaļās.

Cik saprotu, parasti jauni programmētāji piesaistās projektiem no sākumā vai izstrādes sākuma stadijā, respektīvi +- tiek komplektēta komanda konkrētam projektam. Darbības sfēras specifika ir tāda, ka projekts var sākt pelnīt jau pirmajos izstrādes mēnešos, bet uzturot un attīstot, drošvien daudz vairāk, bet tas ir līdzīgi kā ar daudziem projektiem, piemēram, uztaisa sociālo tīklu, cilvēki sāk lēnām lietot, bet ienākumi ir mazi, tālāk izveido papildus funkcijas par samaksu un peļņa daudzkāršojas. Ja darbojies vairākos projektos, tad attiecīgi, katrā projektā tu saņem noteiktu daudzumu žetonu. aaxc, šijā gadījumā ir tā, ka kompānijai ir portfelis ar veiksmīgiem projektiem un tiek attīstīti jauni projekti, kas nedaudz atšķiras no esošajiem, bet ir tajā pašā sfērā.

Man šķiet, ka tur darbojas tie paši principi, kas jebkurā kompānijā - ja acīmredzami kāds nepilda kaut kādus pamatpienākumus, viņš tiek palaists brīvībā. Bet šajā gadījumā strādīgais darbinieks ir tieši motivēts aiziet pie vadītāja un argumentēti pamatot, kāpēc "sabotējošo" darbinieku ir jālaiž vaļā. Parastā kompānijā, kur darbinieks saņem tikai algu, viņam ir praktiski vienalga, vai kolēģis laiž luni, vai nē.

Nesen saņēmu interesantu darba piedāvājumu un mani interesē, vai citi programmētāji ir sastapušies ar ko līdzīgu un ko domā par šādu sistēmu. Kompānija nodarbojas ar projektu izstrādi noteiktā sfērā. Sfēras īpatnība ir tā, ka projekta ienākumi ir stipri atkarīgi no programmētāju cītības un radošuma. Respektīvi, nav jāuztaisa kaut kas ļoti konkrēts, bet labākais, ko programmētāju komanda spēj. Pie viena projekta strādā ne vairāk kā 10 cilvēki, bet viens cilvēks var būt iesaistīts vairākos projektos. Parasti, lai motivētu darbiniekus, tiem tiek piedāvātas kompānijas daļas (stoki, opcijas). Bet šī kompānija piedāvā atalgojumu pēc šādas sistēmas: Ir pamatalga, kas ir ap 60-70% no tādas stabilas labas tirgus algas, bet papildus tam tiek maksāti procenti no projektu peļņas. Procenti, cik tu saņem tiek aprēķināti pēc šāda principa: Katru mēnesi tev iedod noteiktu skaitu žetonus + žetonus vēl var nopelnīt par noteiktiem milestone. Žetoniem ir 4 gadu derīguma termiņš. Katra mēneša beigās, saskaita kopā visus izsniegtos žetonus, kuriem nav beidzies termiņš. Un darbinieks saņem peļņas procentus no projekta pēc formulas - (kopējā peļņa) * 0.3 * (darbinieka žetoni) / (visu darbinieku žetonu summa). Respektīvi 30% no projekta peļņas tiek sadalīta darbiniekiem proporcionāli viņu īpašumā esošajiem žetoniem. Piemēram, ja darbinieks A un B strādā pie projekta gadu un saņem mēnesī 100 un 80 žetonus, bet C un D atnākuši pirms 3 mēnešiem un saņem 90 un 80 žetonus, tad summa būs 12 * 100 + 12 * 80 + 3 * 90 + 3 * 80 = 2670 žetoni un attiecīgi,piemēram, darbinieks B saņems 960 / 2670 = 36% no darbinieku daļas, kas ir 36% * 30% = aptuveni 11% no projekta peļņas tajā mēnesī, bet darbinieki D un C vairākas reizes mazāk, jo viņu sakrātais žetonu skaits nav vēl tik liels. Žetoni turpina strādāt, līdz tiem beidzas termiņš, arī tad, ja darbinieks pamet projektu. Visa sistēma un tās caurspīdīgums un garantijas, ka žetoni netiks mākslīgi atšķaidīti, tiek atrunātas līgumā. Domas?

Respect. Es kādas 100 dienas savos 10+ gados esmu pavadījis ofisā.

Kopš veiksmīgi palaidu savus prodžektus, man īsti vairs nav jēga strādāt algotu darbu, bet līdz tam remote UK startupam.

Jā, tev taisnība. Detalizēti necentos izlasīt visus sludinājumus, tāpēc palaidu šim sludinājumam šo niansi garām.