Przy okazji pracy nad pewnym projektem, doszedłem do miejsca, w którym potrzebowałem prostego REST API. Wszystkie rozwiązania, które sprawdziłem były albo przerośnięte albo nie działały zgodnie z moimi oczekiwaniami. W ten sposób powstała kolejna paczka do Laravela mojego autorstwa. Generic REST API, bo o niej mowa, jest paczką, która na podstawie modeli zdefiniowanych w pliku konfiguracyjnym, udostępni API do pobierania i zapisywania danych. Na chwilę obecną paczka oferuje podstawową funkcjonalność CRUD-a. W przyszłości planuję dodanie walidacji zapisywanych danych, paginację zwracanych... [[ This is a content summary only. Visit my website for full links, other content, and more! ]]

O integracji z Facebookiem pisałem już nie raz. Od mojego ostatniego wpisu na ten temat (maj 3014) trochę się pozmieniało. Ze względu na sporą popularność poprzedniego wpisu (według GA) postanowiłem odświeżyć temat. No to zaczynamy Na wstępie utwórz aplikację na Facebooku. Żeby to zrobić twoje konto musi być zweryfikowane. Jak już potwierdzisz, ze ty to […]

Ze słowem anagram nie jeden z Was się spotkał. A jeśli się nie spotkaliście to zachęcam do odwiedzenia Wujka Google lub Cioci Wikipedii.

Dzisiejsze zadanie będzie proste. A przynajmniej tak ma się wydawać. Lecimy...

Zgodnie z obietnicą przedstawiam kolejną część postu poświęconego frameworkowi Ruckusing Migrations. W tym tekście przedstawię podstawowe możliwości biblioteki na praktycznym przykładzie. Zakładam, że posiadasz teoretyczną wiedzę na temat sposobu działania tej biblioteki a także potrafisz ją prawidłowo skonfigurować.

Jeśli nie posiadasz tej wiedzy zapraszam w do zapoznania się z postem poświęconym tym zagadnieniom.

A więc chcesz dodać nową tabelę do bazy danych?

Aby tego dokonać w pierwszej kolejności należy w CLI przenieść się do głównego katalogu biblioteki i tam wykonać polecenie:

php ruckus.php db:generate <nazwa_pliku>

Ostatni parametr możemy podać w formacie camelCase lub poszczególne słowa mogą być oddzielone podkreśleniami. Po naciśnięciu entera nazwa pliku i tak zostanie skonwertowana do UpperCamelCase. Przykładowo jeśli wykonam następujące poniższe polecenie:

php ruckus.php db:generate adding_a_new_table

to w konsoli pojawi się informacja o tym, że utworzony został plik o nazwie 20160109113352_AddingANewTable.php. Teraz należy przejść do katalogu, który wskazaliśmy w pliku konfiguracyjnym aby w nim były przechowywane pliki zawierające dane dotyczące zmian w bazie i tam znajdziemy nasz nowo utworzony plik.

Gdy go otworzymy zobaczymy kod podobny do tego poniżej:

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

Zwiń
Czytaj na blogu autora...

Dziś zaczynamy swoją przygodę z Code Kata. Przed wami pierwsze ćwiczenie które będziecie realizować.

Wg. poprzedniej części zajmiemy się ćwiczeniem zarówno TDD jak i pogłębianiem swojej wiedzy, doświadczenia, odkrywania nowych torów naszego umysłu.

Czym jest Code Kata?

Są to ćwiczenia programistyczne które wykonuje się regularnie. Najczęściej ćwiczy się jedno zadanie przez kilka/kilkanaście dni.

Za każdym razem należy starać się aby rozwiązania prowadziły do otrzymania takiego samego wyniku, jednak nie wymaga aby był to taki sam kod. Do rozwiązania możemy dojść różnymi drogami, lecz zawsze należałoby wybierać najlepsze, najbardziej optymalne, wydajne.

