F3llony

Ā jā, this. https://medium.com/@wob/the-sad-state-of-web-development-1603a861d29f

Orly? T.i. tu gribi teikt, ka ja tu ar HTML norenderē milzīgu blāķi un tad to pašu blāķi pieprasi no ar AJAX un renderē frontendā, lietojums būs tāds pats? :> I beg to differ.

Ir divas atvērtas pozīcijas super duper awesome komandā pie ļoti interesantiem pašu produktiem: Python & NodeJS Developer Full Stack Web Developer (PHP Symfony 2/3 + web) Prasības bez jau obvious ir 3+ gadi pieredze abām un angļu valoda full working pro-efficiency. Darbs ES uz vietas - no remote. Interesenti var saņemt detaļas PM.

.NET core ir multiplatforma un open source, hostē kur gribi. Es pats uz doto brīdi pētu kas un kā tagad ir ar to Core, bet pirmie iespaidi ir labi.

Laravel tagad arī ASPā darbojas? Jefiņš.

:D

Un /lv arī match? :>

Jā. Pieejami šādi ģeneratori standartā (shitload more dažādos bundļos): generate:controller generate:bundle doctrine:generate:crud doctrine:generate:form doctrine:generate:entity doctrine:generate:entities doctrine:migrations:generate Orly? Tik vienkārši? Atver pūlrequestu. :D A kurā brīdī tev parādas "//" kuru tu tagad aizstāj un kas tas param_str tāds - matched, route pirms būvēšanas? Piemēra rūtera regex konkrētajai locale problēmai: #^/(?P<_locale>en|ru|lv)/?$#s Indulge me.

Nedzen zosis. Visi ar visu tiek galā.

Vienkāršāks par manu? Un trailing slash nav normāla lieta, ja vien tu neattēlo direktorijas indeksu. Muppet.

Bļooda, elementārais overengineered salabotājs, tas nebiji tu kas iepriekš gatavojās uzbrukt tik triviālai lietai ar bazuku koda? :D Quo vadis, Jurčik? Atrada problēmu bļ, trailing slešā... Ņemot vērā cik līdz stulbumam fleksibls ir Symfony rūteris, es domāju ka tavs arguments ir fail either way, pat ņemot vērā ka šeit funkcionalitāte varētu būt ne visai paredzama tiem kas vēl ar FW neprot apieties. Tajā pašā laikā, man prieks ka tā. Daudz mazāk to, kam vispār nevajadzētu gramstīties gar kodu ir Symfony komūnā...

Okay, un tad route ir "//" vai "/lv/". Now what. Kā jau teicu, edge keiss. Varētu jau būt, ka var sapatchot, bet...

Nē, nepieņem. > @Route("/test/", name="homepage") > curl -I localhost:8000/test/ HTTP/1.1 200 OK > curl -I localhost:8000/test HTTP/1.1 301 Moved Permanently Location: http://localhost:8000/test/ Vienkārši bez parametra rūteris var uzminēt, ka tev tur ir slash, bet ja tur ir parametrs, rūteris īsti nesaprot ko ar to darīt. Šis edge keiss ir zināms, bet jams ir tik "edge", ka neko viņa sakarā neviens negrib darīt jo risinājums būtu bloated routing tables vai fastroute pa virsu vēl 10 regeksi.

Nu tas, ka tu 8 gadu laikā neesi spējis iebraukt kā darbojas viena freimworka konfigurācija nenorāda uz overengineering, tas norāda, ka tev nav lemts. Vispār. Neko. Nekad. Symfony YML configi sastāv no 3 "konceptiem": parametri, servisi, routes. Visbiežāk lietotās lietas ir tik nenormāli tupi elementāras, ka šekspīru rakstošie mērkaķi validus servisu konteinerus gan jau ir kādas reizes 5 sarakstījuši. Tas, ka es ielinkoju vienu konkrētu piemēru, ko ātrumā varēju atrast? Te ir jautājums nevis pašiem programmētājiem, bet tizlenim kas iekļāva šo funkciju publiskā API, jo kurš ir tizlāks - core devs exposēt bezjēdzīgu publisku API vai users, kas jamo lieto īpaši neiedziļinoties iekšās? Izčeko VCS, palasi changelogs (kur tādi vispār ir), palasi komit logus. Vai man tev atreferēt visu to figņu tagad? Cašiera fantoms - es zinu kam fantoms vajadzīgs, tvaju *****. Tikai nesaprotu, kāda velna pēc uz Unix boksiem, piemēram, velkas windows fantoma binaries...? Un tā pat izvāca ārā ar nu kuru te versiju, neatceros vairs. To, ka man personīgi nācās vēl uzbrēkt Otvelam par to, ka Fantoma licensi vajadzētu ievērot es nemaz nekomentēšu... Pēdējais paragrāfs - es nesaprotu ko tu tur runā. Lasu, kaut kādi vārdi, bet loģikas nekādas. Moš izlasi vēlreiz ko es iepriekš uzrakstīju un šoreiz iedziļinies, a?

