Topic is not 0 day news. First commits adding new version constraints were added on december 2014. I’ll only mention what’s new:

• when defining logical AND you can use space just like you use comma, so >1.0 <=1.5 is the same as >1.0,<=1.5
• when defining logical OR you should (must?) use double pipe || instead of single pipe |
• I’m sure you know tilde operator ~1.5 (which means you’re interested in versions >=1.5,<2), new caret operator ^ was introduced, ^1.2.3 definition means >=1.2.3,<2, so the change is you can more precisely define starting version; if you would like to define the same constraint without caret operator you would need to write ~1.2,>=1.2.3, so new operator is more concise
• the last one, hyphen operator - is inclusive set of versions, it’s a kind of mysterious to me, 1.0 - 2.0 is equivalent to >=1.0.0 <2.1 and 1.0.0 - 2.1.0 is equivalent to >=1.0.0 <=2.1.0 (take a look at composer doc and then matcher source code)

Żeby usystematyzować cykl (Nie)bezpieczny kod postanowiłem stworzyć spis treści. Jezeli pojawią się nowe wpisy z serii spis będzie na bieżąco aktualizowany. Spis treści (Nie)bezpieczny kod – SQL injection (Nie)bezpieczny kod – XSS (Nie)bezpieczny kod – CSRF (Nie)bezpieczny kod – Shell injection (Nie)bezpieczny kod – Code injection (Nie)bezpieczny kod – Brute force

O brute force słyszał pewnie każdy programista. Jest to prymitywna i prosta metoda ataku, ale w czasach coraz szybszych maszyn i internetu może okazać się skuteczna, o ile nie zabezpieczy się odpowiednio aplikacji. Jak to zrobić przeczytasz w tym artykule :) Trochę teorii Brute force polega na próbie odgadnięcia hasła poprzez generowanie wszystkich możliwych kombinacji […]

Przez pryzmat ostatnich rozmów rekrutacyjnych, oraz architektury kilku projektów jakie analizowałem, dochodzę do wniosku, że spora część „programistów” nie tylko nie widzi sensu, co nie nie ma pojęcia o istnieniu pewnych standardów w świecie PHP. Dzisiaj chciałbym przybliżyć kilka pojęć, kilka z naciskiem na OOP.

PHP Framework Interop Group (PHP-FIG)

Moim zdaniem w tym momencie znajomość PSR-0 do PSR-4 to podstawa. Projekt PHP-FIG zawiązał się w 2012 roku (3 lata temu). Przy „jednym stole” zasiadł m.in. Matthew Weier O’Phinney reprezentujący ZF2, Fabien Potencier z Symfony2, jak również Jordi Boggiano odpowiedzialny za Composer i Packagist. Pomysł był prosty – każdy zespół podchodził inaczej do tematu autoloadera (PSR-0), jak również pojawiały się różne wariacje coding style (PSR-1 i PSR-2). Później powstał standard związany z interfejsem dla Loggera (PSR-3, dla niektórych dyskusyjne, dla mnie ok) oraz udoskonalona koncepcja autoloadera (PSR-4). A reszta już poszła lawinowo, zespół poniosła fantazja.

Reguła KISS

KISS to skrót od Keep It Simple, Stupid. Nie komplikuj kodu, pisz przejrzysty kod bez zbędnych dodatków. Dojdzie nowy programista do projektu, lub ktoś przejmie projekt? Taka osoba powinna móc szybko się wdrożyć, zrozumieć kod bez czytania obszernej dokumentacji i wprowadzić potencjalne poprawki. Pamiętaj – twórz i utrzymuj taki kod, żeby każdy mógł go zrozumieć i nie musiał posiadać doktoratu w tej dziedzinie.

Zasada DRY

DRY to skrót od Don’t Repeat Yourself. Krótko: nie powtarzaj się. Widzisz podobne elementy kodu? Wydziel je, ustandaryzuj. Podczas deploy’u robisz zawsze te same czynności ręcznie? Zautomatyzuj to. Zaczynasz kolejny projekt? Z poprzedniego wydziel wspólną bibliotekę/bundle/etc.

Zasada YAGNI

YAGNI to skrót od You Aren’t Gonna Need It. Nie potrzebujesz czegoś tu i teraz, ani w następnej iteracji? Nie rób tego, nie twórz kodu na wyrost bo kiedyś wykorzystasz jakiś interfejs, albo cały mechanizm do tworzenia uniwersalnych walidatorów. Większa ilość kodu zwiększa prawdopodobieństwo wystąpienia błędów oraz skomplikowanie kodu. Ta zasada po części wiąże się z KISS – wybieraj najprostszą drogę do celu, która daje zwiększoną niezawodność zaimplementowanych algorytmów.

Wzorce projektowe

Jest to chyba jedyny element programowania obiektowego, który został opanowany, a raczej wykuty przez programistów. Większość osób jest w stanie wymienić 3 wzorce i je opisać. Gorzej z wytłumaczeniem własnymi słowami do czego tak naprawdę dany wzorzec służy. Moim zdaniem lepiej nie znać na blachę kilku pojęć z PHP, niż mieć problem ze zrozumieniem podstaw. Przy okazji przypomnijmy sobie czym jest OOP – podstawowe założenia paradygmatu obiektowego:

