F3llony

Es pieņemu, ka mans pieteikums apputēja starp citiem, jo aizpildīju pie draugiem vakancēm. Un tas bija jau labi sen, kazi 3 gadus atpakaļ.

Dzelžaina loģika. Konkrētajā gadījumā es diez vai strādātu jebkad jēlkur. Bet kaut kā tomēr nesūdzos par darbu trūkumu. Patiesībā, pēdējā laikā nācies tik daudz darbus atteikt, ka sāku apsvērt domu atvērt darbā iekārtošanas aģentūru. Humora pēc, man pat neatbildēja uz pieteikumu. Līdz ar to, diez vai mans ego, attieksme un lielā mute būs pie vainas.

Šeit es varu izteikt tikai līdzjūtību. Un zinot kantori, es pasteigtos arī norakstīt. Jāatceras, ka arī Draugiem nav zelta bedre un ir savi dumjumi. Ne mazums man pilsoņu tur ir grozījušies. Pats vienreiz pieteicos pašos draugos pāris gadus atpakaļ, laikam nebiju gana labs, nepaņēma. Tagad lai es tur ietu strādāt, nezinu, kādi bonusi būtu jāliek galdā. :D

Indeed. Lai gan mani īpaši nepārsteidz, ka lielajā vairumā LV kantoru darbojas tieši šādi. Kaut kādi agile, lean principi tur ir diezgan sveši, kur nu vēl kaut kas, kā jidoka, continuous improvement utml.

You, Sir, are brilliant. MMD, kthx.

Mācīšos Scala!

Gold

Vai Cloudflare...

Tu nepareizi raksti. Pareizi ir vinjsj irj troljosjanjasj specjaljistsj

Negribi piekrist, nepiekrīti. Faktu, ka tas tā pa lielam tomēr ir tas nemaina. Satikties droši varam, tikai runāt par ko gan īsti neredzu. Visu, ko man vajadzēja redzēt es redzēju iepriekšējā topikā un tur esošajā risinājumā.

Es tiešām atradu problēmu. Ļauj paskaidrošu - es ar corporate IS izstrādi nodarbojos, ko, no kaut kāda 2008. gada? Es vēl neesmu speciālists. Pat tuvu ne. Patiesību sakot, katra IS kādā konkrētā nozarē man ir jauns tāzera šāviens kājā un katru reizi pieķeroties kaut kāda konkrēta kantora sistēmas izstrādei es jūtos kā pirmajā skolas dienā, jo katrs keiss kas nav regulēts ar likumu (pat ja ir, arī neglābj) ir unikāls. Un te nu mēs nonākam līdz lielākajai problēmai konkrētajā nozarē - pēkšņi kaut kur no velns zina kurienes parādies tāds Tu, kas momentā kaut kur "specializējas", lai gan realitātē mani māc šaubas vai tu maz īsti saproti kas katrā no tajām nozarēm vispār vārās, sāc bāzties visādos sludinājumu dēļos, dempingo cenas, taisi savus "solutions" un kaut kādas figņas, un tad tiem, kas reāli ar to nodarbojas, un kaut ko tiešām no tā arī jēdz velk galus, jo ir saražoti šādi Pjotru kantori uz katra stūra. Es ne vārda neteiktu, ja tu būtu puslīdz godīgs un pateiktu kaut ko no līnijas, "strādāju ar to un to, esmu uztaisījis to un to, ir tāda un tāda pieredze un plānoju darboties tādā un tādā štellē. Pieredzes vēl pamaz bet esmu uzņēmīgs un im gettin' shit done". Lai būtu, awesome, pat varbūt kaut ko piefīrētu no projektiem, kā tas nereti gadās. Bet tu esi speciālists... Humility is a virtue. P.S. Postus vari nedzēst. Es redzēju. Tas visu arī izteica.