Man domāt FW vajag konteineri or kko tamlīdzīgu, konfigurācijas menedžmentu, common cache, veidu kā organizēt requests/responses un veidu kā 1-3 sekundēs piekabināt projektam vajadzīgos moduļus. Viss. Un tad tu vari izvēlēties, šito queue, to ORM, šito IMAP klientu, to adapteri, šito librariju. Savādāk sanāk milzīgs blobs ar visu iespējamo figņu ko kādam jebkad varētu vajadzēt. Un kā tu izvēlies ko tur īsti iekļaut tad? Kādam RabitMQ, kādam ASQS, kādam iron.io, vēl kādam phive-queue. Now which one? Man tīk Doktrīne, kādam tīk Propels, vēl kādam tīk idiorms/paris. Tad vēl atnāk kāds un pasaka, man lūdzu Handlebars. Tiesa, ir lietas kas arī symfony ir standarta distribucijā, bet, jamas var nokabināt viena faila ietvaros. Tiem fw kam ir dziļas integrācijas ar kaut kādiem noteiktiem instrumentiem, oioi.

Es zinu, ka .gitignore jo tas ir defaultais mehanisms. So? Par to otro daļu, piedod bet... > cat app/config/routing.yml app: resource: "@AppBundle/Controller/" type: annotation >cat src/AppBundle/Controller/DefaultController.php <?php namespace AppBundle\Controller; use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route; use Symfony\Bundle\FrameworkBundle\Controller\Controller; use Symfony\Component\HttpFoundation\Request; use Symfony\Component\HttpFoundation\Response; class DefaultController extends Controller { /** * @Route("/{_locale}", name="homepage", defaults={"_locale"="lv"}, requirements={"_locale"="en|ru|lv"}) */ public function indexAction(Request $request) { return new Response($request->getLocale()); } } > bin/console server:start [OK] Web server listening on http://127.0.0.1:8000 >curl http://localhost:8000 lv >curl http://localhost:8000/en en Ja nu tev tik ļoti kāro to trailing slashu arī (nez kādu iemeslu dēļ): @Route("/{_locale}{slash}", name="homepage", defaults={"_locale"="lv", "slash"="/"}, requirements={"_locale"="en|ru|lv", "slash"="[/]{0,1}"})

Normālā gadījumā visi faili no konfiga ir versiju kontrolē kaut kādā formā, dev un test parasti satur "sensible defaults" ko minēja daGrevis, lai arī tā pat faili atrodas VC, jo freima izpratnē konkrētajā env citi config izņemot tos, kas paredzēti dotajai env un tie, kurus dotās env konfigs ielādē, neeksistē. Var jau arī būt _dev.yml kas vienkārši ielādē _prod.yml. Prodā tomēr ir nedaudz savādāk, visbiežāk viens no šiem 3 variantiem: Un vēl viena nianse. config.yml ir paredzēts konfigurācijai kā servisi un servisu linkošana, kā arī konfigurē kādi parametri kur kādam servisam padodami. parameters.yml pamatā satur 1 līdz N dimensionālu masīvu ar skalārām vērtībām, kas ir konfigurācijas mainīgie - DB hosti, paroles, keyi, utt utjp. Labā prakse ir nebāzt abus kopā.

Ar flagiem un konfigurācijas failiem. Realitātē, izskatās apmēram tā: > config.yml >> config_dev.yml >> config_test.yml >> config_prod.yml > parameters.yml >> parameters_dev.yml >> parameters_test.yml >> parameters_prod.yml Būtībā, visi {config|parameters}_{dev|test|prod} faili "extends" no {config|parameters}.yml. Var definēt kādas un cik vien vēlies vides. Reizēm piemēram _test extends no _dev, kas extends no _prod utt utjp. Konfigurācijām no environment variabļiem ir iespēja injicēt konteinerī parametrus ar prefiksiem. Tavi keji vispirms tiktu definēti parameters_prod.yml (produkcijai), pēc tam _prod tiktu iekļauts _dev un tur vari definēt dev keys.

Sorry es parpratu. Es domāju tu saki kāpēc konfigu likt bundļos ne app/config :D My bad.

PHP anotācijas kā tādas vispār neeksistē, vismaz pagaidām ne. Konkrētajā gadījumā anotācijas tiek izmantotas nevis kā Javā vai C# runtime flagiem utml. lietām, bet gan konfigurācijai. Un likt konfigurāciju anotācijās ir tik pat okei, kā konfigurāciju hardkodēt. You see where I'm going with this. By default tas ir tāpēc, ka by default cilvēki taisa food blogus. Bundļa ģeneratorā ir iespējams pateikt izveidot bundli ar yml konfigurāciju. Un tie defaulti rūterī strādā out of the box. Nav nekādu cache gļuku. Līkas ķepiņas varētu būt pie vainas šoreiz. Piedod. A kāpēc kodu izmētāt pa visu appu ja var smuki salikt vienā failā un nosaukt par index.php? :) Katram bundlim ir viena konkrēta vieta kur definēt servisus, parametrus utml lietas, un darīts tas tiek sekojošu iemeslu dēļ: Izolācija - gribi pēkšņi aplikācijas bundli dalīt starp vairākām aplikācijām? No problem. Happens often enough. Tu vienmēr zini kur kas atrodas. Ja tev vajag konfigurēt kaut ko saistībā ar FoodBlog, tad konfigurācija ir FoodBlogBundle/Resources/config/[services|parameters|routing|...].yml nevis app/config/services.yml rindiņā 15,223. Aplikācijas konfigurācijai ir precedence pār bundļu konfigurāciju. Tas nozīmē, ka jebkuru servisu vai parametru var pārrakstīt aplikācijas konfigā mutējot konteineri, piemēram, aizstājot kādu vendora servisu ar savu kas implementē tos pašus interfeisus. Nav labākais piemērs, bet good enough. Iepriekšējais nozīmē arī to, ka atkarībā no vides aplikācijas konfigurācija var pārrakstīt kaut kādas bundļu funkcijas un flagus (piemēram, nesūti emailus CI vidē, izmanto citu DB backendu utt) + pretty much visi argumenti no sērijas par izolāciju, lietu kārtību universā... Bundļi arī savukārt ir vai nu "true bundle" vai "app bundle" - true bundle ir domāts kā pilnībā no aplikācijas izolēts library kuru vēlāk izmanto aplikācija vai citi bundļi (un tikai caur publisko API), app bundles sabukārt veido vienkārši lai palīdzētu organizēt funkcionalitāti pa mapītēm kaut kādās loģiskās grupās... True bundle gadījumā konfigurācija nemaz nevar būt aplikācijas līmenī, savukārt app bundle to var darīt, bet tā pat, visi iepriekšējie argumenti ir diezgan validi arī šeit.

Kāpēc tev vajag 2 dažādas routes, vienu ar un vienu bez prefiksa? home: path: /{_locale} defaults: { _controller: AppBundle:Default:index, _locale: lv } requirements: _locale: en|lv|fr / => lv /lv => lv /fr => fr /en => en Tavai otrai problēmai - routing.yml var uzlikt prefiksu visām routēm kas atrodas dotajā bundle. Piemēram, normalā gadījumā viss tavs aplikācijas kods atrodas AppBundle un varbūt vēl pārītī custom bundles. Katra bundle routes ir definētas katrā bundle, savukārt app/config/routing.yml tu liec tikai kodu kas ielādē šo bundļu routing.yml failus (skat. zemāk). Un for god sake, neizmanto anotācijas. YML un tikai YML konfigurācijas bundļos. Symfony tā pat konfigu lasa tikai vienreiz un kešo produkcijā. some_bundle: resource: "@SomeBundle/Resources/config/routing.yml" prefix: {_locale} requirements: _locale: lv|en|fr

Da kaut vai.

A kada velna pēc būtu jāmeklē 2 cilvēki kas kaut ko migrē velns zina kāpēc ja tajā pašā laikā tie 2 cilvēki var darīt kaut ko produktīvu, piemēram taisīt jaunas funkcijas?! Tam ir ļoti liels sakars, ja ir continuous integration un rolling release, kur vendori tiek updeitoti pie katra rolling release un api izmaiņu paredzamība ir ārkārtīgi svarīga lai laiku api izmaiņu ieviešanai varētu plānot iepriekš. Tas gan ir kaķim zem astes, ja netiek ievērots dajebkāds paredzems princips, kā vendori ievieš izmaiņas - piemēram, ja pēkšņi no zila gaisa pazūd kāda publiska api funkcija minor updeita laikā, tavs feature release plans aiziet kaut kur nebūtībā, jo tev pēkšņi ir jāpārraksta N kods, kas var bloķēt un bloķē citus uzdevumus, ko reāli var izteikt zaudētos eirikos un darba stundās. Un ja tev ir vairāki neatkarīgi projekti uz viena un tā paša freima un ar tiem pašiem vendoriem, zaudējumi reizinās ar projektu skaitu. Tad pasaki man, kāda velna pēc tas būtu jāpacieš ja eksistē lieliskas alternatīvas kur kaut kas tāds nenotiek? Versionēšana un ar to saistītas lietas eksistē tieši šo iemeslu dēļ - lai būtu iespējams paredzēt un plānot izmaiņas. Ja vienīgais princips ir "kad ienāk prātā", tad neko plānot nevar. Un kāds sakars pašveidotiem freimiem ar topiku es galīgi nesaprotu.

Kāds sakars ar ņaudēšanu? Ja tev ir 100+ cilvēki kas suportē N projektus robežās no 30m līdz ar 5 miljardiem pieprasījumu dienā un katru dienu ir deploymenti produkcijā mērāmi desmitos, tu gribi teikt ka šādas nelielas nianses nav svarīgas? Neviens jau nesaka ka tu nevari uz Laraveļa taisīt kaut kādu ceļojumu blogu, kas tiks nomests uz 9.99 eur hostinga un aizmirsts pēc gada. Bet kaut kam, ko veido ilgtermiņā sev vai kādam citam gan varētu nebūt īstā izvēle.

HTML Programmētāju?... HTML... PROGRAMMĒTĀJU?...