F3llony

I have no life.

Es par argumentu kārtibu. Kāda tam nozime? :P

Vajag: URL fitlrs, kur parametru secībai jābūt tieši tādai pašai, kā pieprasījumā, bet to vajag izmantot Paginātorā

Ko? 

Idejiski varbūt. Realitātē Laravel ir reizes 50 lielāks čakars, kā Symfony. Manuprāt.

Wtf is going on...?

Kā Mr. Key saka. Apstiprinu gandrīz visus rekruiterus, izņemot acīmredzamus spamerus.

Uz doto brīdi uztaisīju profilu par privātu, neko nemeklēju un līdz ar to rekruiteru pieprasījumi daudz mazāk - līdz profilam nonāk tikai tie rekruiteri, kuri sapirkušies super duper rekruiteru packages Linkedinā. 

Imho līdzīgs efekts ir arī cool white apgaismojumam telpās? 

Citā topikā tu nesen uzskaitīji daudz labu lietu par Symphony. Vai arī tas bija domāts relatīvi pret Laravel, un, absolūti skatoties, arī Symphony sūkā?

Symfony nav dāvana, ir daži diezgan kaitinoši momenti arī tam. Absolūti skatoties Symfony pilnīgi noteikti nesūkā, bet vieta kur tiekties vēl joprojām ir. Tas gan man domāt visam un visā.

Es visā savā darba dzīvē neesmu saņēmis nevienu adekvātu piedāvajumu no tā, ko es varētu nosaukt par paziņu loku. Es vispār neesmu drošs, vai gribētu. Tā rodas korupcija, you know :D

Normāls Linkedin, Stackoverflow un Github profils ir pamatā viss, kas nepieciešams + minimālas pašreprezentācijas spējas. Ja ārpus LV, labas angļu valodas zināšanas + spēja komunicēt ar cilvēkiem adekvātā līmenī (nē, Tu nedrīksti lekt virsū intervētājam bļaujot "paldies, paldies, ka pasauci, paldies" *bučiņa*).

Man piedāvājumi birst pastkastē burtiski katru nedēļu. Un ja Tu domā, ka no kaut kādiem sētas kantoriem, tad te ir tikai pēdējā gada laikā interesantākie - Adidas, Facebook (jau otro reizi vispār), AirBNB, Skyscanner, ARM, Microsoft (LOL), pa valstīm dalot pamatā Nīderlande, UK, Īrija, Igaunija (!!!), Francija, ASV, Kanāda, kaudze no Latīņamerikas (nez kādu iemeslu dēļ esmu populār Kostarikā :D), Singapūra, Jaunzēlande, gan remote, gan on-site piedāvajumi. 

Piemēram, Igaunijā tagad start-up scene ir vienkārši whoa, normālus devus ar uguni meklē, gan remote, gan on-site. Atliek vien nosūtīt meiliņu vai divus tech recruitment kantoriem. Un darbojas tas tāpēc, ka recruitment kantori ir ieinteresēti noalgot labus profiņus par iespējams lielāku algu - viņu procenti ir atkarīgi no retention rate un darba algas.

A Tu te, php.lv čakarējies... 

Kā tieši tas ir arguments pret to, ko es teicu? Es nezinu, kas ir tā no universa atdalītā realitāte, kurā Tu dzīvo, bet, pirmkārt, Tava definīcija vārdam "labs" iespējams smagi atšķiras no kāda cita definīcijas. Otrkārt, labu piedāvājumu netrūkst. Un, pat ja statistiski 99% no piedāvājumiem ko pakaļ met var klasificēt kā garbage (nevar), realitātē pietiek kaut vai ar to 1%.

So, recap - labiem developeriem vienmēr pieejami labi darbi. Ja Tev nav pieejami labi darbi, tad, nu Tu jau saproti, kur ir problēma. Ja nesaproti - vēl jo vairāk.

Oi, kruts uzbrauciens. Nedēļas laikā labu darbu neatradīsi, ja vien baigi neveicas.

Ar veiksmi te nav nekāda sakara. Labiem developeriem darbu pakaļ met. Vienā dienā strāda vienā kantorī, otrā, jau citā. Protams, ja skaņas no Tevis vairāk kā labuma, tad ir tā pagrūtāk, jā. 

Tev vispār nevajadzētu neko veidot.

Tu jau darbu atradi, vāvuli? :D

PHP ļauj ērti un ātri veidot aplikācijas tiem, kam aplikācijas veidot nevajadzētu.

Laravel ļauj ērti un ātri veidot PHP aplikācijas, tiem, kam PHP aplikācijas veidot nevajadzētu...

:P

Efumo reportēja moderatoriem, lai aizvāc komentāru, kur prasa algas diapazonu :))

