daGrevis

Name atgriež stringu? Price atgriež number? Woah! Malacis, ka sarakstīji. Nebūtu sapratis.

> Jūs nerakstāt klāt, ka tas int ir, teiksim, reāli dzēsto ierakstu skaits? Es nerakstītu ka tas ir integers (es runāju tieši par tipu rakstīšanu). Es raktītu ka tas ir ierakstu skaits kas tiks izdzēsts.

Arī fakts. Ja jau tik ļoti gribas tipus, kāpēc PHP?

Fun fact — augstākminētajā piemērā ir vairāk docstringi nekā kods + normāli komentāri. Noise much?

Neatmaksājas. https://github.com/laravel/framework/blob/5.2/src/Illuminate/Validation/Factory.php Šausmīgs noise un ieguvumi ir apšaubāmi. Parasti jau ir skaidrs ko funkcija saņem un atgriež tikai paskatoties uz funckijas nosaukumu un argumentu nosaukumiem. Ja tomēr nav skaidrs, lietderīgāk būtu salabot kodu, nevis pielikt hintus par to kas tur notiek. Comments being out of sync noteikti ir problēma. Iemesls, kāpēc lietot, daudziem varētu būtu autocomplete no IDEs.

Tie komenti ar argumentu tipiem un return tipu ir bullshits.

> Tāda "tikai vim / notepad" lietošana ir raksturīga iesācējiem, kas vēl nav saskārušies ar situāciju, ka tas, ko viņi iemācījās no galvas, nevienam nav vajadzīgs jau trešo reizi. > jo cilvēki tomēr raksta ar melnu tinti uz balta papīra, bet krāsaini burtiņi uz melnas tāfeles parasti ir ēdienkarte hipsterīgās kafejnīcās Nice opinions!

Nu nez, es nevaru ilgi (2h+) būt uz muguras guļoši. Gribas uz sāniem griezties. Bet nu go ahead, varbūt aizsāksi jaunu trendu!

Es apstiprinu tikai tos cilvēkus, kurus zinu. Jūs Facebookā arī aptipriniet visus?

Viedoklim ir jābūt argumentiem, ne?

> Vajag ieviest noteikumu, ka nedrikst publicēt darba sludinājumus bez algas diapazoniem. ++

Vai arī var vienkārši nedzīvot Londonā, San Francisko vai tamlīdzīgās vietās.

Tāpēc visiem ir jāmācās Scala.

> Veidot subtable vai katram tipam atsevišķas tabulas arī nebūtu prāta darbs. Kāpēc? Vai produktu tipi būs dinamiski, tobiš produktu tipus varēs pievienot/noņemt izmantojot UI?

Jurchik, vai simpleframe izmanto kaut kam nopietnam?

> >Catching multiple exception types > > pa taisno no Javas ņemts. So? Normāla fīča.

Es kādreiz lietoju Skeleton, bet pēdējais komits viņiem 2014. gadā.

Nekad neesmu teicis, ka nav jāizmanto GUI, ja tā ir ērtāk. Tikai uzsvēru, ka vienmēr varēs izdarīt vairāk ar termināli, un, ka nav jāsaka “we don't need it“.

> Teikšu godīgi, bez paniskas gūglēšanas es to nevarētu, un arī tad pasvīstu. Nevajag baidīties, Google ir programmētāja draugs! Par svīšanu - atkarīgs no attiecīgā uzdevuma. Augstāk minētais bija vienkārši piemērs un ne jau no vieglākajiem. > Kaut kā neizprotu līdz galam tos branchus, mērdžus, pul requestus... saprotu, ka tas viss labi un gudri, bet nu man tas šķiet sarežģīti. Iesaku mēģināt savā galvā vizualizēt commitus kā koku, padomāt kā diff maina tavu kodu (datus) starp commitiem un kā tas tiek saglabāts, apstrādāts. Nekas tur tāds _ļoti_ sarežģīts nav. > kur jāliek vien lietā SQL (konsole), jo query builderis (GUI) ir par īsu. Exactly my point. > Kas tas tāds par flowu? Sūtat zip failā patchus caur e-pastu arī? :)) Nekādus patchus pa e-pastiem, lūdzu! :D Augstāk minētais bija tikai ilustratīvs piemērs kaut kam custom, pirmais kas iešāvās prātā. :)

