qwerty

ReactJS ir kļuvis par manu absolute top leader šajā jomā.. Iesaku. Un nedomāju, ka tuvākajā laikā kaut kas mainīsies.

Codez, es bieži brīnos, kur tu tāds esi padevies. Bet tas nav uzbrauciens, tas ir izbrīns. Cik nācies lasīt diskusijas, tu spēj izcelties programmēšanā, ekonomikā, fizikā, bioloģijā, ķīmijā, matemātikā, pedagoģijā.. Nu nopietni, kā? Cik tev gadu, kādu skolu (un vai vispār) tu esi beidzis?

Varbūt pilnīgi beztēma (un pilnīgi nesaistīta ar draugiem grupu), bet.. Parasti programmētājam ir kaut kāds workstations, kurā viņš ikdienā strādā (operētājsistēma un teksta editors). Vajadzības gadījumā varētu strādāt arī pie kā cita, bet 99% laika parasti pavada vienā vidē.. Es piemēram ikdienā strādāju ar Ubuntu un Atom, bet, ja vajag, varu piesēsties pie Windows 7 ar Sublime textu. Bet mainot darba vietu (ofisu) parasti tiek mainīts arī dators, pie kā cilvēks strādā. Nu man tā bijis kādas reizes 3, nekāda mega pieredze nav, bet tomēr. Un tad situācija ir kā nu kur. Piemēram, ja esmu Linux pro un ikdienā gribu strādāt ar Ubuntu un Atom editoru, bet darba vietā ir kaut kādi tīklā saslēgti datori, kas refreshoti no viena iso faila, un tur ir piemēram windows 7 ar sublime text vai phpstorm, tad esmu neapmierināts. Vai arī manam kursa biedram, kurš bija redzējis tikai Windowsu, pirmajā prakses dienā bija jāsēžas pie crunchbanga. Ar kādiem variantiem šīs lietas risināšanā jūs esat sastapušies? Vienreiz man piedāvāja stiept savu portatīvo no mājas līdzi katru dienu, bet tas tomēr ir tāds meh..

Nesaprotu, kā pareizi ar phpunit notestēt šādu situāciju (funkcionālais tests): Aplikācijai ir route /get_articles, kas pieņem GET parametru order_by (pieļaujamās vērtības - timestamp, likes, stars, priority) Šis route aiziet uz kontrolleri, kas izdara dažas maznozīmīgas lietas, un tad izsauc Article modeli, kas pieprasa datus no DB. Testa vidē datubāzē ir 5 zināmi article. Tātad, man nav skaidrs, ko šeit testēt. Ja tas ir funkcionālais tests, tad laikam es sagaidu, ka pieprasot /get_articles, ja visi parametri ir pareizi: Response kods ir 200 Atbilde ir JSON, kurā ir atslēga articles Articli ir sakārtoti pēc order_by parametra - kā šito realizēt un vai vispār vajag? Ja parametri nav pareizi vai nav vispār padoti: Response kods ir 422 Neskaidrība ir ar to order_by parametra padošanas testēšanu. Tā kā testa datu bāzē ir tikai 5 article, tad es teorētiski varu notestēt vai iegūtie JSON dati ir sakārtoti pareizi. Kā to darīt: vai man funkcionālajā testā uztaisīt atsevišķu query, kas no datubāzes pieprasa articles ar attiecīgu order by X ? vai arī man testā hardkodēt to datu JSON, kas ir datubāzē? (sanāk, ka nav DRY, jau dati atkārtojas gan datubāzes seedā, gan testā) Vai arī to vispār nelikt funkcionālajā testā un jāraksta Article modeļa unit tests?

Ja ielieku savā lapā Facebook share pogu, izskatās, ka vienīgais veids, kā norādīt manu custom virsrakstu un tekstu šim share ir lietojot ob:description meta tagus. Problēmas sākas tad, kad man vienā lapā ir vairākas share pogas atšķirīgam saturam (saraksts ar article, piemēram) Katram article loģiski ir citādāks title un desciption, bet meta tagus es varu lapā pievienot tikai vienu reizi! Ja tos dinamiski nomaina ar jquery, izskatās, ka Facebook to neredz. Man vajag alternatīvu tiem ob meta tagiem, lai vienā lapā varu uzturēt vairākas share pogas. Twitter un draugiem.lv skaisti atļauj katrai like pogai padod šos parametrus. Nu, piemēram, tvnet.lv sourcē varam apskatīt, kā tie tagi izskatās. Bet tā kā viņiem vienā lapā ir tikai viena share/like poga, tad viņiem nav problēmu. Es gribu, lai vienā lapā ir vairāki article. Ko darīt?

Vai kāds var 100% apstiprināt, ka Draugiem.lv API nav tāda fīča, kas ļauj Draugiem.lv pases aplikācijai, kurā reģistrējies lietotājs, postot ierakstus draugiem.lv profila "runā" sadaļā? Cik skatos viņu API, tad nav, bet tas ir dīvaini, jo twiteris un facebuks gan atļauj līdzīgas mahinācijas ar twītiem vai sienu.

