Chess Browser - konfigurator pozycji szachowych

Geneza projektu była taka - stworzyć narzędzie do łatwego ustawiania pozycji szachowych i analizowania możliwych posunięć. Wiadomo - posługiwanie się screenshotami szachownicy i przesuwanie pionków w Paincie było zadaniem karkołomnym. Powstał więc projekt - była szachownica, pionki z możliwością ich przesuwania, czyli wszystko co trzeba.

No dobrze, a co się stanie, jeśli wykonamy nieprawidłowy ruch? Albo wykonamy ruch białymi, gdy ruch mają czarne i vice versa? Trzeba tego pilnować. Kolejność ruchów białe-czarne to łatwizna. Prawdziwym wyzwaniem okazało się pilnowanie, aby nieprawidłowy ruch nie został wykonany. Należało wprowadzić reguły szachowe - zasady poruszania się i bicia poszczególnych figur, roszada, promocja, bicie w przelocie, sytuacja szacha, mata, pata itd. Najtrudniejsza była reguła pilnująca, aby wykonany ruch nie doprowadził do szacha na własnym królu.

Udało się wreszcie dodać wszystkie reguły. System pilnował poprawności ruchów - można było grać. Oczywiście samemu ze sobą. Ale chodziło mi o łatwe uzyskanie dowolnej sytuacji szachowej, aby następnie analizować kolejne możliwe ruchy. Na tym etapie można było to uzyskać jedynie poprzez normalną grę od pozycji startowej. A to było czasochłonne i wymagało uwagi - trzeba było zbić nie występujące w analizowanej sytuacji figury, a pozostałe ustawić na właściwych pozycjach. I to wykonując dopuszczalne posunięcia - przecież system pilnował, czy nie dochodzi do nadużyć!

Potrzebne więc było narzędzie dodatkowe. Omijające reguły szachowe. Pozwalające szybko usuwać zbędne figury, a te biorące udział w rozpatrywanej sytuacji przesuwać w dowolne miejsce. I to się udało. Pojawiły się przyciski włączające tryb usuwania figur oraz tryb ustawiania figur. W obu trybach reguły szachowe są ignorowane, co pozwala na łatwe uzyskanie żądanej konfiguracji na planszy. Po powrocie do normalnego trybu reguły szachowe znów były pilnowane i można było analizować możliwe posunięcia.

Pomocnym narzędziem okazał się rejestr posunięć. Każdy ruch był odnotowany i pokazywany na specjalnej liście. Lista miała też za zadanie umożliwić skok do wybranego kroku. Tu jednak musiałem wprowadzić ograniczenie - jeśli cofniemy się do któregoś kroku, nie będziemy mogli grać dalej. Dopiero gdy ustawimy się na ostatnim kroku, dalsza gra będzie możliwa.

Tak więc musiał powstać dodatkowy mechanizm, który umożliwi cofnięcie ostatniego kroku, tak aby możliwa była dalsza gra. I taki mechanizm powstał. Polegał na cofnięciu się do kroku poprzedniego wraz z usuwaniem wpisu, dzięki czemu nadal byliśmy na ostatnim kroku i mogliśmy grać dalej!

Przydatną opcją okazała się możliwość włączenia podświetlania pól, na które można przesunąć (bądź zbić) zaznaczoną figurę. Wygląda to bardzo efektownie.

Niezbędną natomiast opcją była możliwość zapisania naszej pracy. W końcu żal by było stracić tak żmudnie przygotowaną konfigurację po zamknięciu przeglądarki, czy nawet po ustawieniu nowej sytuacji. Tak więc zapis listy posunięć (bo przecież przygotowana sytuacja szachowa to lista posunięć) musiał powstać! I powstał. Jak to działa? Rejestr ruchów to tablica obiektów z indeksami. Taką tablicę przesyłam na serwer AWS do API Gateway na konkretny endpoint, który wywołując funkcję Lambda zapisuje przesłane dane do bazy danych DynamoDB.

A skoro można było zapisywać historię posunięć, to trzeba też móc ją potem wczytywać. No i w ten sposób powstała komplementarna do niej opcja wczytywania listy konfiguracji, a po wskazaniu jednej z nich załadowaniu jej i odtworzeniu na planszy.

