tag: php

28Oct

Inversion of layered architecture

Hosszú ideje nem volt már technikai jellegű bejegyzés a blogon, épp itt az ideje kicsit változtatni ezen. A cikket az egyik stackoverflow kérdésre adott válaszom ihlette, ahol megkaptam, hogy a kedvenc UML-emről igazán írhatnék valami cikket, ezt pedig megfogadom :) A legtöbben ismerjük az úgynevezett layered architektúrát, aminek a lényege az, hogy alkalmazásunkat több különböző rétegre bontjuk. Ezek a rétegek egymásra épülnek és a felhasználó, legyen az egy tényleges felhasználó vagy valami egyéb kliens, mindig a tetejével lép kapcsolatba. Na most a dependency inversion elve nem csak osztályokra értelmezhető, hanem ilyen modulokra is. Na de mégis hogyan?

Tovább »

18Feb

Circuit breaker, avagy mi van akkor, ha nem megy?

Amikor szoftvert írunk, akkor törekszünk arra, hogy bolondbiztos legyen. Amikor webre fejlesztünk sem történik ez másként. Minden tőlünk telhetőt megteszünk annak érdekében, hogy bizony a felhasználó mindig megkapja, amit akar, hiszen nekünk közvetve belőlük van pénzünk. Azonban akadnak olyan esetek, mikor külső tényezők is befolyásolhatják a szolgáltatást, amit nyújtunk? Akkor bizony tudni kell esni. Ahogy manapság egyre nő a microservice hype, egyre gyakrabban fogunk találkozni azzal, hogy bizony, ki kell hívni egy külső service felé, ami nem mindig végződik egy boldog 200-as válasszal. Cikkünkben a Circuit breaker patternről lesz szó és arról, hogy is segíthet ez nekünk, ha külső szolgáltatásokra épül az oldalunk.

Tovább »

06Feb

Laravel dockerben

A korábbiakban már láthattuk, hogy is tudunk apache alapú webszervert futtatni, azonban akadnak esetek, főleg ha a Laravel eszközkészletét vesszük figyelembe, mikor egy szimpla webszervernél több kell, vegyük csak a workereket, scheduled jobokat. A docker alapvetően egy process-t (és azokat, amiket az spawnolt) tud futtatni és addig tart egy konténer futása, amíg a process tart, ennélfogva fontos, hogy az úgymond foreground fusson, tehát ne daemonként. Most nézzük meg, hogy is hívhatjuk segítségül a supervisord-t és indítsunk konténert cronnal workerekkel és futó apache-al! 

Tovább »

30Jan

Vissza a jövőbe - Legacy kódok

A mai nap az egyik facebook csoportban felröppent a kérdés, miszerint óhatatlanul is 'gány'-e minden kód, amit öröklünk. Az eddigi cikkekel ellentétben most nem fogunk hirtelen legacy kódot gyártani, tehát nem lesz semmiféle gyakorlati megvalósítás, így aki copy-paste ügyében jött, azt most el kell keserítsem. Akit viszont érdekel egy hosszabb vélemény a legacy kódokról, az a tovább gomb után megtalálja :)

Tovább »

23Jan

SOAP, avagy 'Run you fools!'

Az eddigi cikkekben főleg a RESTful irányába mentünk el, ami mostanában elterjedőben van, viszont óhatatlan, hogy az ember belefusson a jó öreg SOAP-ba. Már volt róla szó, hogy hogy is néz ki mindez, viszont az még nem derült ki, hogy is tudunk ilyet létrehozni, valamint egy kliens se ártana, mert "jó" esetben mi inkább használni fogjuk ezeket, nem pedig szervert írni rá PHP-ben. Mindenesetre mindkét opcióról szót ejtünk majd. Na de zuhanjunk is neki, mert semmi se lesz belőle!

Tovább »

31Dec

PHP Docker mögé bújva

Ígértem korábban a Passportos verzióját a REST API-nk authentikációjához és ennek az első lépése az, hogy 5.3-as Laravel kell hozzá, ahol bele is futottam a hibába, miszerint lokálisan csak 5.6.3-as PHP-m volt, neki pedig 5.6.4-es kellett volna. Persze mi sem egyszerűbb egy lokális környezetnél, updateljük és ennyi. Sajnos production környezetben nem így szokott mindez történni, no meg jó lenne, ha már a 7-est használnánk, így gondoltam mixelem a kellemest a hasznossal és megnézem mennyire bonyolult bepakolni ezeket dockerbe, úgy hogy működjenek is. A példák, habár Laravel alapúak, a legtöbb PHP keretrendszerre igazak lesznek, ahol a Document Root a public mappára mutat.

