daskilla Posted January 31, 2016 Report Share Posted January 31, 2016 Un tad vēl ir tādi brīnumi kā šis epic. Because fuck you and fuck your API stability. :D Un tādu ir vēl - tur visādi dīvaini versiju bumpi, pēkšņi kaut kur pazūd vai mainās publiskas API daļas, kaut kādas klases pēkšņi pārvācas velns zina kur etc. Nemigrēsim projektus no 5.1 tālāk šī iemesla dēļ, https://laravel.com/docs/5.2/upgrade#upgrade-5.2.0 Upgrade guide ir mazs referāts priekš MINOR versijas maiņas. 5.4 (ja tāds būs) noteikti API ziņā nebūs pat līdzīgs 5.1. Quote Link to comment Share on other sites More sharing options...
Kasspars Posted January 31, 2016 Report Share Posted January 31, 2016 Droši nelietojat Laravel. Būs mazāk ņaudētāju :) Quote Link to comment Share on other sites More sharing options...
F3llony Posted January 31, 2016 Report Share Posted January 31, 2016 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. Quote Link to comment Share on other sites More sharing options...
Kasspars Posted January 31, 2016 Report Share Posted January 31, 2016 Ja tev ir 100+ cilvēku komandā, tad nebūs grūti atrast 2 cilvēkus, kad nomigrēs uz jaunāko L versiju 30m vai 5 miljardiem, kā arī vairākiem desmitiem deployment dienā nav nekāda sakara ar migrēšanu uz jaunāku L versiju. Tu tos ciparus pieliki, tikai lai izskatītos "svarīgāks" Varu derēt, ja tev būs paša veidots un uzturēts framework, tajā būtu 10tiem funkciju, kuras dara vienu uz to pašu. Quote Link to comment Share on other sites More sharing options...
F3llony Posted February 1, 2016 Report Share Posted February 1, 2016 Ja tev ir 100+ cilvēku komandā, tad nebūs grūti atrast 2 cilvēkus, kad nomigrēs uz jaunāko L versiju 30m vai 5 miljardiem, kā arī vairākiem desmitiem deployment dienā nav nekāda sakara ar migrēšanu uz jaunāku L versiju. Tu tos ciparus pieliki, tikai lai izskatītos "svarīgāks" Varu derēt, ja tev būs paša veidots un uzturēts framework, tajā būtu 10tiem funkciju, kuras dara vienu uz to pašu. 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. Quote Link to comment Share on other sites More sharing options...
Blitz Posted February 2, 2016 Report Share Posted February 2, 2016 Tad pasaki man, kāda velna pēc tas būtu jāpacieš ja eksistē lieliskas alternatīvas kur kaut kas tāds nenotiek? Symfony? Quote Link to comment Share on other sites More sharing options...
F3llony Posted February 2, 2016 Report Share Posted February 2, 2016 Symfony? Da kaut vai. Quote Link to comment Share on other sites More sharing options...
jurchiks Posted February 2, 2016 Report Share Posted February 2, 2016 Nez, pēdējo nedēļu ar kapeikām esmu bik pastrādājis ar Symfony, un jau esmu saskāries ar vairākām problēmām, kuras salabot prasa daudz par daudz koda. Piemēram, viselementārākā štelle - optional _locale prefix visiem URL - tāds gemorojs. Symfony v2 it kā šo esot bijis iespējams uztaisīt ar 2 route prefixiem, vienu /, otru - /{_locale}, bet symfony 3 tā vairs nevar, jo tur rūteris glabā routes masīvā, kur key = Route name. Attiecīgi tā, kā routes, lai arī ielādētas caur diviem prefixiem, tomēr ir ar vienādu nosaukumu, tad _locale-prefixed routes aizvieto bez-prefixa routes (vai arī otrādāk, atkarībā no tā, kādā secībā routing configā definēti prefixi). Workaroundu par glītu kodu nosaukt nevar - ciklē cauri visiem routes, klonē katru route, pieliec _locale prefixu un nosaukumam postfixu _lang, tad pievieno tam pašam rūterim. Rezultātā ir my_route = /, my_route_lang = /{_locale}. Attiecīgi, lai varētu uzģenerēt linku uz šiem routes, vajadzīgs papildus kods. Labāks risinājums būtu uztaisīt kaut kādu @LocalizedRoute anotāciju ar pārsvarā identiskiem parametriem, izņemot _locale default un requirements definēti kaut kur konfigā, lai nav katrā anotācijā jākopē viens un tas pats. Quote Link to comment Share on other sites More sharing options...
F3llony Posted February 2, 2016 Report Share Posted February 2, 2016 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 Quote Link to comment Share on other sites More sharing options...
jurchiks Posted February 2, 2016 Report Share Posted February 2, 2016 (edited) A vot nestrādā tas defaults, mēģināju. Varbūt vēlreiz pamēģināšu, moš kārtējais cache gļuks, bet nu hz. Nu, PHP anotācijas nav tas pats, kas Java anotācijas, bet tā, kā ar Java anotācijām esmu pazīstams un Symfony 3 defaultā uzliktas anotācijas, tad tās arī izmantoju. Ērtāk tomēr. Edited February 2, 2016 by jurchiks Quote Link to comment Share on other sites More sharing options...
daGrevis Posted February 3, 2016 Report Share Posted February 3, 2016 Kāpēc izmētāt konfigurāciju pa visu appu ja var to smuki salikt vienā vietā? Quote Link to comment Share on other sites More sharing options...
F3llony Posted February 3, 2016 Report Share Posted February 3, 2016 A vot nestrādā tas defaults, mēģināju. Varbūt vēlreiz pamēģināšu, moš kārtējais cache gļuks, bet nu hz. Nu, PHP anotācijas nav tas pats, kas Java anotācijas, bet tā, kā ar Java anotācijām esmu pazīstams un Symfony 3 defaultā uzliktas anotācijas, tad tās arī izmantoju. Ērtāk tomēr. 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. Kāpēc izmētāt konfigurāciju pa visu appu ja var to smuki salikt vienā vietā? 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. Quote Link to comment Share on other sites More sharing options...
daGrevis Posted February 3, 2016 Report Share Posted February 3, 2016 > A kāpēc kodu izmētāt pa visu appu ja var smuki salikt vienā failā un nosaukt par index.php? :) Ko? > Katram bundlim ir viena konkrēta vieta kur definēt servisus, parametrus utml lietas To es arī iesaku darīt. Nevis “bundlim“ pie katra kontrolera (?) ir kkāda anotācija (?) kas pasaka ar kuru URL šis te ir atverams. Quote Link to comment Share on other sites More sharing options...
F3llony Posted February 3, 2016 Report Share Posted February 3, 2016 > A kāpēc kodu izmētāt pa visu appu ja var smuki salikt vienā failā un nosaukt par index.php? :) Ko? > Katram bundlim ir viena konkrēta vieta kur definēt servisus, parametrus utml lietas To es arī iesaku darīt. Nevis “bundlim“ pie katra kontrolera (?) ir kkāda anotācija (?) kas pasaka ar kuru URL šis te ir atverams. Sorry es parpratu. Es domāju tu saki kāpēc konfigu likt bundļos ne app/config :D My bad. Quote Link to comment Share on other sites More sharing options...
briedis Posted February 3, 2016 Report Share Posted February 3, 2016 Ka symfony menedžē environment konfigurāciju? Teiksim, dev`am vajag braintree sandbox key'us. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.