Hahaha :D

Ieviest testus var jebkuram projektam, jautājums tikai - kādus. Neredzu traucēkli kādam vecam projektam ieviest funkcionālos testus, lai nebūtu jākliko formām 15x cauri, lai saprastu visus gadījumus, kur kas strādā.

Kāpēc solo projektiem "nav vajadzības"? Testi nav domāti tam, lai otram pateiktu, ka viss strādā, vai arī otrs kaut ko darot, saprot, ka kaut ko salauza. Tik pat labi, tas "otrs" esi Tu, labojot kodu citā vietā, un radot problēmas citur. Testi nu būtu lieta, ko vajadzētu apsvērt iemācīties, nevis pretoties "papildus kodam". To, ko Tu pavadi "spaidot formas", ja vispār to dari, pārbaudot savu darbu, Tu vari izdarīt uzrakstot kodu, un tas strādā automatizēti.

Maziem projektiem, arī nebūtu ne vainas kaut ko uzrakstīt, lai atvieglotu sev darbu.

This. Pie tam, testēt labu kodu ar unit/bdd testiem ir ļoti vienkārši. Protams, nevajag aiziet galējībās, un arī man netrūkst stuff bez testiem, bet pamatā tie ir mani personiskie eksperimenti kuri pa lielam tiek uzrakstīti, izmantoti kādam sīkumam un aizmirsti. Bet jebkas kas iziet ārpus šī loka ir jātestē. Labi, nav laika, uzrakstīsi pēc tam, bet pateikt, nope, nevajag? Pff. 

Still, labāk par arrogant **hole, kurš domā, ka visu zin.

Es nezinu visu, un ja vari iecitēt, kur esmu ko tamlīdzīgu teicis vai kā savādāk pamatot sevis teikto - zelta dālderis Tev.

Taču, mans viedoklis konkrētajā gadījumā ir pamatots ar jurchika kodu, ko esmu redzējis un jama atbildēm uz dotā koda niansēm ko esmu norādījis. So, ja tas mani padara par arrogant asshole, so be it. Labāk arrogant asshole kā oblivious idiot. Any day.

Precizēšu. Es neesmu pret testiem, bet ir vairākas lietas:

- mikroprojektu budžets (tēlaini sakot, tu nevari nopirkt mersi pa dažiem k, bet ir, kam vajag "ejošā stāvoklī")

- labāk testu nav vispār, nekā ir pseido-testi (viltus drošības sajūta)

- TDD ir tikai viens no vairākiem "approach"

- un vēl virkne lietu.

 

Domāju, ka galvenais bija noņemt ērci.

Un es Tev absolūti piekrītu. Es nedomāju, ka manis teiktajam tiešām vajadzēja milzīgu sarkanu leiblu "common sense applies". Tam tā kā vajadzētu būt pašsaprotami. 

Gala klientam vajag risinājumu, kas strādā, nevis lai tu ej katru dienu uz biroju, vai raksti līdam testus. Tas ir priekš tiem, kuri grib feisītī likt bildītes ar torti "10 gadu jubileja darbā" un "priekšnieks šodien bija labs, esmu laimīgs"...

Salvis 2.0 ...? Manuprāt mēs ļoti labi un uzskatāmi zinām, kas parasti notiek ar "galvenais ka strādā" :>

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.

Huh? Tu esi šausmīgi slikts programmētājs nevis tāpēc, ka neraksti testus, bet tāpēc, ka raksti sūdīgu kodu ;> Zini atšķirību.

Tu šādi piedāvā Jurčikam remote darbu?

Lai visvarenie koda dievi stāv klāt pilsoņiem, kas jamo tiešām pieņems kaut ko darīt... :D

Iedomājies, pienāk līds prasa, eu jurchik, kur testi? A man nepatīk testus rakstīt.. :D Hahahaha....

Hahaha. Hahahahahaahaha... HAHAAHAHAHAHAHAHAHAHAHAHAHA...

Heh, tas pats Eloquents pie jebkura pieprasījuma ģeniali izpilda fetchAll, attiecīgi aizdiršot visu atmiņu, ja rezultāts ir pietiekami liels. Tā vietā, lai dotu normālu single row fetch, kas strādā ievērojami efektīvāk. Protams, ja tādas problēmas rodas, tad prātīgāk bieži vien būtu taisīt jau zemāka līmeņa datu agregāciju, nevis katru rindu lasīt kā veselu modeļa objektu. Un to darīt visām rindām vienlaicīgi.

Doctrine2 relācijas var būt lazy (e.g. ielādē associated objektu tikai kad reāli izmanto) un Iterate, kas ielādē pa vienam rezultātam. By default gan arī ir fetch-all, bet pamatā tāpēc, ka tiek sagaidīts, ka tiks izmantoti realistiski limiti. 