I ostatnia rzecz, którą dodałem - demo gry komputer-komputer oraz komputer-gracz. W pierwszej komputer gra sam ze sobą, w drugiej - można zagrać z komputerem (gracz gra białymi).

Śmiesznie to wygląda, bo oprócz reguł szachowych zastosowałem prostą zasadę preferowania bicia figur z uwzględnieniem ich znaczenia (wagi) oraz ataku na króla. Nie ma tu żadnych strategii ani predykcji.

Kod źródłowy na Githubie: https://github.com/PrivateAccount/ChessViewer

DEMO online: https://master.d2mlbkja551bj3.amplifyapp.com

Jak stworzyć CMS-a bez użycia frameworków

Od dawna interesował mnie temat CMS-ów. Chciałem napisać własnego. W końcu zarządzanie swoją stroną z poziomu przeglądarki na dowolnym komputerze - czy to własnym, czy też kolegi lub koleżanki - jest bardzo wygodne i szybkie, nie trzeba mieć żadnych narzędzi typu klient FTP czy SSH do łączenia się z serwerem. Wystarczy, że otwierasz w przeglądarce swoją stronę, logujesz się do panelu administratora, zmieniasz, co trzeba, wylogowujesz i gotowe. Nowa treść na stronie pojawia się od razu.

Mając hosting i domenę, pokusiłem się o napisanie takiego systemu. Najpierw powstała aplikacja oparta na PHP i MySQL. Funkcje biznesowe były rozdzielone na różne pliki PHP, które jednocześnie generowały stronę. Było w nich wszystko - i łączenie się z bazą danych, i operacje na bazie, i jakaś logika, i wreszcie wstrzykiwanie obrobionych danych do szablonu strony. Spaghetti Code, taki misz-masz.

Chcąc to wszystko uporządkować, napisałem kolejnego CMS-a, który tym razem został oparty na architekturze MVC (model-view-controller). Poszczególne funkcje biznesowe były podzielone na trzy osobne warstwy. Kontroler przyjmował od użytkownika żądania, przekazywał sterowanie do Modelu, który z kolei pobierał dane z bazy lub je zapisywał, a wynik zwracał do Kontrolera. Następnie Kontroler po otrzymaniu danych przekazywał sterowanie do Widoku, podając mu potrzebne dane. Widok, wykorzystując otrzymane dane generował stronę, po czym zwracał ją do Kontrolera, a na koniec Kontroler wysyłał odpowiedź do użytkownika. Całość działała również na PHP i MySQL.

Potem przyszedł pomysł na stworzenie CMS-a opartego na frameworku Angular. Architektura zmieniła się całkowicie. Angular zajmował się nie tylko wyglądem strony, ale też obsługą danych, komunikacją z serwerem. Serwer tylko dostarczał potrzebnych danych, bądź je przyjmował, za pośrednictwem wystawionego API.

Pomyślałem sobie potem, czy nie napisać takiego systemu bez użycia frameworka. W samym HTML, CSS i JavaScript i połączyć to z API dostarczającym danych. I udało się! Wykorzystałem jakiś darmowy szablon dla stron typu wizytówka. Wyciąłem z niego treści, a w ich miejsce wstawiłem puste znaczniki, do których będą wstrzykiwane dane pobrane z serwera poprzez API. Z kolei API zostało oparte na endpointach w postaci plików PHP, które komunikują się z bazą MySQL. Działaniem aplikacji steruje JavaScript, który AJAX-em wysyła żądania do API i pobiera z niego dane, po czym umieszcza je w przygotowanych w szablonie znacznikach. I co, da się? :-)

Aby nie być gołosłownym, zapraszam do obejrzenia efektu tej pracy: http://micro-cms.pl
Możecie też zajrzeć do kodu i zobaczyć, jak to zostało zrobione: https://github.com/andrzuk/microCMS

Stare, dobre serwlety

Skoro udało mi się na platformie Heroku wdrożyć i uruchomić aplikację typu MEAN Stack, czemu by nie zrobić tego samego z aplikacją Java Servlets? Taka myśl mi zaświtała, gdy platforma OpenShift zmieniła sposób dostępu do swoich usług i starą wersję diabli wzięli. Bo pewnie nie wiecie, ale parę lat temu dokonałem tego karkołomnego czynu i swoją javową apkę uruchomiłem na OpenShift. Działała pięknie, aż pewnego dnia platforma została upgrade-owana i apka poszła się... przestała działać, mówiąc oględnie. Żal było tej całej pracy i włożonego wysiłku, a przede wszystkim praktycznego rozwiązania w tej jakże klarownej i wspaniałej technologii, więc szukałem sposobu na udostępnienie mojego projektu.

Nadzieja pojawiła się w momencie, gdy znalazłem platformę wdrożeniową Heroku. Po sukcesie z aplikacją MEAN Stack postanowiłem powtórzyć scenariusz z apką javową. Jednak zdecydowałem, że nie będę tak po prostu przenosił projektu na nową platformę, a zamiast tego przepiszę go. Dlaczego? Z dwóch powodów. Po pierwsze, gdy będę pisał kod od nowa, odświeżę sobie wiedzę na temat technologii Java Servlets. Bo po tych paru latach sporo już zapomniałem. Nie zajmowałem się tą technologią, aplikacja sobie działała, a ja z niej tylko korzystałem. Kodu nie rozwijałem, nawet w ogóle do niego nie zaglądałem. Po drugie, nie dałoby się tak po prostu wgrać całego projektu, licząc na to, że aplikacja ruszy. Zbyt duża była różnica w infrastrukturze - inne komponenty projektu, inna metoda łączenia się z bazą danych. Trzeba by było dużo przerabiać, a tego bardzo nie lubię - nawet we własnym kodzie. Już wolę napisać projekt od początku, tak aby był dostosowany do nowej platformy i na niej działał.

Okazało się, że wdrożenie na Heroku przebiega o wiele łatwiej i przyjemniej niż na OpenShift. Niemniej jednak stworzyłem prosty instruktaż takiego wdrożenia, aby ktoś mógł z niego skorzystać, a i ja sam mógłbym się nim kiedyś posłużyć, gdy znowu zapomnę, jak i co się robiło... No cóż, pamięć to z pewnością nie jest moja mocna strona. :-)

Póki co, apka działa i można ją znaleźć tu: https://java-blog-cms.herokuapp.com.

Apka Node.JS na platformie Heroku

Zabawy z technologią MEAN Stack ciąg dalszy. Tym razem parę słów na temat wdrożenia. Znalazłem doskonałą platformę stworzoną właśnie do takich zadań - Heroku. Mamy tu możliwość uruchamiania aplikacji różnego typu, w tym Node.JS.

Istnieje kilka metod przesyłania kodu aplikacji na platformę: za pomocą Heroku Gita, za pomocą importu repozytorium z GitHuba, za pomocą importu z Dropboxa oraz za pomocą Container Registry. Ja wybrałem pierwszą metodę. Polega na wysłaniu kodu (git push) ze swego lokalnego repozytorium do repozytorium Gita na platformie Heroku.

Aplikacja, którą napisałem, potrzebuje bazy. Bazę mongoDB tworzę i przechowuję z kolei na platformie mLab. Gdy baza jest gotowa, tworzymy dla niej użytkownika. Dostęp do bazy uzyskujemy poprzez connection string, który zawiera nazwę hosta, numer portu, nazwę bazy, nazwę użytkownika i hasło.

Kod naszej aplikacji musi zatem posługiwać się takim stringiem. Jednak aby tych informacji nie przechowywać wprost w kodzie aplikacji - który jest przecież trzymany i potem przeglądany w repozytorium Gita - zapisałem je w zmiennych systemowych, które się tworzy z poziomu platformy Heroku.

W efekcie mamy w pełni działającą aplikację w chmurze. Wszystko odbywa się prosto, szybko i wygodnie. Do uruchomienia nie potrzebujemy ani serwera, ani hostingu, ani nawet własnej domeny. Opisane powyżej czynności ująłem w prostym tutorialu obrazkowym, który zintegrowałem z działającą aplikacją - zapraszam do zapoznania się: https://mean-stack-web.herokuapp.com.

MEAN Stack

Od jakiegoś czasu interesuje mnie temat MEAN Stack-a, czyli stosu technologicznego MongoDB + Express.js + Angular + Node.js. Chciałem bliżej zapoznać się z tymi groźnie brzmiącymi terminami. Angulara już co prawda poznałem - napisałem nawet za jego pomocą apkę (Projekt Angular) - ale pozostałe elementy były dla mnie obce.

Zacznijmy od bazy danych. Przez całe życie - no, może przez pół - używałem relacyjnych baz danych, a konkretnie SQL Server, MySQL. Natura tych baz zapewniała mi z jednej strony elastyczność w projektowaniu modelu aplikacji, a z drugiej dawała możliwość tworzenia złożonych zapytań, dzięki którym dostawałem potrzebne dane. Te cechy sprawiały, że nie wyobrażałem sobie stosowania w aplikacji bazy NoSQL. Ale czy na pewno? Może baza nierelacyjna podoła takiemu zadaniu? No i chciałem to sprawdzić w praktyce.

Stworzyłem projekt aplikacji opartej na bazie MongoDB. Potrzebowałem jeszcze hostingu, platformy, na której to wdrożę. Skorzystałem z OpenShift, który oferuje postawienie aplikacji Node.js na darmowym koncie. A dlaczego Node.js? Bo chciałem pobawić się JavaScriptem na backendzie. Chciałem zobaczyć, jak JavaScript sprawdza się nie tylko w przeglądarkach, ale również na serwerach. No i jak dla mnie bomba! Rewelacja! Mam ulubiony język programowania w każdej warstwie aplikacji! A jeśli dodam, że w całej aplikacji używamy genialnego formatu przesyłania danych JSON, zaczynam czuć się jak w domu!

Ogromnym ułatwieniem przy tworzeniu aplikacji są frameworki. Część serwerową bierze na siebie Express.js. Zapewnia routing, obsługę requestów, komunikację z bazą danych, wysyłanie danych i komunikatów do przeglądarki użytkownika. A wszystko w JavaScript i JSON! Część kliencką bierze na siebie Angular. Zapewnia powiązanie danych z elementami interfejsu, manipulację na widokach, zarządzanie szablonami HTML.

Gdy zebrałem to wszystko do kupy, powstała zgrabna aplikacja-demo typu ToDoList, którą możecie obejrzeć pod linkiem MEAN Stack Auth App, i której kod znajdziecie na GitHubie pod linkiem MEAN Stack App.

Edytor map

W poprzednim artykule (I znowu gierka) napisałem, że do gry można dodawać własne figury. Należy w tym celu napisać w konsoli coś takiego:

shapes.push({ 
  map: [[0, 1, 1], [0, 1, 0], [1, 1, 0]], 
  color: '#0080c0' 
});

Jest to bardzo niewygodny sposób, więc pomyślałem sobie, że warto by było stworzyć narzędzie ułatwiające tworzenie nowych figur. Wynikiem tych przemyśleń stał się tzw. Edytor map, w którym definiowanie własnych figur odbywa się w sposób wizualny.

W edytorze widzimy mapy wszystkich figur gry, co jest ogromnym ułatwieniem dla gracza-projektanta. Już na pierwszy rzut oka widać, że największą zaletą edytora jest wygoda obsługi. Ale chyba najważniejszą jego cechą jest sprawdzanie, czy figura, którą stworzyliśmy, nie występuje już w kolekcji, i w takiej sytuacji poinformowanie nas o tym i niedopuszczenie do jej dodania. Również podczas edytowania map z kolekcji odbywa się takie sprawdzanie. A ponieważ figury mogą się podczas gry obracać, kontrola powtarzalności uwzględnia położenie mapy w każdym z czterech kierunków.

Oczywiście poza dodawaniem figur do kolekcji możemy je też usuwać. Co prawda możliwe to było również z konsoli poprzez wpisanie polecenia:

shapes.splice(3, 1);

gdzie pierwszy parametr oznacza indeks w kolekcji liczony od zera, a drugi - ilość usuwanych elementów. Ale działając w ten sposób nie wiedzieliśmy, która figura zostanie usunięta. A posługując się edytorem, widzimy dokładnie, którą figurę usuwamy.

Kolejną możliwością, już bardziej estetyczną, jest zmiana kolorów naszych figur - zarówno tych z kolekcji, jak i dodawanej.

Bawiąc się w ten sposób figurami możemy dojść do wniosku, że warto by było zachować naszą pracę, tak aby przy kolejnym uruchomieniu gry zestaw pieczołowicie przygotowanych przez nas figur nie przepadł. Użyłem do tego mechanizmu LocalStorage. Podczas uruchamiania gra sprawdza, czy w LocalStorage istnieje zapisany przez nas zestaw, i jeśli istnieje, ładuje go zastępując zestaw "fabryczny".

Oceńcie zresztą sami, czy warto było trudzić się nad takim rozwiązaniem. A przy okazji rozerwijcie się, grając w Tetrisa własnymi klockami. Zapraszam serdecznie: https://master.d1zjxkgl40pyw5.amplifyapp.com

I znowu gierka

Tak mi się spodobało pisanie w Java Scripcie, że trzasnąłem następną gierkę. Jest to znana wszystkim układanka Tetris. Gra jest osadzona na podstronie mojego CMS-a, podobnie zresztą jak poprzednia gra, Snake. Udało mi się uzyskać w miarę zgrabny kod, z którego jestem całkiem zadowolony. Aczkolwiek jest jedna rzecz, do której bym mógł się przyczepić - algorytm obracania figur. Bazuje on na 2-wymiarowych macierzach 3x3 i gdybym chciał w przyszłości dodać figury o większych rozmiarach, algorytm należałoby przerobić na bardziej uniwersalny, obsługujący figury dowolnej wielkości. Dało mi to do myślenia i właśnie się nad tym głęboko zastanawiam... Może coś wymyślę, a tymczasem zapraszam do zagrania on-line: https://master.d1zjxkgl40pyw5.amplifyapp.com

PS: Już wymyśliłem - wystarczy zwykła transpozycja kolumn i wierszy w odpowiedniej kolejności.

Obrót w lewo:

for (i = 0; i < this.size; i++) {
  for (j = 0; j < this.size; j++) {
    this.shape.map[i][j] = map[this.size - j - 1][i];
  }
}

Obrót w prawo:

for (i = 0; i < this.size; i++) {
  for (j = 0; j < this.size; j++) {
    this.shape.map[i][j] = map[j][this.size - i - 1];
  }
}

gdzie map[][] jest mapą figury przed transformacją.

PS: Można tworzyć własne figury i je dodawać do puli klocków - wystarczy wpisać w konsoli coś takiego, jak na przykład:

shapes.push({ map: [[1, 1, 1, 1, 0], 
                    [1, 0, 0, 0, 0], 
                    [1, 1, 1, 0, 0], 
                    [1, 0, 0, 0, 0], 
                    [1, 1, 1, 1, 1]], 
              color: 'brown' 
});

Wykresy w Angularze

Apka w Angularze aż się prosiła, aby dodać do niej wykresy. Sprawdziłyby się idealnie jako prezentacja statystyk odwiedzin. Należało więc rozejrzeć się za odpowiednim komponentem. Wybór był oczywisty - Angular Chart. W końcu nie na darmo ktoś napisał bibliotekę przeznaczoną do takich rzeczy. Pobrałem, dołączyłem do projektu, przetworzyłem dane o statystykach apki odpowiednio do wymagań komponentu, osadziłem w widoku i wyszło bardzo zgrabnie.

Paginator

Wreszcie zrobiłem paginację w Angularze. A nie było łatwo. Stworzyłem komponent "Paginator", z którego mogłyby korzystać wszystkie moduły aplikacji. Wystarczyło w nich załadować ów komponent metodą wstrzyknięcia zależności (fachowo nazywa się to "Dependency Injection"). No i działało, nie było z tym problemu. Do zainicjowania komponent potrzebował pewnych informacji - liczebności tabeli, z której pobierał wiersze, stałej wartości ilości wierszy na stronę, stałej ilości maksymalnej ilości przycisków z numeracją (po przekroczeniu której pojawia się wielokropek w środku paginatora). Tych wszystkich inicjalizacyjnych danych dostarczał serwis komponentu. Lista się wyświetlała, pod nią paginator i wszystko działało jak należy.

Ale szybko zauważyłem, że liczba wierszy na stronę nie może być jednakowa dla wszystkich modułów. Należało uzależnić ją od modułu. Wobec tego do ustawień aplikacji dołożyłem klucz w postaci obiektu JSON, w którym podaję, ile linii ma przypadać na który moduł. Inicjalizator paginatora odczytywał klucz, odnajdywał wartość dla aktualnie uruchamianego modułu i gotowe. Prosto i elegancko.

Prawdziwy jednak problem pojawił się, gdy uświadomiłem sobie, że nie wystarczy odpowiednio zainicjować paginator na początku. Podczas działania modułu trzeba jeszcze nim dynamicznie zarządzać! No bo przecież wyświetlane listy też są dynamiczne - może na nich przybywać pozycji, gdy tworzymy nowe elementy, np. strony, obrazki galerii. Może też ubywać, gdy kasujemy. Paginator musi za każdym razem uwzględniać zmieniającą się liczebność list! Ktoś powie: co za problem? Dopisać do komponentu metodę, która aktualizuje paginator. Tak, to oczywiste. Ale trzeba jeszcze zaktualizować tzw. $scope paginatora, który jest powiązany z wyświetlanymi pod listą kontrolkami. A to już nie takie proste. Ale znalazłem rozwiązanie - genialna metoda $watch, którą dostarcza framework. No i problem rozwiązany! Pozostaje tylko cieszyć się nową kontrolką.

Nowy slajder

Zwykle na swoich stronach pokazuję zrzuty ekranu gotowej aplikacji. Można to zrobić w najprostszy sposób - umieszczając obrazki na stronie. Można też użyć innej metody, pozwalającej na uzyskanie przyjemnego dla oka efektu - wykorzystać gotowy slajder, jakich jest pełno w internecie. Z kilku takich slajderów sam już korzystałem. Ale ostatnio coś mnie naszło, usiadłem do komputera i napisałem własny slajder - tak dla sportu. A może z nudów... W każdym razie wyszło coś takiego:

No i czy nie fajny? :-)

System zarządzania treścią i nie tylko...

... bo także układem strony, wyglądem i zachowaniem. Otóż mój CMS umożliwia nie tylko szybką aktualizację treści na stronach - a więc tworzenie nowych stron i ich edycję, ale również modyfikację szablonu (szkieletu strony), ostylowania (CSS), a ostatnio nawet działania (JS). A to wszystko dzięki dodaniu edytora skryptów.

Możemy z poziomu panelu administratora pisać dowolne skrypty, które już w momencie zapisania zaczynają działać. O ile nie mają błędów. :) A gdy pójdzie coś nie tak, zawsze można przywrócić skrypty "fabryczne".

URL: http://swoja-strona.eu

Gra jako podstrona serwisu

A dlaczego nie?! Co się będziemy ograniczać! Tak więc jedną z podstron mojego najnowszego CMS-a jest gra zręcznościowa "Snake". Wystarczy wejść i można od razu grać. Grę można obsługiwać zarówno myszką (dotykowo na tabletach), jak i klawiaturą (na stacjonarnych kompach).

Pomysł był taki, aby przepisać grę, którą kiedyś napisałem w wersji desktopowej (na Windows), na wersję webową, tak aby nie trzeba jej było do uruchomienia ściągać. Ale w praktyce napisałem ją od nowa - tak było łatwiej. I przyjemniej!

Gra jest dostępna pod adresem: http://angular-cms.pl/page/13

Projekt Angular

Przyszedł czas na zaprzyjaźnienie się z front-endem. Dotychczas cały wysiłek wkładałem w backend, bo tam leżała cała logika aplikacji. Niezależnie, w jakim języku apka została napisana - czy to PHP, czy Python, czy Java. To serwer obsługiwał żądania użytkownika i generował widok. Tworzenie przyjemnych dla oka efektów wizualnych na stronie nie było możliwe za pomocą backendu. Mając na uwadze to ograniczenie, postanowiłem przyjrzeć się bliżej "drugiej stronie medalu", czyli front-endowi. Zacząłem bawić się Javascriptem, potem wziąłem na warsztat jQuery, który w połączeniu z AJAX-em i JSON-em bardzo mnie zachwycił swoją prostotą, a jednocześnie potęgą działania. Zrobiłem mały projekt, który wykorzystuje wspomniane technologie. Wyszło całkiem zgrabnie.

Ale wciąż nie dawał mi spokoju pewien zamysł, który chodził za mną od kilku lat. Chciałem zrobić apkę webową, która by działała podobnie jak apka desktopowa. To znaczy taką apkę, która miałaby jeden niezmienny szablon, a w nim pojawiałyby się dynamicznie różne, zależne od kontekstu, dane. W praktyce oznacza to brak przeładowywania całej strony przy zmianie kontekstu. Na przykład, gdy chcemy wyświetlić inną podstronę, nie odbywa się wczytywanie jej od nowa, a jedynie następuje podmiana danych w stale wyświetlanym szablonie. Takie zachowanie jest cechą tzw. Single Page Applications, czyli aplikacji jednostronnych.

Aby taką aplikację napisać, wystarczy HTML, Javascript i źródło danych (baza danych na serwerze, plik na dysku itp.). Można to zrobić ręcznie, ale wymaga to mnóstwa wysiłku. I tu z pomocą przychodzą przeznaczone do tego frontendowe frameworki. Ja wybrałem AngularJS, bo mi najbardziej odpowiada. Dzięki niemu można szybko i sprawnie napisać aplikację webową tego typu. Chcąc więc poznać Angulara, poczytałem trochę teorii, liznąłem trochę dokumentacji i zacząłem pisać swoją apkę.

Ponieważ chciałem w niej mieć system zarządzania oparty na autoryzacji, czy jak kto woli autentykacji, musiałem rozwiązać problem przydzielania dostępu - i to zarówno w części frontendowej, jak i backendowej. Autoryzacja po stronie serwera jest konieczna, ponieważ logikę autoryzacji po stronie klienta można podejrzeć i złamać (po stronie serwera nie jest już tak łatwo). Tak więc, mając zrobioną podwójną autoryzację, mogłem wykonać system zarządzania stroną. W efekcie powstał projekt Angular CMS, prosty CMS, którego teraz będę wypełniał treścią.

ORM na Javie

Skoro aplikacja pracuje na bazie danych, logiczne wydawało się zaimplementowanie w niej ORM-a (mapowania obiektowo-relacyjnego). A cóż to za diabeł?! Jest to po prostu zbiór klas zawierających pola, które są ściśle odwzorowane na kolumny odpowiednich tabel w bazie. Czyli każda tabela w bazie posiada swój odpowiednik w postaci klasy. Jak to wygląda, opisałem w artykule ORM - mapowanie obiektowo-relacyjne.

Apka na Javie ruszyła

Postanowiłem nauczyć się Javy. Ponieważ najbardziej leży mi Web, wziąłem na warsztat Java EE. Poszukałem sobie darmowej platformy hostingowej dla aplikacji javowych. Znalazłem taką - OpenShift. Założyłem konto, zacząłem instalować proste, szkoleniowe apki, aby potestować różne zagadnienia. A więc: jak działają serwlety, jak wygląda obsługa formularzy, jak łączyć się z bazą. Jak już podstawy miałem opanowane, rozpocząłem projekt CMS-a w Javie. I po dwóch miesiącach intensywnej pracy powstała niezła apka, którą można obejrzeć na żywo: http://cms-jfrmwrk.rhcloud.com. Zapraszam do obejrzenia!

FineCMS - dodać edytor czy nie?

W trakcie pisania frameworka miałem poważne wątpliwości, czy powinien on umożliwiać edycję szablonów i arkuszy stylów strony wprost z panelu admina. Są to przecież kluczowe, a nawet krytyczne elementy strony, które w razie błędnej edycji mogą popsuć cały jej układ. Jednak z drugiej strony bezpośrednia edycja szablonu oraz arkusza stylu staje się tak potężnym narzędziem w rękach administratora, że aż żal byłoby z czegoś takiego rezygnować. Po dłuższym wahaniu zdecydowałem, że edytor szablonu i stylu musi się pojawić. W końcu dostęp do niego ma jedynie administrator, a jest on (przynajmniej powinien być) osobą świadomą tego, co robi. W efekcie w panelu admina widzimy dwie nowe ikonki: "Szablon" oraz "Styl".

Już po pierwszych testach dołączonego edytora stwierdzam, że dzięki nowym funkcjom elastyczność systemu ogromnie wzrosła. Dosłownie można się bawić w przebudowywanie układu i wyglądu. Tak więc była to doskonała decyzja, "jedyna słuszna koncepcja". :)

Strona projektu: FineCMS

Nowy projekt - FineCMS

Tym razem napisałem od nowa frameworka MVC. Zupełnie inna architektura, całkowicie odmienione i poprawione front controller, dispatcher, router. Kod jest bardziej spójny, elegancki, łatwiejszy w zarządzaniu. Na tym frameworku postawiłem nowego CMS-a. Użyłem tu Twitter Bootstrapa do widoku oraz PDO do modelu. Poprawiłem też paginację list. Dzięki nowej architekturze udało się uprościć instalator aplikacji.

Początek był trudny. Zanim ukształtowała się obecna postać frameworka, wiele razy podchodziłem do stworzenia właściwej architektury. Gdy zaprojektowana struktura nie była do końca spójna, odbiegała choć w jednym miejscu od ustalonego standardu, albo było w niej coś, co mi się nie podobało, wtedy usuwałem dane rozwiązanie i wracałem do punktu wyjścia, próbując stworzyć rozwiązanie w inny sposób, dopóki nie powstało coś, do czego nie miałem zastrzeżeń, co było zgrabne i eleganckie. Takie podejście stosowałem wielokrotnie w trakcie całego projektu. Jednak najwięcej takich nieudanych prób było na początku, zanim nie wyłonił się ogólny schemat, którego trzeba było się potem trzymać. Wówczas kolejne rozwiązania przychodziły same, bo wynikały z istniejącej już architektury. Gdy framework stał się kompletny, można było osadzić na nim CMS-a. Tak też zrobiłem i w obecnej postaci CMS ma wszystkie podstawowe funkcjonalności. Jego rozbudowa o kolejne jest ułatwiona dzięki ustalonemu standardowi, którego wystarczy się trzymać - prowadzi on za rękę podczas tworzenia nowych funkcji.

Strona projektu: FineCMS. Zapraszam do obejrzenia.

CMS - mechanizm kontroli dostepu Access Control List (ACL)

Własny framework

Postanowiłem napisać własnego frameworka PHP. Zgodnie ze wzorcem projektowym MVC (Model-View-Controller). Czyli szablon aplikacji 3-warstwowej.

Moim założeniem było stworzenie jak najcieńszego frameworka, na którym można postawić stronę www. Jak najcieńszego, ale zarazem mającego walidację formularzy (wypełnienie pól, poprawność e-maila, pesela, ochrona przed SQL injection), a także generatory list, formularzy i widoków.

Dlaczego własny, a nie gotowy, np. Zend, Symfony, Code Igniter, Yii, Cake PHP, Kohana itd.? Bo wolę samemu tworzyć strukturę klas i obiektów, hierarchię i całą architekturę, czy wreszcie własny routing, niż wgryzać się od zera w nową technologię. Co prawda trochę pobawiłem się Code Igniterem czy Yii, i nawet zrobiły na mnie miłe wrażenie, ale gdy pomyślałem sobie, że obsługa złożonych zapytań do bazy miałaby się odbywać według przygotowanych schematów frameworka, zdecydowałem, że zrobię coś własnego, gdzie będę dokładnie wiedział, co i jak się odbywa. Ano, zobaczymy, co z tego wyjdzie...

Na razie rozwijam i testuję projekt na localhoście - używam WAMP-a, gdyż bardziej mi odpowiada niż XAMP - ale gdy framework będzie kompletny, udostępnię go na jednej z moich stron.

A tymczasem zachęcam do odwiedzenia mojej bieżącej strony: http://mvc.net.pl.

Wstęp

Witam wszystkich na moim blogu! Blog ten poświęcam zagadnieniom tworzenia stron internetowych. Początkowo robiłem strony statyczne w html-u. Obecnie tworzę strony dynamiczne w oparciu o PHP i MySQL. Stało się to moją pasją i mam na tym polu pewne osiągnięcia, którymi chciałbym się z Wami podzielić.

Zapraszam na moją stronę: http://swoja-strona.eu.