Laravel: molio bih malo objašnjenje (get(), get('key') )

Nisam još. Dok neću biti u stanju napisati sam (bez pomoći guglanja) web sa login+pretraživanje (search) sa prikazom prvih 5 rezultata u padajućoj listi ispod input forme (uz jQuery), neću niti pokušavati. Savladao sam (Laravel) osnove Eloquenta, blade-a, korištenje artisana. U radu ću još proširiti znanje s objektima. Računam (kako je @tpojka napisao u drugom postu da mi treba vremena) da ću oko prosinca/siječnja biti dovoljno siguran za apliciranje gdje se traži i Laravel (u korištenju od min godine dana). Ne bih još slao cv dok ne skupim barem nešto prakse s Laravelom. (da, još i Git i Composer, ali to ide paralelno s ovime što radim).

Eto, tu se “lome koplja” :slight_smile:
Trenutno tako i radim, ali ima smisla i ovo što @bozoou kaže.

@tpojka,

A zašto nisi onda i kreiranje rezultata kreirao kroz jednu dodatnu metodu, mislim na ovu liniju:

$resultFromVarsMakeover = $neededVar1 + $neededVar2;

Po čemu ti je ta linija drugačija od ove dvije koje si vukao kroz zasebne metode?

U primjeru ti se malo toga vidi jer nisi poštivao da nazoveš metode razumljivim imenom.
Da si nazvao metodu privateMethodThatReturnsVar1() npr: gets_DB_table_count()
A metodu privateMethodThatReturnsVar2() npr: gets_api_items_count(), kod bi već bio čitljiviji i razumljiviji na djelovima gdje se te metode pozivaju. No otkrilo bi se još nešto. Otkirlo bi se upravo iz naziva jel to nešto što zaslužuje biti zasebna metoda ili ne.
U ovom tvom slučaju je sasvim očekivano da bi te metode klasi mogle trebale još negdje…pa je i sasvim pošteno da se nalaze unutar zasebnih metoda.
No što je sa linijom:

$resultFromVarsMakeover = $neededVar1 + $neededVar2;

Da je i to nazvano kvalitetnim imenom, već bi bilo jasnije da li je to neka generalna metoda (matematička kalkulacija) koja računa neku statistiku/odnos iz “db_table_count” i “api_item_count”, ako bi bila, onda je sasvim zasluženo da se i ta kalkulacija premjesti u svoju metodu…bilo ili ne to privatna metoda ove klase. Jer može kalkulacija biti i općenitija…koja se tiče različitih entiteta koji posjeduju table_count i api_count.
Nek dođe do promjene te naoko jednostavne matematičke kalkulacije, ako se ista koristi na više mjesta…onaj koji održava kod morao bi moći nadograditi matematičku kalkulaciju isključivo na jednom jedinom mjestu u kodu. I to je DRY.

Hoću reći, ti si u startu napisao:

I onda nisi ništa napisao o tom smislu…zašto bi bilo nešto smisleno, a zašto ne.
Ja tvrdim da kerefeke o broju linija i preglednosti su samo nuspojava DRY pristupa…a DRY je poanta priče. Netko tko nebi uočio da mora postojati DRY, mogao bi intuitivno cjepati metode (videći druge) na odokativni broj linija…ali to nebi značilo da zaista i ima lako održiv kod.

I ne kažem ja da će igdje štetiti nešto presjeći radi preglednosti…ali govoriti o cjepanju, a ne objasniti nekome DRY princip, kao jedan od jako bitnih razloga …je po meni totalno promašeno.

Da se nebi netko uplašio goglati DRY, bojeći se pregršt tone informacija da ga čeka iza tog pojma…stvar je zapravo na prvu jako jako jednostavna:

Dont Repeat Yourself

Kada god se ima potreba neki dio koda duplicirati na nekom mjestu…koliko god taj dio koda bio kratak, poželjno ga je nekako separirati (recimo u metodu) …i koristiti kroz tu metodu.

Tako da buduće svake promjene na tom djeliću koda se mogu napraviti na tom jednom jedinstvenom mjestu. Unutar metode.

No stvar nije tako jednostavna, jer DRY imamo npr. i u CSS (tu nam pomaže LESS/SASS) da bi kod bio DRY ispravan. No DRY imamo puno dalje i od toga…i upravo da zajednica pokuša održati DRY pristup na svim razinama, često programski jezici i alati evoluiraju.

Ok, navuk’o si me da napišem kako bi to ustvari trebalo izgledati.

<?php
/**
 * Created by PhpStorm.
 * User: tpojka
 * Date: 01/10/2018
 * Time: 18:55
 */

use Some\DbRepository;
use Some\ApiRepository;

class SomeClass extends SomeBaseClass
{
    /**
     * @var object DbRepository
     */
    private $dbRepository;

    /**
     * @var object ApiRepository
     */
    private $apiRepository;

    public function __construct(DbRepository $dbRepository, ApiRepository $apiRepository)
    {
        $this->dbRepository = $dbRepository;
        $this->apiRepository = $apiRepository;
    }

    /**
     * Adds db rows count and api items count and returns that result
     * @return int
     * @throws Exception
     */    
    public function countDbAndApi(): int
    {
        try {
            $dbCount = $this->dbRepository->getCount();
            $apiCount = $this->apiRepository->getCount();
        
            return $dbCount + $apiCount ?? 0;
        } catch (\Exception $e) {
            throw $e;
        }
    }
}

Poenta je bila upravo na te dvije linije a ne na ostatku koda. Ostatak koda samo oubličuje kontekst.
Nadam se da sad izgleda smisleno i sa nazivima varijabli i sa tim što nešto u neki metod. :slight_smile:
Ova klasa bi trebalo da ima dependency injected interface koji koristi ove klase za inicijalizaciju objekta externog servisa (Db, Api, etc…)
Kako var1 i var2 nemaju dodirne tačke osim return type-a shodno tome idu u posebne metode (u primjeru ovog posta i u nezavisne repozitorijume).
Zanima nas ovaj metod koji računa te dvije vrijednosti. Da li treba ići u poseban metod sabiranje dvije cifre je za posebnu diskusiju (lično smatram da je to u domenu mikrooptimizacije).

Ima još jedna stvar u Laravel-u koje bi se trebalo pridržavati.
Mislim da nije hitno ali je bitno.
Držati se striktno naziva fajlova, klasa i metoda (pa i varijabli) kako je opisano u dokumentaciji i ukapirati na koji način su formirana ta imena.
Dosta može pomoći i neki video ili cijeli serijal od Jeffrey Way-a na laracasts sajtu jer je jedan od onih koji su najviše uradili na izgradnji frameworka pa mu sve to ide lagano. Tj. lako je primiti konvenciju naziva kroz njegove video serijale.
Ima se smisla držati toga k’o pijan plota jer je dosta stvari vezano u fw-u a pogotovo u Eloquent-u tako da u konačnici olakšava rad.
Recimo SingularController (PascalCase naziv za controller, jednina), Plurals (naziv za model, engleska množina), camelCase() i $camelCase (za naziv metoda i varijabli).
Recimo sa default komandom u terminalu php artisan make:model House -mrc će biti kreirani
House (model), HouseController (resource controller) i migration fajl za houses tabelu (model u množini) po tom uskladjenom standardu. Ovo će raditi i za nepravilne engleske riječi tako da ako se kreira
php artisan make:model Knife -m dobiće se Knife.php za model i migracijski fajl za tabelu knives.
I tako kreirani fajlovi onda ne zahtijevaju dodatna podešavanja kao što su recimo ime tabele u modelu. Isto se odnosi i na polja u tabeli: svaka (bez izuzetka) tabela mi ima id polje. Čak i pivot tabele. Jer ako u jednom momentu odlucčim napraviti model za tu pivot tabelu, sve će mi već biti spremno bez glavobolja za mijenjanje imena, postavljanje custom key-eva u relacione metode etc. A i osnovna indexing pretraga uradjena odvojeno na takvoj tabeli će raditi zavidnom brzinom. Ono što hoću da kažem da se treba slijepo držati standarda i konvencije bilo koje domene, bio to jezik, bio framework bila biblioteka/repozitorijum. A ono bar u maksimalnoj mjeri jer jako puno olakšava rad kasnije.

Ovo mi je bilo pobjeglo :smile:

1 Like

Oh, pa to naučih u prvoj lekciji rada s Laravelom :slight_smile:
Paziti na plural i singular u nazivima modela i klasa. A o nazivima klasa i metoda mislim da se nalaze u PSR-1 koje si poslao (pa to koristim i u Laravelu a bogme i u JS odnedavno - gdje sam prije pisao funkcije kako mi se sprdnulo jer to nitko nije dirao osim mene :slight_smile: ).

Pretplati se na mejlove sa laravel/laravel github repozitorijuma i ili sa laravel taga na stackoverflow-u.
U realnom vremenu ćeš biti svjedok unapredjenja i/ili problema koji te (ne) moraju kačiti.

Github:


i ovde

StackOverflow:

Meni je dosta pomoglo, uopšteno govoreći.

1 Like

Mnogo dobro :smiley: :smiley: …velim ja, ideje su u cloudu.
Inače, ja sam jedan kompletni specifičan scenarij pričao mojoj curi kakva bi nas budućnost mogla čekati…i onda je takva epizoda bila prikazana u seriji Black Mirror.

Bilo je epic gledati svoje misli režisirane.
Inače, to je ona epizoda kada mi ljudi s strojevima upsijemo replicirati osobnost preminulih osoba, te ih pustimo u “život” opet.

Može zvučati smiješno, ali razgovor sa osobom na skypeu, je razgovor sa strojem koji samo jako dobro replicira što neka osoba negdje radi. U budućnosti će ta replikacija doći na malo luđi level :smiley:

:grinning:

@bozoou
Bilo je nekol’ko sličnih epizoda.
Jedna je kad žena preko “Amazona” naruči preminulog muža, jedna je bila kad love “mutante” a ustvari love ostatke civilizacije i treća kad postoji virtualni zagrobni život. Koja od tih?

Da, cijela serija zapravo naginje u tom smjeru da nam dočara mogućnost realnosti “virtualnog” svjeta …(mada su moje ideje kod mene prije nego što uopće znam za seriju :D, tako da nisu njom inicirane…)

…konkretno se radilo o epizodi kada naruči preminulog muža!

Serija je woooohu ledeni šamar potencijalne realnosti!! Bar meni.

Da popunim popis i prisjetim se malo :slight_smile:
Bilo je odlično i ono kada je onaj crayz haker otimao ljudski karakter kroz slinu ili nešto…te ih replicirao u vlastitoj igrici…gdje je sebi zadao nadljuske moći, a otete karaktere koristio kao sredstvo iživljavanja.

Zatim, ono kada veliki stupanj AI-a proživi milijune godina testirajući razne kombinacije kompatibilnosti partnera …da bi taj prikazani “real life” bio zapravo samo matematički model koji se izvrti unutar djelića sekunde…za uber napredni “tinder”, tj. web site za pronalazak idealnog partnera.

Meni serija vrh :smiley: (Iako sam nakon treće epizode skoro prestao gledati…i napravio pauzu možda i godinu dana. Tako da me se prve tri nisu nešto ekstra dojmile, iako ne mislim da su loše. Samo one kasnije su čisto prosvjetljenje, heh…iako većini vjerujem samo SF xd)

A čak i ono u jednoj epizodi od te prve tri je super…kada otmičari naprave ucjenu…tako da traže da političar javno hebe svinju…ne bumo se dugo iznenadili da i takvo nešto vidimo, kada građani počmu smišljati nove načine respresije odgovornih osoba.

Dečki, pobogu, pa kaj vi to gledate?! :smiley:

Inače mrzim serije koje se nastavljaju…koliko god bile dobre, to je meni sve gadljivo u rangu sapunica…čiste psihološke navlakuše…

Ovaj Black Mirror, svaka je za sebe…i što se mene tiče, svaka ima odličnu poruku. Šteta ne pogledati.

Možda i nisam relevantan, jer inače nemam TV i generalno ne gledam filmove niti serije. Ponekad probam…ali imam jake filtere…

USS Callister. Prva četvrte sezone. Kad utripuje da je kapetan Enterprise-a.
Sad kad pregledam listu, svaka je dobra na poseban način.

Black Mirror. Odlična, ali nemoj pred klincima (moralno je diskutabilna, k’o što se vidi iznad :slight_smile: ). Jako dobro je ocijenjena, isto. Nudi se na Netflix-u a vjerujem da ima i na trafici™ da se kupi. :wink:

3 Likeova

Svakakve pixdarije čovjek dozna na forumu :smiley:
(Idem potražit)

U vezi Laravel-a još jedna stvar (ne znam je li već pomenuta):
pogledaj njihov Slack kanal. Iz dva razloga, kud ima masa ljudi koji će biti spremni pomoći, možda i bitnije da vidiš i da se upoznaš sa Slack interface-om koji jer je Slack nezaobilazan kanal komunikacije kod bilo koga ko ozbiljnije shvata timsko programiranje (ako poslodavac ne komunicira u vezi projekta putem Slack-a, traži boljeg; skoro pa da je tako). Ako si već koristio Slack, onda ništa. :smiley:

1 Like

Evo upravo poslao prvi CV, jučer me jedan kontaktirao da pošaljem. Amsterdam.

EDIT: ne traže Laravel

1 Like

Otvorio račun, prozujao - izvrsno, to će pomoć. Na stackoverflow otvorio račun i pretplatio se kako si objasnio (na tagove i kategoriju) :slight_smile:

Jbg, meni su trebale godine da determinišem šta valja a šta ne valja tj, šta se može preskakati kad uzmemo u obzir neoficijalne stvari. Što da se ne pomogne nekom da to predje (i šta valja i šta ne valja) mjereći mjesecima. Sjećam se da sam nekad dok sam pretraživ’o CodeIgniter video klipove (srazmjerne tada tekućem znanju) bio zadovoljan jednim tajlandskim serijalom (dok sam neke engleske preskak’o). :grinning:

1 Like