Tovább »

19Dec

Konstruáljunk web API-t - 2. felvonás

Amikor az ember webről beszél, a legtöbb esetben színes weboldalakat képzel el, ezerféle közösségi platform belépéssel, ahol az ember minden mozzanatát lépésen tudják követni különböző módszerekkel, hogy a leginkább testreszabott élményt kapja. Ha bejelentkezünk egy oldalra, akkor a következő oldalbetöltéskor már az üdvözlő képernyő fogad, azt a hamis érzést keltve, hogy a weboldal tudja, hogy pontosan kik is vagyunk. Ez persze közel sem igaz, csupán a böngészőnk által küldött sütiben szerepel egy session ID, amivel azonosítanak bennünket és ezáltal hozzánk igazíthatják az oldal tartalmát. Ehhez viszont az kell, hogy a böngésző süti ide-oda közlekedjen a kérésekben/válaszokban. Azt már tudjuk régről, hogy a HTTP az egy ún. stateless protokoll, vagyis a két egymást követő lekérés közt nincs semmiféle kapcsolat, állapotváltozás. Ezt hivatott áthidalni az imént említett sütis megoldás. Azonban amikor REST webservicekről beszélünk, ott ez a sütis módszer nincs jelen. A korábbi példákban ez nem is okozott gondot, hiszen még nem volt szó arról, hogy ki mit is csinálhat az adott REST erőforrásokkal. Viszont mi a helyzet akkor, ha bizonyos műveleteket csak adott jogosultság mellett szeretnénk megengedni? Valamilyen formában tudtára kell adjuk a szervernek, hogy mégis kik vagyunk, ami alapján ő vagy végrehajtja az említett műveletet, vagy egy jól irányzott 401-es válasszal finoman elutasít bennünket. Ilyen műveletek lehetnek pl. azok, amikor törölni akarunk egy elemet, hozzá akarunk adni, módosítani, netán valakinek a privát dolgaiba akarunk kutakodni. Cikkünkben belepillantást nyerünk abba, hogy mi is az OAuth2.0 protokoll és hogy segíthet nekünk a fentiekben, third party vagy épp a saját API-nk használatakor.

Tovább »

26Aug

Konstruáljunk Web API-t!

Amikor a legtöbben meghallják azt a rövidítést, hogy API, rendkívül különféle dolgokra asszociálnak. Van akinek a Java Persistence API jut eszébe, van akinek a Facebook API, míg másoknak valami teljesen más...api

Tovább »

16Jul

She wants the DI

A SOLID sorozatunk utolsó része következik, ahol a Dependency Inversion Principle, röviden DIP lesz terítéken. Alkalmazásunk felépítését tekintve többszintű hierarchiát képez. Ha megvizsgáljuk az osztályainkat és azok függőségeit, akkor egy faszerkezetet rajzolnak ki, ahol a fa gyökere felé haladva egyre magasabb és magasabb szintű osztályok következnek. tree-451x320Amikor tervezzük az alkalmazásainkat, a gyakorlat az, hogy először azokkal az alacsonyszintű osztályokkal kezdjük, amik az egyszerű műveleteket végzik, mint a lemezelérés, hálózati protokollok, stb. (Ezek lesznek a levelek) Ezután fogjuk ezek működését egységbe zárni magasabb szintű osztályainkba, ahol a komplex logika található (üzleti folyamatok, stb.). Ahogy a sorrendből is lehet rá következtetni, ez utóbbiak függnek az alacsony szintű osztályoktól. Ebből kifolyólag az előbbi elgondolás, miszerint a low-level osztályoktól a high-levelek felé haladunk a megvalósítás során. A probléma itt a flexibilitás lesz, ugyanis ha az egyik alacsonyszintű osztályt le kell cserélni valahol, akkor meg vagyunk lőve, mert a magasabb szintű osztályainkat ennek implementációjára építettük.

