Composer

Az utóbbi időben volt szerencsém elég sokat játszani a composerrel. Ennek tapasztalatait szeretném összeszedni. Nem célom egy teljesértékű composer leírást adni, inkább arra koncentrálok, hogy a composer.jsonban való matatás helyett mennyire jól használhatók a CLI parancsok.

Mi is az a composer?

Kezdjük Ádámtól és Évától. A composer egy dependencia menedzsment (magyarul függőség kezelő) alkalmazás PHP projektekhez. Ma már senki nem ír teljesen nulláról, csak és kizárólag saját kódból építkezve meg egy alkalmazást, de még ha így is tesz, akkor is jól teszi ha független komponensenkben, libekben gondolkozik. Egy szó mint száz, a composerrel való találkozást senki nem fogja megúszni (kivéve természetesen ha azt is megírja magának).

Telepítés, inicializálás

A composert pharban hozza a jézuska:

cd ~/FirstComposerProject
curl -sS https://getcomposer.org/installer | php

Ezt érdemes a projektünk gyökerében elvégezni és egyből hozzá is adni a repohoz (ugye senki nem dolgozik verziókövetés nélkül – még otthon magányosságában sem?).

git add composer.phar
git commit -m 'add composer'

Mivel viszonylag ritka az az eset, hogy több verzió kell a composerből ezért én tartok egyet a PATH-on is.

sudo cp composer.phar /usr/local/bin/composer
sudo chmod +x /usr/local/bin/composer

Így gyorsan és fájdalommentesen egy bárhonnan futtatható composer a jutalmunk. Mint minden szoftvert a composert is fejlesztik, nem árt néha frissíteni.

sudo composer selfupdate

vagy ízlés szerint akár

sudo composer self-update

De hogy lesz ebből projekt. Hát egyszerűen, inicializálni kell. Mások ezt úgy mondanák, hogy hozz létre egy composer.json filet és tegyél bele ezt-meg-azt. Mi azért probáljuk meg egyszerűbben.

composer init

Ilyen egyszerű. Egy interaktív felület gyönyörűen végigvezet a szükséges adatokon, szinte el sem lehet rontani. Valahogy így néz ki.

  Welcome to the Composer config generator  


This command will guide you through creating your composer.json config.

Package name (<vendor>/<name>) [root/first-composer-project]: my/first-project        
Description []: Az elso composeres probalkozas
Author [blerou <sulik.szabolcs@example.com>]: 
Minimum Stability []: 
License []: MIT

Define your dependencies.

Would you like to define your dependencies (require) interactively [yes]? no
Would you like to define your dev dependencies (require-dev) interactively [yes]? no

{
    "name": "my/first-project",
    "description": "Az elso composeres probalkozas",
    "license": "MIT",
    "authors": [
        {
            "name": "blerou",
            "email": "sulik.szabolcs@example.com"
        }
    ],
    "require": {

    }
}

Do you confirm generation [yes]? yes

A dependenciák összeválogatását kihagytam, arról később. A lényeg, hogy a végén kiírt JSON megjelenik a composer.jsonben is. Nincs más hátra, mint előre, repoba vele.

git add composer.json
git commit -m 'add composer.json'

Minden kezdet nehéz, na ez nem az.

Függőségek kezelése

El is érkeztünk a lényegi részhez. Tegyük fel, hogy egy silex alkalmazást készülünk építeni, ehhez nyilvánvalóan kelleni fog maga a silex. A composer a csomagneveket vendor/project formában várja, valamint minden csomaghoz tartozik egy verzió is (a szemantikus verziózásra nem szeretnék kitérni elég írás van arról máshol :)). Az a szép a composerben, hogy nem kell szinte semmit fejben tartani a csomagokról, mert ő minden segítséget megad. Szóval adjuk hozzá a silexet a projektünkhöz.

composer require

Igen, ilyen egyszerű. Először rákeresünk a csomag nevére, majd kiválsztjuk, végül választunk hozzá egy verziót is (ha nem tudjuk miből választhatunk, akkor a * a jó választás) és már települ is. Íme az eredmény:

Search for a package []: silex

Found 15 packages matching silex

   [0] silex/silex
   [1] yunait/level3-silex
   [2] bernard/silex
   [3] silex/ckan_client
   [4] silex/web-profiler
   [5] neutron/silex-imagine-provider
   [6] neutron/silex-filesystem-provider
   [7] mheap/silex-assetic
   [8] mheap/silex-memcache
   [9] macedigital/silex-jms-serializer
  [10] fabpot/silex-skeleton
  [11] jdesrosiers/silex-cors-provider
  [12] jdesrosiers/silex-swagger-provider
  [13] ddesrosiers/silex-annotation-provider
  [14] verdet/silex-sphinxsearch

