jurchiks

Tu domā tā kā izdomāt kaut kādu ideju un mēģināt kādam biznesam to notirgot?

Ir liela atšķirība starp "nav vajadzības" (solo projektiem), "nav iespējams ieviest" (lieliem/veciem projektiem), "nav jēgas" (ļoti maziem projektiem), un "nepatīk". Bet davai, vismaz vienu reizi pieturi muti un neizplūsti daiļrunībā par to, cik es esmu šausmīgi slikts programmētājs, jo saviem personīgajiem projektiem nerakstu testus, lai izdabātu tādiem lepniem ļautiņiem kā tu.

Ignore him, he's just being himself.

...no mājām. Latvijā.

Nav īsti vietas veļukam dzīvoklī. Un mašīnu Rīgā jau tā pietiek.

Vajag minēt konkrētu atalgojumu. Ir tādi dīvaiņi, kas uzskata, ka atbilstošs atalgojums ir 800€ bruto.

Ir ieteikumi, kur meklēt?

Jau izmēģinu. Pagaidām ne parāk veiksmīgi.

Kur tad Latvijā man maksās tādas summas darbā no mājām? Es viennozīmīgi negribu vasaras karstajā laikā vairāk par pusstundu svīst sabiedriskajā transportā ceļā uz viņu ofisu (vai jebkuru ofisu).

Ir ~4.5 gadu darba pieredze ar dažāda lieluma un sarežģītības projektiem (vizītkaršu lapas, e-veikali, dokumentu uzskaites sistēmas, kredītu sistēmas, utt), gan frontend, gan backend, bet pēdējā laikā esmu sapratis, ka mūsdienu frontend pasaule nav priekš manis. Meklēju darbu pilnībā vai lielākoties no mājām (dzīvoju Rīgas centrā), pastāvīgā darbā, pie viena vai dažiem lielākiem projektiem. Zinu, ka tas ir iespējams, jo 3 darbos, kopumā vairāk par 2 gadiem, esmu tā strādājis. Prasu 1200€/neto (bet ja piedāvā vairāk, neatteikšos). Sīkāka info privāti.

Visticamāk, ka tu kodu viņam tikai parādi (piemēram, remote desktop), tad saņem naudu un aizsūti kodu. Vai varbūt 50% pirms, 50% pēc. Galu galā, ja tu klientam parādi strādājošu kodu un par to saņem samaksu, tad nav loģiski to kodu viņam nesūtīt, tā tu tikai dabūsi negatīvu atsauksmi savā freelance lapas profilā, un turpmāk tu tur klientus nedabūsi. Gan jau ka advancētākiem klientiem ir kāds, kas validē, ka kods tiešām atbilst prasībām un nav kaudze ar netīriem hakiem.

@jurgenz - frontend mūsdienās ir ļoti pieprasīts. Ļoti daudz tādu lapu, kurās backenda vispār nav.

Mjā, nu tad hz. Bet tas, ka uz pieteikumiem neatbild, ir "normāla" prakse mūsdienās... Diemžēl.

Par maz pieredzes un par daudz prasi. >aizsutu CV uz java/scala poziciju kur man nav pieredzes Viņi meklēja junioru/bez pieredzes? Jeb tu vnk pieteicies senioram, kaut gan tev nav pieredzes?

Mjā, nesliktas summiņas... Tikai Londonā par dzīvokļa īri arī aizies kāda ceturtā daļa algas.

That's not what I meant, but oh well.

Turpinam strīdēties?

LOL :D Top komentārs arī labs.

DRY ir princips. Idejiski to var elementāri attiecināt arī uz datubāzēm. Normalizācija ir krietni vien plašāks jēdziens, kas sevī ietver arī DRY.

Izlasi, lūdzu, visu topiku, tad labāk sapratīsi, par ko es konkrēti runāju.

Nav gan tikai ID, ir visi dati, kas indeksā definēti. Ja nav definēts neviens lauks, tad, protams, tikai ID vien būs. DRY nav svarīgs ātruma dēļ, bet gan lai datubāzē neveidotos tonna duplicate datu. Kur tu tur saredzi pretrunu?

Jā, izpildes ātrumu tas ietekmē minimāli, bet DRY gan datubāzēs ir svarīgs, it īpaši, ja ir plānoti 10k+ produkti ar tonnu atribūtu.

Kāpēc products_attributes tabulai ID kolonna? Unikalitāte rodas no product_id + attribute_id kombo, tāpēc vajag UNIQUE (product_id, attribute_id). Bez UNIQUE indeksa ID īstenībā var nemaz nebūt unikāls, ja 2 ieraksti ir ar vienādu product_id + attribute_id kombo. Nu un vēl ir tā, ka ja vērtība atrodas tabulā products_attributes, kur katra vērtība ir piesaistīta katram produktam, tad sanāk, ka ja 10 produktiem ir vienāda atribūta vērtība, tad datubāzē ir 10 vienādi teksta ieraksti atribūta vērtībai. Not very nice. Labāk tad tā: attributes: id, name attribute_values: attribute_id, name products: id, name, whatever else product_attributes: product_id, attribute_value_id (+ join attribute_values.attribute_id, + join attributes.name pēc id) Jā, varbūt nav diez ko smuki, toties nav data duplication, un nav katram produktam ar roku jāraksta atribūta vērtība.

Skaidrs ir viens - ja ir atribūti, kas ir vienam produktam, bet nav otram, tad kolonnas automātiski nav pareizais risinājums. Varētu jau vēl darīt tā, ka definē produkta tipu un tam atbilstošos atribūtus, un katram produkta tipam ir sava tabula ar pareizajām atribūtu kolonnām, bet tas ir baigi nesmuki, ja tos tipus jādefinē caur UI, un vēl nesmukāk, ja atribūti var mainīties. `product_attributes` ir normāls vidusceļš starp 2 galējībām; nav nekādu problēmu pielikt vai noņemt atribūtus, nav arī limita atribūtu skaitam. Ja vēl šo tabulu kaut kā kešo, tad vispār nav problēmu.

Kāpēc neder: CREATE TABLE `product_attributes` ( product_id INTEGER NOT NULL, name VARCHAR(64) NOT NULL, value VARCHAR(255) NOT NULL, INDEX(name), FOREIGN KEY(product_id) REFERENCES products(id) ON DELETE CASCADE ) ?