Tajā pašā laikā, uz doto brīdi es rakstu batch procesoru kam nāksies nolasīt un agregēt ap 40-50m rakstu darbus no mysql. Šajā gadījumā, custom code obviously un nekāda ORM. ORM tam nav jebkurā gadījumā paredzēts. 

SQL daba, wtf? Parunāsim vēl par dažādu DBMS enerģētiku un auras krāsu? Ja tu nemāki rakstīt SQL, tad tā arī pasaki, nevis runā par kaut kādām pierastajām formām. SQL sintakse man, piemēram, šķiet ļoti pierasta forma, kad runa iet par SQL pieprasījumu rakstīšanu.

 

Punkts divi, ja tu nemāki izmantot ORM (lasīt - izmanto tur, kur vairs nav jāizmanto ORM), tad tā nav ne ORM, ne SQL, ne PHP, ne node.js vaina, bet gan curved_hands.dll/so, ka viss bremzē.

This.

@Kavacky Ko tur nemācēt, gadiem drukāti tie kveriji, bet kad palieto ko jēdzīgāku, atpakaļgaitu negribas slēgt.

 

Tā arī daru, jaunajā projektā kur ir postgres, optimizēju ar tiešiem pieprasījumiem, ignorējot ORM. Pieaugums apmēram 50%.

Un kādu ORM tad Tu izmantoji, ja ORM-like queries tev pieaugums bija 50%? Un vai tie 50% nebija Object side?

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.

Datubāzēs darbojas principi denormalizēti un normalizēti dati/shēma. Ne viens ne otrs princips ir labs vai ļauns, un atkarībā no mērķa abi ir pielietojami tai vai citā gadījumā un ir datubāzes shēmas, kurās duplicēti dati ir ne tikai vēlami, bet pat nepieciešami. Piemēram, milzīgas, denormalizētas agregācijas tabulas. 

Savukārt, Elasticsearch meklējumos pēc kompleksiem nosacījumiem krietni pārspēj Mysql.

This.

"If the only tool you know is a hammer, you tend to see every problem as a nail". 

Dzēst, F3llony bloķēts. Neveido diskusiju. Pubertāte un atzinības trūkums, acīmredzams. Nav ko troļus barot.

Es vēl joprojām neesmu dzirdējis no Tevis nevienu argumentu izņemot "es esmu slinks un man nepatīk shema constraints". Redzēsim, cik industriāls būs Tavs risinājums, kad kādam nabaga frēzes operatoram nozāģēs kāju, jo Mongo nejauši papisīs vienu updeitu un silently nofeilos, tāpēc ka Wuu lai palielinātu ātrumu (kas ir galvenais) noteiktu darbinās visus klientus ar WC:NACK vai minority...

Lūdzu, cienītie, tā arī rodas tādas LNB Mongo bāzes, knapi kopā turas, jo šitādi kretīni savu DB izvēli pamato ar teikumu like "uhh ohhh yeyy dokument store un grāmatas taču ir dokumenti, right? There MUST be something!".

Divas problēmas. Tev nav priekšstata kas ir vairākums, un Tu nedomā.

Industriālo softu. Mongo tur spīd. Hahahahaha. Because fuck data integrity. :D

Mongo lieto 2 veidu devi - tie, kam vajag document-store un tajā glabā document-alike datus, un tie, kas ir slinki nejēgas. 
 
Mongo spēks ir semi-schema-free agregācijas un map-reduce. Pilsoņi, kas mongo izmanto kā datubāzi vienkāršam CRUD ir pilnībā nafig saspiedušies. Tas ir tas pats, kas Casandrā glabāt blogpostus savam kaķu blogam vai Hadoop pirkumu sarakstus rakstīt. Un devi, kas izdomājuši glabāt Mongo jebko, ko nevar atļauties prosta izdzēst un/vai zaudēt imo ir pilnīgi tizleņi.

If you want to sleep at night, don't click here.
 
@aaxc Tava problēma ir ka Tu vēlies column-alike datus glabāt row-like struktūrā. Tātad, kas tie par datiem? Vai pēc visiem šiem datiem Tu jēlkad meklēsi vai kaut kā ar jamiem darbosies? Vai tev tiešām nepieciešamas 10,000 "kolonnas"? Varbūt viss ko tev vajag ir glabāt šos parametrus vienā kolonnā DB saserializētu + vienkārši tos barot kādam search engine, kas ir paredzēts meklēšanai, piemēram, Ellasticsearch? Jo tā tabula baigi jau nu izskatās pēc metadatiem, pret kuriem veic meklēšanu and stuff.

Džavistiem - https://jitpack.io