briedis

Haha, jā, es un vēl 2 :D

Haha, tieši gribēju teikt - respect, ka vanilla :D

Nezinu kā tas REACT tur darās, bet gan jau this konteksts pazūd...

Meklējam arī kolēģi ThePrintful :) https://www.theprintful.com/darbs (zem DraugiemGrupas, attiecīgi, visas tās pašas ekstras, kas citām draugiem.lv vakancēm)

Pāris vakances šeit: https://www.draugiem.lv/work/

Šis stilīgs :) No aizmugures izskatās, kā galda lampa kājām gaisā

Leaf? Tas ir kaut kas maģisks, nenovēlu nevienam ar to strādāt :D Un vēl smarty, mmmmmmmm..

Tu jau atlasi tikai vienu lapu (20, 30, max 100 lietotāji), nevis tūkstošus. Nekam tur nevajadzētu bremzēt ar indeksu, pat ja ir ļimons ierakstu.

Var visu vienā vaicājumā, bet vai vajag? Čakars apstrādāt būs tādu kluci, neglīts kods. Es darīt brutāli - atlasi lapu ar lietotājiem, masīvā ievāc visus user id, un tad katru vaicājumu atsevišķi ar nosacījumu, where person_id IN (saraksts ar tiem vajadzīgajiem uid'iem) un smuki sasortē pa masīviem. Protams, nebūs, tik efektīvi, kā visu ar vienu vaicājumu, bet kods smukāks - var sadalīt N funkcijās vienā klasē

Varbūt beigās pietiktu ar to, ka ieviestu kešošanu :D Jāsaprot, kas tad ir tas pudeles katls? CDN + normāla kešošana / optimāli kvērijis sniegtu noteikti 10x lielāku labumu, kā migrācija. 45k 6 stundās ir 125 pieprasījumi minūtē, kas ir diezgan smieklīgs skaitlis, kuru, man liekas, ka pat kāds raspberry pi varētu mierīgi pacelt. Pieslēdziet new relic, ātri vien sapratīsiet, kas to pasākumu bremzē.

Uz nix uzlikt/piekompilēt visādus php libus ir stipri vienkāršāk (kaut kāds imagick uz win pamatīgas galvassāpes sagādā, vismaz man :S) Gan jau, ka vieglāk arī atrast personu, kas administrē nix, nekā win, ja rodas nepieciešamība.

Mhm, kāda jēga maksāt par kaut kādu IIS serveri, ja viss un vēl labāks ir pieejams par velti?

Nē, tas ir heits.

Paskatieties kā pierakstās where nosacījums: http://www.yiiframework.com/doc-2.0/yii-db-query.html#where()-detail ...un kāda ir Laravel dokumentācija: http://laravel.com/docs/5.1/queries#where-clauses Where in Yii: ->where(['IN', 'id', [1,2,3]); Laravel: ->whereIn('id', [1,2,3]); (id IN (1, 2, 3)) AND (status = 2) Yii: ->where(['id' => [1, 2, 3], 'status' => 2]) Laravel: ->whereIn('id', [1,2,3])->where('status', 2) Yii: $model = User::find()->where('userid > :userid', [':userid' => $userid])->one(); Laravel: $model = User::where('userid', '>', $userId)->first(); Yii viss ir kaut kāds samudrīts, Laravel - skaists un elegants.

Joprojām heitojot Yii.... $user = Yii::app()->db->createCommand() ->select('id, username, profile') ->from('tbl_user u') ->join('tbl_profile p', 'u.id=p.user_id') ->where('id=:id', array(':id'=>$id)) ->queryRow(); vs $user = DB::table('tbl_user AS u') ->select(['id', 'username', 'profile']) ->join('tbl_profile AS p', 'p.user_id', 'u.id') ->where('id', $id) ->first();

Tad nu gan, viena koda rindiņa.

Protams, lietotāja avatar bildītes varētu glabāt, bet nu ja vajag pieglabāt bildes orģinālu, un lietotājs vnk ielādē no sava telefona kādu 6MB bildīti, vai vēl labāk no fotoaparāta kādus 10 MB. Es īsti neredzu vispār nekādus argumentus, kāpēc DB būtu labāk. Ērtāk? Ja jāraksta kaut kāds servēšanas skripts, tad tas vien jau ir neērtāk...

Kur tad tu sakešosi bildes? :D un kād tu no php viņas atrādīsi lietotājam? enkodēsi kā base64, vai ar php visas outputosi? :)

Kuru rausta 0.3 vai 0.02? Kamēr nav >0.5, pofig.

Kā tad tu izvadi bildes? Un, ja teiksim bildes ir 10MB?

Te ir internets - uzvar tas, kurš pēdējais kaut ko iepļerkst.

Ģenerators ir figņa, tādu var izmantot tikai, kad nāk klāt pavisam jauni modeļi. Cik relācijas esmu licis, tik visas ir bijušas klāt esošiem modeļiem, kur jāraksta viss ar roku. Kaut kāds ģenerators neattaisno to, ka ir sūdīga dokumentācija.

Salīdzini šīs dokumentācijas - cik viegli ir atrast info par one-to-one relāciju: http://laravel.com/docs/5.1/eloquent-relationships vs http://www.yiiframework.com/doc-2.0/guide-db-active-record.html

Jā, tā nu doķos ir rakstīts, bet vismaz tagad ir saprātīgs interfeiss.