• Abstrakcja
• Hermetyzacja
• Polimorfizm
• Dziedziczenie

SOLID

Same wzorce projektowe, czy tworzenie klas i ich ciał nie świadczą o tym, że programuje się już obiektowo. Możemy mieć masę klas, zależności itp. A kod nadal jest proceduralny, bo ciągle zapominamy o OOP. W tym przypadku pomoże nam zastosowanie 5 założeń nazwanych w skrócie SOLID.

• Single responsibility principle – Zasada jednej odpowiedzialności
• Open/Closed principle – Zasada otwarte-zamknięte
• Liskov substitution principle – Zasada podstawienia Liskov
• Interface segregation principle – Zasada segregacji interfejsów (eng)
• Dependency inversion principle – Zasada odwrócenia zależności (eng)

GRASP

Jakby równolegle obok zasad projektowania obiektowego SOLID, są zasady GRASP (General Responsibility Assignment Software Patterns).

W dużym uproszczeniu w GRASP chodzi o opisanie podstawowych zasad, którymi będziemy kierować się podczas tworzenia całego projektu, gdzie wszystko kręci się wokół metodycznego podejścia do fundamentów OOP. GRASP składa się z 9 zasad: Creator, Information Expert, Controller, Low Coupling, High Cohesion, Polymorphism, Indirection, Pure Fabrication, Protected Variations. Małe wprowadzenie do GRASP znajdziecie w grwykładzie Wiktora Zychla.

Konferencje

Tak wiem, konferencje != stanardy, przynajmniej teoretycznie. Jeśli znasz powyższe reguły, przeczytałeś wiele mądrych książek oraz masz za sobą kilka projektów… Pamiętaj nie stój w miejscu, świat dookoła się zmienia, tak samo zmienia się IT. Powstają nowe frameworki, biblioteki, narzędzia, inni programiści natrafiają na inne problemy. Warto pojechać chociażby na PHPCon (niedługo pojawią się informacje o tegorocznej edycji), czy również pójść na spotkanie lokalnej społeczności (PHPers).

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

W trakcie naszej pracy napotkamy na różne sytuacje w których potrzebujemy zarejestrować jakiś Service Provider tylko w środowisku developerskim. Możemy dodać odpowiednie wpisy w config/app.php ale w przypadku braku na wersji produkcyjnej dostaniemy błąd. Taka sytuacja może dotyczyć paczek zainstalowanych z sekcji require-dev pliku composer.json.

Rozwiązanie bardzo proste i eleganckie które zaoszczędzi nam czasu i kłopotu.

composer.json

Wpierw musimy mieć jakąś paczkę którą chcemy załadować lokalnie. Dodajemy do composer.json do sekcji require-dev np:

"barryvdh/laravel-debugbar": "2.0.*@dev"

i robimy composer update

Tworzymy ServiceProvider

Tworzymy ServiceProvider odpowiedzialny za warunkowe rejestrowanie:

php artisan make:provider LocalEnviromentServiceProvider

Ładujemy go w pliku config/app.php

'App\Providers\LocalEnviromentServiceProvider',

Rejestrowanie własnych Service Provider

Na początku dodajemy pole gdzie będziemy trzymać nasz wpisy:

    /**
     * List of Local Enviroment Providers
     * @var array
     */
    protected $localProviders = [
        'Barryvdh\Debugbar\ServiceProvider',
    ];

oraz metodę do ich rejestrowania:

    /**
     * Loda local service providers
     */
    protected function registerServiceProviders()
    {
        foreach ($this->localProviders as $provider)
        {
            $this->app->register($provider);
        }
    }

a na końcu do metody boot() dodajemy wywołanie:

    /**
     * Bootstrap the application services.
     * @return void
     */
    public function boot()
    {
        if ($this->app->isLocal())
        {
            $this->registerServiceProviders();
        }
    }

Inne środowiska

Jeśli chcemy ładować nasze wpisy w innych środowiskach niż local to zmieniamy

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Tematem Domain-Driven Design jestem zainteresowany już od dłuższego czasu, ale ostatnio częstotliwość jego występowania przy okazji developmentu znacznie się zwiększyła.Biorąc to pod uwagę zdecydowałem się na odświeżenie swojej pamięci i ponowne przewertowanie stronic Domain-Driven Design Eric’a Evansa. A skoro już to zrobiłem, to chyba warto podzielić się odczuciami i obserwacjami na temat tej lektury z Wami.Czytaj więcej »

Wraz z ukazaniem się Laravel 5 dostaliśmy z marszu kilka udogodnień m.in. kontrolery do logowania, rejestracji. To wszystko zostało okraszone przez Bootstrap. Ale co jeśli nie chcemy tego wszystkiego, tylko czystą aplikację?

Nic prostszego. Wystarczy jedna komenda:

php artisan fresh

I już pozbyliśmy się wszystkiego co przyszło z nowym projektem.