Es pilnīgi noteikti kļūdos, bet konkrētajā kontekstā ar nozīmi de-facto. Kavacky, atverot to jama risinājumu, Tu man gribi teikt, ka jams ir specializēts konkrētajā darbības virzienā? Es domāju, ka tālu no tā. Tāpēc arī Pjotra kantoris.

Vēl viens... Nepietiek jau ar visādiem Pjotru kantoriem...

O.O paneļa jūzeri un app jūzeri vienā kolekcijā... Mjā... Hard coded, hard coupled shēma un dati. Niiice. Bet atgriezīsimies uz mirkli realitātē, kur es esmu PO un es tev neesmu teicis nevienā brīdī, kas es gribu šīs 3 grupas. Es negribu tās tavas nule izdomātās 3 grupas. Es gribu 50. Nē, 70. Es vispār vēl nezinu, vienkārši izdari tā, lai es rīt varu ieiet panelī, nodefinēt permisijas un kamēr es to neesmu izdarījis, nekas nemainās. Un vēl es gribu permisiju matricu. Pilnvērtīgu. Es gribu matricu, kur katrai lietotāju grupai es varu piešķirt read write permisijas katrai lapeles sadaļai. Pēc tam es gribu lai grupas varētu mantot citas grupas tiesības. Un pēc tam nepiemirsti palabot savu migrāciju, kad es būšu panelī salicis visas permisijas pareizi FTW. Ps naming conventions, smartass. app_users app_user_groups app_users_user_groups_rel

Kādi 2 objekti, kādā update brīdī. Tu maz pats saproti, ko raksti? Kāpēc lai migrācija kaut ko veidotu?! No kurienes tad tava migrācija izraus to B objektu? Kurš jamo definēs? Tu? Paskatīsimies no cita skatu punkta. Es esmu PO un jau minētajai jūzeru mvp fīčai gribu tās pašas grupas. Uzraksti man kodu, kur es varu ieiet panelī un pielikt katram lietotājam grupu. Tavs risinājums?

Jā, un šis piemērs ir pilnīgi valids, jo tu neizzīd no pārpilnības raga kaut kādus datus, bet gan paņem datubāzē jau esošu informāciju un konvertē saskaņā ar jauno shēmu. Šāda darbība ir pilnīgi saderīga ar manis teikto, jo šajā gadījumā migrācija neražo jaunus datus - tā pārveido esošo datu glabāšanas veidu/uzskaiti/reprezentāciju, pie tam to izdara neko nejēdzot par pašiem datiem izņemot to shēmu.

A jau eksistē, bet B vēl neeksistē. Tāpēc tev nevar būt relācija starp A un B, jo relācija prasa kā minimums 2 objektus, starp kuriem veidot relāciju. Ja tev ir bars ar lietotājiem, ir izveidota grupu konstrukcija, bet grupas vēl neeksistē, loģiski, ka nekāda relācija nesanāks. Grupas veidot nav developera pienākums, tātad nekādas datu migrācijas šā vai tā nebūs, savukārt nākotnes relācijas veidosies organiski, savukārt jaunām organiskām relācijām nekādas migrācijas nav nepieciešamas. Konkrētais princips darbojas +/- jebkurā gadījumā. Pie tam, tavs B ir nevis objekts, bet objektu kolekcija, un pats relācijas princips padara tavu piemēru par bezjēdzīgu un relācija nav obligāta, jo tas, ka relācija nav obligāta ir jāparedz arhitektūrā. Ja tu esi aiz sava prieka padarījis to relāciju obligātu saistot kaut ko, kas eksistē, ar kaut ko, kas neeksistē, cmoon...

Nē, tas ir tieši šī argumenta scope, jo runa ir par arhitektūru un arhitektūra ir development scope, tā pat, kā migrācijas. Ja tev ir ACL modelis, kas nepieļauj lietotājus bez grupas ar noklusējuma rules kodā, tad tava arhitektūra ir kretīnisms un tu mēģini tagad ieborēt, ka tevis paša radītā hipotētiskā problēma ir arguments par to, kāpēc vajadzētu bāzt šādus datus migrācijās. Jebkurā gadījumā, tev kā devam nav nekādas ziņas, kādās kurš grupās tiks iedalīts, jo tas nav arhitektūras jautājums. Case closed, go home.