Nespēju saprast vai man no DB migrācijām ir lielāks labums vai posts. Teorētiski ir skaidri saglabāti soļi kas un kā darīts ar tabulām un kā šos soļus atcelt, bet tajā pašā laikā vēlāk no šīs informācijas tāpat nav nekādas jēgas, jo nevienam parasti neinteresē kā DB izskatījās pirms mēneša vai diviem - viss iet tikai uz priekšu. Arī bieži rodas konflikti, kad līdz pusei nostrādājusi un nofeilojusi migrācija aizkavē. Ja jāveic kādas sarežģītākas izmaiņas, jāizmaina foreign keyi, tad migrāciju ->down() metožu uzrakstīšana ir gatavais murgs. Pilns up un down cikls ir diezgan lēns, sākot ar kādām 10 sekundēm. Dažreiz liekas, ka ērtāk būtu glabāt tikai shēmas dumpu no datubāzes. Bet man pieredze par mazu lai izsvērtu kura metode ilgtermiņā atmaksāsies. Viedokļi?

https://www.youtube.com/playlist?list=PL442FA2C127377F07 Dod ziņu, kad noskaties visu.

Nu labi varbūt pārspīlēju. Kādi 60 id varētu būt.

Vai ir pieļaujams, ka regulāri tiek izpildīti query, kuriem pievienots WHERE IN () operators, kurā ir tiešām DAUDZ vērtību, piemēram, WHERE IN($ids), kur $ids satur 1000 dažādus identifikatorus? Jeb eager loading Neko ļoti daudz no indeksēšanas nesaprotu, bet vai šādi kvēriji pie lielāka datu apjoma nepaliks ļoti lēni?

To stackoverflowa jautājumu jau izskatīju, tur nekas par to nav. Lielāko daļu googles linkus arī. Tos iegūtos rezultātus ir paredzēts sūtīt uz klienta pusi kā daļu no JSON atbildes. Tāpēc vienīgais, ko varu iedomāties - Article modelī definēt $visible laukus priekš pārvēršanas uz JSON. Tad to, ko man atgriež Eloquent, pārvērst uz JSON un vēlreiz atpakaļ uz PHP objektu. (Man neder uzreiz iegūtais JSON, jo tas nav viss JSON, kas jāsūta..)

Cerams ir kāds Eloquent zinātājs. Tātad, ja ir kāds vienums datubāzē (piemēram, raksts Article) kas ir daļa no on-to-many relationshipa, tad varam lietot ->with() metodi, piemēram: Articles ::select('article_id', 'article_text') //Seit ir probleema ->with([ 'user' => function($q){ $q->select('user_id', 'user_name'); // Sis straadaa kaa paredzeets, no usera nak tikai id, name } ]) ->get(); Problēma ir tāda, ka ->select() priekš user strādā kā paredzēts, bet ārējais select, ar ko es gribu ierobežot, kādus datus ievākt no article, rada problēmu - atgrieztajiem objektiem ir noņemts nost 'user', jo tas it kā nav ārējā select sarakstā. Bet, ja es pievienoju tur to 'user', tad izmet erroru, ka datubāzē nav kolonna 'user' - Eloquent nesaprot, ka es ar to domāju nevis kolonnu, bet with() relationshipu. Vai kāds zina, kā varu norādīt interesējošās kolonnas gan Article, gan User ?

Ko tad, ja viņa laiki nāk no dažādām laika zonām, piemēram, Džakartas un Latvijas?

Well, lielākā daļa no appām ko pēdējā laikā taisu ir single page appas, kas no servera saņem tikai JSON. Ar freimworku nav nekādu problēmu principā neizmantot View un kontrolleros padod JSON. Tā kā servera puse tām appām ir diezgan vienkārša, tad tagad domāju vai nevarētu visu procesu paātrināt ar WP un pats vairāk vai mazāk koncentrēties uz frontendu.

Man ir pieredze ar vairākiem programmēšanas ietvariem un es zinu ko ar tiem var paveikt. Tajā pašā laikā esmu diezgan daudz dzirdējis par un ap Wordpress, bet nav bijusi praktiska pieredze ar to strādāt un es īsti nezinu ko ar to vispār var paveikt. Tāpēc vai zinošāki cilvēki nevarētu apskaidrot, kādas ir tādas mājaslapas pazīmes, ko būtu labāk taisīt ar freimworku, un kādas ir tādas mājaslapas pazīmes, ko būtu labāk taisīt ar wordpresu? Iztiksim bez fleima un visi pieņemsim, ka freims nav labāks par WP un WP nav labāks par freimu, viss atkarīgs no use case. :) Respektīvi kādi ir hinti mājaslapas uzbūves prasībās, kas norāda par labu vienam vai otram tūlim? Kādi ir lielākie ierobežojumi, ko nevar vai galīgi nevajadzētu veikt ar WP?