Wersjonowanie bazy danych prostym tematem nie jest. Nie dla wszystkich. I o ile wersjonowanie „zwykłych” plików tekstowych zawierających kod jest sprawą jasną i prostą to jak zachowywać różne wersje czasami bardzo skomplikowanych schematów baz danych? Czy wersjonować samą tylko strukturę czy także dane? I wreszcie jak aktualizować bazę na „produkcji” – wszak wykonywanie aktualizacji „ręcznie” jest obarczone wysokim prawdopodobieństwem popełnienia zwykłego ludzkiego błędu. 

Co robić? Jak żyć?

Temat wersjonowania wydaje się na tyle skomplikowany, że wiele osób nie podejmuje nawet próby wyszukania narzędzia, które ułatwiło by zadanie. A nie trzeba zbyt długo i głęboko szukać. Znalezienie takiego rozwiązania jak framework Ruckusing nie powinno zająć więcej niż 10 minut. Idea tego narzędzia została zapożyczona (a jakże!) z systemu migracji wbudowanego w Ruby on Rails.

Jak to działa?

Ruckusing przechowuje kolejne aktualizacje bazy w klasach PHP, które zawierają kod wprowadzający zmiany w bazie. Każdy plik generowany jest za pomocą odpowiedniego polecenia w CLI. Nazwa każdego pliku jest poprzedzona datą i czasem, w którym został wygenerowany co utrudnia przypadkowe stworzenie dwóch plików o tej samej nazwie. Po wypełnieniu klasy kodem opisującym naszą aktualizację wracamy na chwilę do CLI – wydajemy polecenie odpowiadające za wprowadzenie zmian i już mamy zaktualizowaną bazę danych. Za pomocą jednego polecenia wprowadzone do bazy mamy nawet bardzo skomplikowane aktualizacje. Informacje o tym jakie zmiany zostały już wprowadzone do bazy przechowywane są w tabeli db_schema w postaci kolejnych rekordów zawierających przedrostek nazw plików (ten z datą i czasem).

Jak dodać do Ruckusing projektu?

Konfiguracja jest bardzo prosta i sprowadza się w zasadzie do dodania nowej zależności dla Composera:

ruckusing/ruckusing-migrations

Następnie wpisujemy composer update i już mamy zainstalowany framework.

Jak skonfigurować?

W katalogu głównym frameworku znajduje się katalog config a w nim z kolei szablon pliku konfiguracyjnego (database.inc.php). Plik ten należy skopiować do głównego katalogu biblioteki i zmienić jego nazwę na ruckusing.conf.php.  Sama biblioteka obsługuje bazy MySql, PostgresSql i SqlLite. Tak więc gdy otworzymy plik ruckusing.conf.php zobaczymy w nim tablice asocjacyjną z przykładowymi szablonami konfiguracji dla każdej z typów baz. Każda z przykładowych konfiguracji zapisana jest w odpowiednim kluczu (np. development). Jest to nazwa środowiska w jakim działa baza danych. Możemy tworzyć rzecz jasna własne środowiska poprzez dodawanie nowych kluczy i w jednym pliku przechowywać różne konfiguracje dla różnych środowisk.

Jeśli chodzi natomiast o konfiguracje samego połączenia z bazą to zapewne będziecie wiedzieć jak uzupełnić wszystkie dane poza directory. Ten parametr odpowiada za nazwę katalogu, w którym będą przechowywane pliki opisujące zmiany w bazie danych. Istotne jest aby w naszym środowisku developerski i w środowisku produkcyjnym ten katalog miał tą samą nazwę dzięki czemu gdy będziemy pobierać, commitować zmiany i później pobierać do wersji produkcyjnej wszystko będzie w jednym katalogu i będzie można łatwo wprowadzić zmiany na „produkcji”.

Ostatnią zmianą jaką należy wprowadzić w pliku konfiguracyjnym jest usunięcie fragmentu kodu („. ‘..’ ”) znajdującego się na samym końcu linii.

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

Zwiń
Czytaj na blogu autora...