Enter package # to add, or the complete package name if it is not listed []: 0
Enter the version constraint to require []: *
Search for a package []: 
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing psr/log (1.0.0)
    Loading from cache

  - Installing symfony/routing (v2.3.6)
    Downloading: 100%         

  - Installing symfony/debug (v2.3.6)
    Downloading: 100%         

  - Installing symfony/http-foundation (v2.3.6)
    Downloading: 100%         

  - Installing symfony/event-dispatcher (v2.3.6)
    Loading from cache

  - Installing symfony/http-kernel (v2.3.6)
    Downloading: 100%         

  - Installing pimple/pimple (v1.0.2)
    Downloading: 100%         

  - Installing silex/silex (v1.1.1)
    Downloading: 100%         

symfony/routing suggests installing symfony/config ()
symfony/routing suggests installing symfony/yaml ()
symfony/routing suggests installing doctrine/common ()
symfony/debug suggests installing symfony/class-loader ()
symfony/event-dispatcher suggests installing symfony/dependency-injection ()
symfony/http-kernel suggests installing symfony/browser-kit ()
symfony/http-kernel suggests installing symfony/class-loader ()
symfony/http-kernel suggests installing symfony/config ()
symfony/http-kernel suggests installing symfony/console ()
symfony/http-kernel suggests installing symfony/dependency-injection ()
symfony/http-kernel suggests installing symfony/finder ()
silex/silex suggests installing symfony/browser-kit (>=2.3,<2.5-dev)
silex/silex suggests installing symfony/css-selector (>=2.3,<2.5-dev)
silex/silex suggests installing symfony/dom-crawler (>=2.3,<2.5-dev)
silex/silex suggests installing symfony/form (>=2.3,<2.5-dev)
Writing lock file
Generating autoload files

Ha már ismerősebb a táj lehet ezt rövidebben is írni:

composer require silex/silex 1.1.1

vagy

composer require silex/silex=1.1.1

A require parancs alkalmas arra, hogy minden, productionben is szükséges függőséget megadjunk. Azonban nem csak ilyen függőségek vannak. Vannak olyan libek, amit kifejezetten fejlesztéshez veszünk igénybe, de nem akarunk látni az éles rendszerben. Ilyen, hogy más ne mondjak a PHPUnit.

composer require --dev phpunit/phpunit 3.7.28

A fenti módszerekkel beállított függőségek gyönyörűen megjelennek a composer.json-ban, anélkül, hogy egy ujjal is hozzányúltunk volna. Persze ha nem egyedül dolgozunk egy projekten, akkor könnyen előfordulhat, hogy más valaki vesz fel új függőseget. Ezeket nem árt telepíteni.

composer install

Ha azt szeretnénk, hogy a fejlesztéshez használatos újabb függőségek is települjenek szükség van a --dev kapcsolóra

composer install --dev

Időnként pedig nem árt frissíteni is (ez elintéz mindenféle függőséget, korra és nemre való tekintet nélkül).

composer update

Minden require, install és update után létrejön vagy frissíl egy composer.lock file. Itt tárolja a composer az aktuális telepítés pontos verzióit (az összes függőségével együtt természetesen). Ajánlás alapján ennek is a repoban a helye.

git add composer.lock
git commit -m 'add composer.lock'

További hasznos parancsok

Előfordul, hogy nincs szükség sem telepítésre sem frissítésre, de szeretnénk újrageneráltatni az autoloadert. Ilyen eset ha át akarjuk állítani a projekt autoloaderét PSR0-ról classmap alapúra.

composer dumpautoload

vagy

composer dump-autoload

Persze elő fog fordulni, hogy kézzel kotorásszunk a composer.json-ban. Ekkor könnyen megviccelhetnek az ott felejtett vesszők és egyéb állatok. Szerencsére leellenőrzhetjük a file egészségét.

composer validate

Itt a vége

A leírtaknál több parancsa van a composernek természetesen, de ezek a függőségkezelés szempontjából a legfontosabb, a többi szinte csak hab a tortán.

Jó szórakozást.

Kategória: composer, php | Megjegyzés hozzáfűzése

Simple Made Easy

Újra meg kellett nézni Rich Hickey zseniális előadását. Kötelező darab, aki még nem látta nézze meg mindenképpen, ha már láttad nézd meg még egyszer!😉