Tovább »

09Jul

ISP - Interface segregation principle

Amikor új applikáció tervezésébe kezdünk, akkor nem árt komolyan fontolóra venni, hogy milyen absztrakciókat is fogunk használni az egyes modulok és submodulok esetén. Ha ezen modulok egyike esetünkben egy osztály, akkor az absztrakció formája nem lesz más, mint egy interface. Tegyük fel, hogy ezt létrehoztuk és az adott osztályt implementáltuk is, minden klappol, megkaptuk érte a kis pénzünket és nem utolsó sorban úgy működik, ahogy a megrendelő elképzelte elképzeltük. refactoring-to-solid-code-32-728

Tovább »

28Apr

Díszítsük fel a wrappert!

A decorator pattern a struktúrális minták közé tartozik, és a célja roppant egyszerű: magába foglal egy másik osztályt és plusz funkcionalitással látja el azt, így az eredeti osztály metódusai érintetlenek maradnak. Nézzük meg hogy is történik mindez!  

Forrás: foodnetwork.com

Forrás: foodnetwork.com

Tovább »

24Mar

Refactoring a javából

Elképesztő módon elmaradtam az írásokkal, amire semmilyen (még az ivás se) lehet mentségemre. Ezért most ha tudom, akkor megpróbálom pótolni, de már inkább nem is ígérek semmit, mert eddig nem úgy tűnt, hogy be tudom tartani :) A kódminőség a fejlesztők életében elég kritikus téma. Ha szóba kerül a refaktorálás szó, akkor mindenki valami szörnyű, 10 éves kódbázisra asszociál, aminél ha bekapcsoljuk a deprecated hibák kiírását, százával kezdi kihányni két kiíratás közben, hogy bizony az mysql_connect már öregebb, mint az iOS7.. így le kéne cserélni. A refaktorálás mikéntjéről, példákról és magáról a folyamat szellemiségéről lesz szó az alábbi cikkünkben:

Hat-Design

Design hat, a gányer-kipa ellentéte

Tovább »

07Feb

Partizánkodás 3 - Tele a puttonyt!

Az előző részben elkezdtük csinálni a saját kis composer package-ünket, ami egyelőre még elég szegényes funkcionalitással bír. Most nem ártana telepakolni azokkal a bizonyos tutiságokkal és ha ezekkel végeztünk, elkezdhetünk pár tesztet is ráengedni. Ha mindezen csomagon többen dolgozunk és folyamatos javításokat is eszközölünk rajta, akkor nem árt bekötni egy CI-be, ahol miután összeintegráltuk a változásokat (ez lesz majd a "nightly build"), az általunk (és mások) által írt teszteket végigeresztjük rajta és csak azok sikeressége esetén fogjuk megveregetni a saját vállunkat. Hogyha mégjobban figyelni akarunk a kódminőségre, akkor bekötünk mellé egy SonarQube-ot is, amivel a stílushibákat tudjuk kiküszöbölni.

mega

Aki miatt csecsre fut a build, az meglakol!

Tovább »

17Jan

Partizánkodás 2 - Csomagolástechnika

Amikor az ember fejlesztésbe kezd, és eljut arra a pontra, hogy egy kódrészletet átmásol A helyről B-be, akkor a józan ész azt diktálja, hogy bizony ezt lehetne szebben is csinálni. Azt a részt, amit átmásoltunk, kívülről konfigurálhatóvá tehetnénk, és újrahasznosíthatnánk a B helyen, ezzel megspórolva X sornyi kódot. Ebből születnek a függvények, amikből aztán osztályok lesznek és végül megszületik az első saját kis függvénykönyvtárunk. Ezeknek a függvénykönyvtáraknak a menedzselésére szolgál a a composer, amiről már korábban is írtam. Ehhez fogunk most magunknak egy csomagot készíteni, a saját kis repositorynk egyikében, lecsekkoljuk, hogy működik-e és ha igen, akkor nekilátunk összerakni a laravelhez illeszthető csomagunkat, amivel a saját kis admin felületünket legeneráljuk. Ha ez kész, ennek mintájára több felülethez is készíthetünk ilyen generátor könyvtárat.Package-0

Tovább »

2014-2018 © Letscode.hu. Minden jog fenntartva. Build verzió: