aaxc

Algas nenorādīšana ir padomju mantojums. Ja, piemēram, ASV sportistu algas ir publiski pieejamas, tad Krievijā tās tiek īpaši slēptas. Šāda sistēma arīdzan palīdz darba devējiem samazināt izdevumus, pieņemot darbā cilvēkus, kuri mazāk paprasīja vai maksājot mazāk, kā kolēģim. Situācija, ka vienā ofisā ir divi vienlīdz kvalificēti darbinieki, bet vienam alga ir uz pusi lielāka tikai tāpēc, ka viņš paprasīja vairāk (vai otrs nebija par sevi pārliecināts un paprasīja mazāk) ir ikdiena. Un nevienam citam, kā darba devējam, tas pa labu nenāk. Ja "rietumos" profesionāļus piesaista norādot atalgojuma sistēmu, daļas uzņēmumā un vēl dažādus finansiālus labumus, tad mums ar uzņēmuma stabilitāti un pasakām, ka citur būs sliktāk.

Vai šis ir kāds mājasdarbs?

Uz Vecrīgu ir pārvākušies, jeb Republikas laukums tagad skaitās Vecrīgā?

Use absolute urls maybe?

Made my day

Paga, vaitad display ports nav šamajam?

Ieliec viņus vienā divā un tam nodefinē klasi vai uztaisi JS eventu

Kautkas at meta datiem laikam ne tā, vai kas to lasa: <meta name="twitter:image" content="http://www.ipexpoeurope.com/design/ip15a/images/ipexpoeurope_square.png" /> <meta property="og:image" content="http://www.ipexpoeurope.com/design/ip15a/images/ipexpoeurope_square.png" />

https://www.davidwolfe.com/scientist-work-before-10-torture/

Varbūt ceļojumā pa Ķīnu? https://bytes.com/topic/python/answers/654619-calling-postgresql-stored-procedure

Un tikai tā, kā tad savādāk skatīties uz savu lolojumu? Tjipa: "taisu štruntu, kuram jau ir 10 labākas versijas, bet toties savu!" ? Ja tu taisi kautko līdzigu, kas jau ir, tad tikai tad, ja vari to uztaisīt labāku.

Man ar tikpat kā identisks setups, tikai, kā jau minēju, laptops cits:

Atkarīgs no nepieciešamības. Man ir i7 Lenovo Ideapad lai var klientiem atrādīt veikto. Ofisā es viņam pat nepieskaros, jo uzreiz pieslēdzu klāt docking-station ad diviem 2k monitoriem, klavas, peles un austiņām. Idejiski, man portatīvais kalpo kā trešais monitors epasta un skype lasīšanai. Mums ofisā ir tikai divi stacionārie un tie paši maki.

heh, http://rotermannsquare.lv/ izdomājis atkal tautu čakarēt un pat jaunu lapu pasūtijis. Ja nav noslēpums, cik šoreiz par šāmo samaksāja? Par pirmo versiju 2009. gadā 1.6k Ls avansu man iemaksāja, bet pēc tam izdomāja likvidēties un pārējo tā arī nesaņēmu :/

Vaitad tieši tāpēc no Symphony netika atvasinās Laravel? Idejiski.

Pēdējais jau ir HD Home-cinema system :D

Neesmu pats nekad mēģinājis, bet var arīte meklēt freelance/darba piedāvājumus: http://stackoverflow.com/jobs?tags=php

Droši, mēs vēl tikai lemsim, vai pāriet uz Mogo vai pārstrukturizēt MySQL, tākā papildus viedokļi vēl noderēs ;)

Protams, tas ir viens no variantiem, kā atrisināt šo situāciju, bet jautājums ir ātrdarbībā. Kas būs ātrāk izfiltrēt: mongodb datus vai šādus? Cik es sapratu, monogo vajadzētu ātrāk apstrādāt šāda veida filtrēšanu.

Patreiz, ar 18 produktiem, ir 397k šādi ieraksti (tie pie tam ir mēnesi veci dati, prodā ir 430k patreiz). Kas notiks, ja man produkti būs 180 ? 500? Un tas ir tikai pirmais vilnis. Man vajag ieilkt pamatu sistēmai, kas strādās ar 10k+ produktiem un tad šāda struktūra būs vēl mazāk pārskatāma.

Jā, nākotnes doma ir izveidot sistēmu, lai produktus un tipus var operators pats sadefinēt un ievietot pēc iedotās specifikācijas un no scripta līmeņa, nekas nav jāmaina. Šobrīd strādājam pie šīs pamatstruktūras izstrādes/pārveides.

Negribas but nekrofilam, bet vajag padomu: Tātad, projektā izmantojam mysql produktu tabulu ar papilddatiem. +----------------+ | products | +----------------+ | id | | name | | type | | color | | image_id | | collection_id | +----------------+ Problēma rodas pievienojot jaunus produktus ar citu tipu, jo tiem ir citi papildus parametri, kā rezultātā nākas paplašināt tabulu: +----------------+ | products | +----------------+ | id | | name | | type | | color | | image_id | | collection_id | | width | | height | | weight | | offset_x | | offset_y | | angle | | coordinates | | sex | | size | | ... | +----------------+ Tākā tuvākās nākotnes plānā ir produktu klāstu palielinat no pārdesmit tipiem uz vairākiem simtiem, šī tabula ātri vien izskatities nelietojama. Veidot subtable vai katram tipam atsevišķas tabulas arī nebūtu prāta darbs. Līdz ar ko ir doma pariet uz MongoDB, kur noradīt produktu, tīpu un pārejo jau kā specifiska tipa/produkta veida parametrus. Šādi katrs produkts saturētu tikai sev vajadzigo informāciju, kuras struktūre es vēlāk nolasu, lidz ar to man pat nav vairs svariga kopējā struktūra - es izmantoju tikai konkreta produkta parametrus. Idejiski vis izskatas rožaini (pradukti satur tikai nepieciešamos datus, pievienojot jaunus produkturs tabula nav jāčakarē, viegli atfiltrēt, ielasot produktu es uzreiz iegūstu vajadzīgo struktūru, pat nav jāčeko kas tas par tipu), bet tākā pats produkcijā ar liela apjoma mongo datiem neesmu ņēmies ( uz konvertāciju patreiz vien jau aizies 400k+ produktu ar vairākiem miljoniem variāciju ), gribētos dzirdēt no pieredzējušiem lietotājiem potenciālās problēmas, lai nav tā, ka pēc dažiem mēnešiem ir jarauj mati no galvas ārā un jādomā kā to visu pārverst atpakaļ uz mysql.

Locked for massive offtopic

Nu gan jums offtopics panesās. CIk ilgi, līdz kāds sāks lielīties, ka ar perfokartēm jau programmējis?

Spriežot pēc iepriekšējiem postiem, runa ir par http://writer.is. Un jā, lūdzu precizēt, kāpēc nav uzticams.