Pieņemsim, ka ir portāls ar ziņu rakstiem. Katram rakstam ir Facebook Like un Twitter tweet poga. Mērķis is sakārtot rakstus pēc tā, kāda ir like un tweet kopsumma katram rakstam. Pēc tam parādīt lapas izmantotājiem, kuri ir populārākie raksti. Izmantojot Facebook un Twitter API, var noteikt, cik like ir vienam konkrētam rakstam. Bet, ja es gribu sortēt visus rakstus, tas nozīmē DAUDZ api pieprasījumu. Kāds te varētu būt risinājums? Varētu pieņemt, ka katru dienu rodas 100 jauni raksti. Šis popularitātes mehānisms varētu darboties tikai rakstiem, kas jaunāki par vienu nedēļu. Varētu arī tā, ka like skaits updeitojas tikai reizi stundā. Tas nozīmē, ka ir 100*7=700 aktīvi raksti, katram jāveic divi (FB, Tw) pieprasījumi ik stundu. Tātad 1400 pieprasījumi stundā, 33600 pieprasījumi diennaktī. Neesmu pārliecināts, vai kas tāds ietu cauri. Visticamāk iesprūstu kaut kur pie FB vai Tw rate limitiem.. Ir kādas idejas?

Paldies. "Ieteikt" funkcionalitātē dokumentācijas praktiski nav. Ir tikai tāds tūlis, kas iedod koda snippetu, ar ko uzburt "ieteikt" pogu savā web lapā. Kā arī vajadzētu precizēt uzskaitīšanas metodi. Cik es saprotu, tas "count" apraksta ieteikumus par konkrētās lapas URL, bet parametriem title un text nav nekādas nozīmes (attiecīgi TIKAI url kalpo kā identifikators tam, kas tiek ieteikts) <script type="text/javascript" src="//www.draugiem.lv/api/api.js"></script> <div id="draugiemLike"></div> <script type="text/javascript"> var p = { title:"Mans virsraksts", text:"mans teksts" }; new DApi.Like(p).append('draugiemLike'); </script> Bet draugiem.lv funkcija "atcelt" pie runā ieraksta, ko esi ieteicis, arī netiek ņemta vērā - tas count nemainās. Vismaz tā man pēc eksperimentēšanas izskatās.

Pacelšu mironi, bet šis jautājums kļuvis man aktuāls. Vai tagad, 2014.tajā, draugiem.lv ir API, kas ļauj to izdarīt? Cik apskatīju viņu piedāvāto dokumentāciju, tad nekas tāds nav pieminēts. Šitā html parsēšana ir normāls mazohisms..

Mēģinu saprast, kā strādā draugiem.lv pase, bet es nesaprotu kāda ir saistība starp sesiju uz mana domēna un uz draugiem.lv domēna. Tātad viņi iesaka lietot https://github.com/Draugiem/draugiem-php-sdkTajā ir funkcija ->getSession(), kas kaut kā maģiski nosaka, vai lietotājs ir ielogojies, vai nav, 1. Savā example.com nospiežu uz pogas "Ienākt ar draugiem.lv pasi" 2. Mani redirekto uz draugiem.lv. 3. Ievadu savus datus 4. Draugiem.lv serveris pārbauda, vai tie ir pareizi 5. Mani redirekto atpakaļ uz example.com 6. ->getSession() tagad zina, ka esmu ielogojies Pēc manas saprašanas, pēc ielogošanas draugiem.lv, viņu serveris man izveidoja sesiju un cookie ar sesijas ID. Uz sava example.com man ir jāizveido pašam sava sesija. Bet ja mani redirekto atpakaļ uz example.com, tad draugiem.lv cookie nenonāk līdz example.com, jo pieder draugiem.lv. Tad kā tā funkcija zina, ka esmu ielogojies? Kur es kļūdos? Kas pie šāda autorizēšanās modeļa man jāglabā example.com datubāzes tabulā ar informāciju par lietotājiem? Draugiem.lv user_id ? Ja lietoju PHP platformu, kas neizmanto built-in sesijas, bet encrypted cookies, tad vai es varu sasaistīt to ->getSession ar savu mehānismu?

Yep, tikai tur teikts: Izklausas, ka to tomer vajadzes

Javascript būs sarežģītāks par php šajā gadījumā. Labāk domā kā norealizēsi to..

Pateicoties codez aktīvajai trollēšanai es arī esmu izlēmis vismaz apskatīt Scalu dažas dienas un papētīt, kas tur ir tik awesome.

Scala is the answer, who cares what the question was..

Es kaut ko nesaprotu - kāda jēga vispār PHP rakstīt funkcionālos testus, ja tos ir reālistiskāk rakstīt javascriptā? Proti: 1. Piemēram, ja raksta funkcionālos testus Laravel, tad iespējams darīt, piemēram, šādi - izsauc kādu route aplikācijā un tad pārbauda, vai lapas title ir pareizs. 2. To pašu varētu notestēt javascript pusē ar kādu Selenium freimworku - pieprasot to pašu routu un pārbaudot title. Otrais variants ir reālistiskāks. Tad kāpēc vispār pūlēties to darīt PHP? PHP lai paliek unit testi modeļiem+DB un tml..

Well, yes, tas ir Laravel. Runa iet par integrācijas testiem. Nu skaidrs. Tad laikam tas nav nekāds labais risinājums un jātaisa man arī atsevišķa testu DB.