> Also - so pro, much cli. Except we don't need it. Nu gan... Kad saskarsies ar kaut cik custom problēmu, uzraksti! Piemēram, * izfiltrē man Git branchus, ne vecākus par trim dienām, * kuros ir bijuši jauni commiti salīdzinot pret master branch, * tad saglabā šos commitu messages pa Markdown failiem un šos failus atsūti man uz e-pastu. Šādu problēmu tu vari sabakastīt neizmantojot termināli? Nez vai. Daudz vieglāk būtu uzrakstīt dažas rindiņas Bash. Nevajag apgalvot, ka jums nevajag shellu; tas ir tikai vēl viens toolis ko ir ļoti labi zināt un izmantot, kad nepieciešams.

Tabulas uz Firefox 46, Arch Linux izskatās identiski. Absolūtais elements gan ir borken.

> Dizains neērts, nepārskatāms, pretīgs izkārtojums. Es ceru ka tu runā par Bitbucket.

Man patīk kā Wuu tik īsā laikā no nooba izauga, viņaprāt, par profiņu. :)

Ja nekļūdos, pika (klients RabbitMQ uz Python) piedāvāja jau kko gatavu kas ļāva tā darīt. https://pika.readthedocs.io/en/0.10.0/index.html

> daGrevi, es vēl gaidu, kad pastāstīsi sīkāk par saviem fona procesiem, interesantos aspektus! :) Bijām uztaisījuši tādu abstrakciju, ka ir bāzes klases ar nosaukumu `BaseService`, kuru manto visi servisi. Tad bija noteikta failu un direktoriju struktūra kurai vajadzēja sekot kad taisi servisu. Tālāk jau Docker mācēja no tā uzbūvēt image un pēc tam uzspawnot containeri. Katram servisam arī bija klienta klase. Ar servisu tu sazinies izmantojot klientu. Šeit ir pseudo-kods ar diviem servisiem: ~~~ class UserService(BaseService): def create_user(...): # ... def delete_user(...): # ... ~~~ ~~~ class PaymentService(BaseService): def deposit(...): # ... def withdrawal(...): # ... ~~~ Klientu klases nebija jāraksta — tās tika auto-uzģenerētas runtimā. Same ar worker kodu, tas arī nav service-specific. Nākotnē bija doma rakstīt klientus arī PHP, jo mums ir cita aplikācija, rakstīta PHP, kurai arī vajadzētu runāt ar servisiem. Tad ir, piemēram, web node kura, izmantojot klientu, runā ar servisiem kuri atrodas, iespējams, uz cita datora. Smukā lieta te ir tur, ka programmētājs, most of the time, var aizmirst, ka `UserService` atrodas uz cita datora. Tas kas notika under the hood, pateicoties RabbitMQ, bija taska ielikšana message queue. Tālāk jau `UserService` workers to paņēma uz izpildīja. ~~~ def sign_up(request): form = SignUpForm(request.data) if form.is_valid(): UserClient.create_user(form.data) # UserClient, nevis UserService. ~~~ By default visi taski pildās asinhroni. Metode `create_user` atgriezīsies instanti. Bija iespēja pateikt, ka gribi gaidīt rezultātu no vienas vai vairākiem calliem. Te jau parādās tas aync nature on backend, ko briedis noliedza. Redzi ka tomēr var būt. :) Arī patīkami ka šis viss scalojas horizonāli. > Cik līmeņos viņi sarunājās, cik tādi procesi vienlaicīgi gaidīja (cik viņi bija saistīti)? Procesi vispār nav saistīti. Viss kas viņiem ir kopīgs ir runāšana caur RabbitMQ. Ko tu biji domājis ar tiem līmeņiem?