F3llony

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

Pierādi, un tad mētājies ar apgalvojumiem. Neredzu atšķirību starp atmiņas patēriņu CSV datiem, kas uz klienta, vai servera konvertēti un attēlojas klienta pusē.

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.

Kapēc lapu taisīšanai vajag ASP.NET? Jāhostē būs uz MS servera, kas nav lēti.

 

Ieteiktu izmantot Laravel, vai Yii.

 

Galvenais ir būvēt no moduļiem, jo pasūtījumi mēdz būt līdzīgi un tā ieekonomēsi laiku. Ar composeri savāc vajadzīgos moduļus, sakonfigurē, papildini nepieciešamības gadījumā ar jaunām fīčām un aiziet.

.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. 

Ieteiktu apskatīt Laravel un papildus tam vue.js 

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

prasa augstāko, bet sludinājums ss.lv un sistēma uz codeigniter

:D

#^/((?P<_locale>en|ru|lv)/)?$#s

Un /lv arī match? :>

Tepat blakus ir cits topiks par "ģeneratoriem" iekš Laravel. Kāds tādus lieto? Symphony tādi ir?

https://php.lv/f/topic/22402-laravel-%C4%A3ener%C4%81tori/#entry179310

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

trim(preg_replace('/\/{2,}/','/',$param_str), '/')

such fix, much code, very php, wow

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.

tā sabiedējāt, ka ar ar routēm netiek galā, paldies nē.

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ā... 

Ko tur nevar saprast, ko darīt? Ja tur ir tukšums, tad uztver to kā tukšumu.

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

@F3llony - interesanti. Jo, piemēram, @Route('/foo/') pieņem gan /foo, gan /foo/. Tad kāpēc, ja ir parametrs, nav tāpat?

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

@Route("/{_locale}{slash}", name="homepage", defaults={"_locale"="lv", "slash"="/"}, requirements={"_locale"="en|ru|lv", "slash"="[/]{0,1}"})

Tie config faili atrodas versiju kontrolē?

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:

1. parameters_prod.yml.dist ar "sensible defaults" un bez, piemēram, DB konekciju info atrodas VC un parameters.yml ir gitignorē. Produkcijā parameters.yml atrodas kaut kur failu sistēmā, pie deployment simlinko uz /app/config. Devā ielinko un aizpilda manuāli, vai ielinko ar composer tasku/git hūku, vai arī izmanto https://github.com/Incenteev/ParameterHandler. Šādā veidā tev ir gan atskaites punkts VC un nedaudz privātuma. Mīnuss šeit ir turēt gan .dist gan produkciju "on the same page", lai gan tam lieliski der konfiga menedžeri utml tūļi.

 

2. parameters.yml ir VC vienmēr. Parametru vērtības tiek saņemtas no ENV. ENV menedžē ar tūli (puppet, cap, ansible, whatever). Mans personiskais favorite.

 

3. parameters.yml ir VC ar visām parolēm. Dens Kaminskis berzē rokas.

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ā.

Ka symfony menedžē environment konfigurāciju? Teiksim, dev`am vajag braintree sandbox key'us.

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. 

> 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.

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.

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

Symfony?

Da kaut vai.

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.

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?...