Kategória: design, talk | Megjegyzés hozzáfűzése

Scrum vagy mi?

Hétfőn páran átmentünk a szomszédba, a ChemAxon-hoz, ahova meghívtak minket, hogy vegyünk részt a belsős techtalkon. Szeretek hozzájuk átjárni, kellemes a hangulat. Most sem csalódtam, egy szimpatikus fiatalember beszélt arról, hogy az ő csapatuk hogyan is csöppent bele a scrum világába, hogyan és mit csináltak rosszul és hogy végül hol kötöttek ki, hogyan csinálják most. Tanulságos volt.

A magam részemről dolgoztam már mindenféle metodika nélkül (mint oly sokan), scrumban és jelenleg kanbanban (nem dupla ragozás cserébe elég hülyén néz ki ;)). A lényeg, hogy egyáltalán nem rajongok a scrumért, viszont ez az előadás megerősített bennem egy mélyen motoszkáló gondolatot, érzést: nevezetesen ezek csak frameworkök, csak eszközök, amelyek keretet adnak a munkának. De végsősoron az egész csak az emberen múlik, azon hogy mennyire érti meg és mennyire valósítja meg azt, amire szüksége van. Minden más csak eszköz. Ha nem segítesz magadon mit várhatsz egy eszköztől?

Hogy triviális a kérdés és a válasz? Tényleg?

Kategória: gondolatok, scrum | Megjegyzés hozzáfűzése

A program komplexitás skálázódásáról

Michael Feathers nevű úriembernek hála ismerkedtem meg a Reg Braithwaite nevű úriember munkásságával. Azt kell tudni róla, hogy egy ideje már a szakmában van és rengeteget ír, amit az évek során elég változatos formában tett meg.

A továbbiakban egy írására szeretnék koncentrálni, ami a szürreális számokról szól. Valójában pedig a program komplexitás skálázódásáról. A szürreális számok példája csak egy rendkívül elegáns példa a téma bemutatásához, megértéséhez. Nem kívánom összefoglalni a cikket, mindenkinek javaslom az elolvasását. (a szépséghez hozzátartozik, hogy a github repoban a példakód is ott csücsül a post mellett.)

Az ok pedig, ami ezt a postot ihlette az, hogy egy adott programnyelven a kód ábrázolása mennyibe marad egyszerű ahogy a probléma komplexitása nő. A mai általános célú nyelvek mindegyike Turing-teljes nyelv (még a Brainfuck is), azaz konyhanyelven bármely probléma leírható vagyis arra megoldás adható bennük. Ez azonban csak egy matematikai állítás, pusztán egy egzisztencia tétel. Arról nem szól, hogy mennyi idő alatt, mennyire karbantartható módon és mennyi fájdalom árán tehető meg mindez.

Nekem pedig egyre inkább fáj, amikor hihetetlen mennyiségű boilerplate kódot kell leírnom, ha ki akarok fejezni valami egyszerű dolgot (PHP-ról beszélgetünk) a lehető legegyszerűbben, és ezen a design minták sem segítenek. Sőt. Kérdés, hogy mennyiben teszik egyszerűbbé a design patternek a fejlesztést és mennyiben language smellek.

Kategória: gondolatok | Címke: , | Megjegyzés hozzáfűzése

Káosz és kód

Mostanában olvasom James Gleick: Káosz című könyvét. Érdekes gondolatokat ébreszt az emberben.

A káosz természetesen, mint káoszelmélet szerepel a könyvben és az írásomban is. Csakhogy a káosz egy (eléggé elcsépelt) hétköznapi szavunk és (sajnos) elég gyakran találkozunk vele a napi rutin során. Azonban ha úgy fogalmazunk, hogy érzékenység a kiinduló feltételekre, akkor érdekes következtetésekre juthatunk.

Bővebben…

Kategória: gondolatok | Címke: , | Megjegyzés hozzáfűzése

Feature Bits – kikapcsolható funkcionalitás menet közben

Egész jó kis előadás, érdemes megnézni Feature Bits: Enabling Flow Within and Across Teams.

Sok elgondolkoztató dolog hangzik el, komoly érvek mellette és ellene is. A bácsiknak úgy tűnik van tapasztalata a témában.

Kategória: fejlesztés | Címke: , | Megjegyzés hozzáfűzése

Nem mai, de érdekes írás Michael Nygard-tól:

Nem mai, de érdekes írás Michael Nygard-tól: The Future of Software Development

Kategória: gondolatok | Címke: | Megjegyzés hozzáfűzése