Kā tas saprotams, nedrīkst? Argumentu studijā.

Lietotāji tev jau eksistē; Pēc migrācijas shēmā ir grupu dalījums, pēc noklusējuma visi lietotāji var būt vispār bez grupas ar ACL defaultiem (deny everythang, permit nothang); Lietotāji vispār netiek aiztikti (o2m relācija); Admins ielien panelī un sadala aitas (lietotājus) grupās; ?!! Profit Konkrētajā piemērā, tas vispār nav tavā kompetencē gar konkrētajiem datiem gramstīties.

Dati nav atkarīgi no shēmas, shēma ir atkarīga no datiem. Sāksim ar to. Vai arī tev lietotājvārdi, piemēram, tagad datubāzē glabāsies kā biginti, jo es tā esmu uzlicis? base8 encode FTW. Bet kāpēc tu par visu varu gribi bāzt datus shēmas migrācijās? Nu labi, ja tev ir tādi dati, taisi atsevišķas datu migrācijas, Django style. Lai gan arī tur es neesmu redzējis, ka raw dati tiktu soursēti migrācijā, transformācijas, jā, bet dati? Lai nu kā, man pat šie piemēri izskatās pēc datiem, kam nebūtu jābūt migrācijā, tiem būtu jātiek vilktiem no produkcijas. Tieši tādā pašā veidā, kad tu veido feature branch versiju kontrolē no master nevis FEATURE-XXX-STAGING un pēc tam dauzi galvu pret sienu, jo tavs feature branch ir branch no kaut kāda brancha, kam ar prod nav nekāda sakara. Šajā gadījumā, tev migrācijās būs dati, kam ar master/prod nav nekāda sakara. Es vēl joprojām pieturos pie tā, ka - Shēmas migrācijas ir tupas, tām nav jājēdz nekas par datiem, kas atrodas DB Datiem, kas atrodas dev db jānāk no produkcijas Datus no produkcijas fetcho ar skriptu Uz produkcijas datiem izpilda migrācijas, kas vēl nav produkcijā lai būtu konsistence ar citiem darboņiem Ar konkrēto pieeju nekad nav bijušas nekādas problēmas, konflikti, nesakritības vai vēl kaut kas. Dati vienmēr ir maksimāli tuvu produkcijai, konsistenti un paši agregē savas izmaiņas (talk about lietotāju grupas). Manuprāt ražot kaut kādus datus devā kurus pēc tam baksta prodā ar migrāciju ir diezgan nesmuki. Thats all.

Teorētiski to protams var darīt, uztaisot kaut kādu "demo dati" migrāciju, bet es šādus datus glabātu kaut kā savādāk. Kaut SQL failā. Man gan šāda problēma ir reti, jo parasti sinhronizēju šādus datus no produkcijas lai dev būtu maksimāli tuvs prod.

Nē, pilnīgi noteikti nē, bībelē ir punkts kas to aizliedz! Zaimotājs! Baigā atšķirība... Es gan protams spēcīgi iebilstu pret jebkādu datu glabāšanu migrācijās, jo why?!

Kā, tas ir, pacelsi? Tev ir grūti uzrakstīt komandu, kas nodumpo aktuālo shēmu un atmet vecās migrācijas? Un kad vajag "pacelt", sāc no pēdējās aktuālās shēmas + migrācijas since then.

A kas tev liek glabāt miljards gadus vecas migrācijas? :< Reizi tur piemēram nedēļā vai 2ās, piem. sprinta beigās, shēma ir stabila, hands off un uztaisa tīrīšanu. Vecās migrācijas lai nīkst iekš GIT.