Zminimalizuj swój CMS i uważaj na błędy

poniedziałek, 2020-03-091046Alib CyMeS, Internet, Programowanie

Jestem zwolennikiem minimalizmu. Jeśli coś da się zrobić w prostszy i bardziej zwięzły sposób, to stracę masę czasu, żeby to zrobić. Na krótką metę jest to może mało ekonomiczne, ale na dłuższą mam z tego wiele korzyści. I frajdy.

Grafika pochodzi z Adobe Stock

Mój Alib CyMeS składa się tylko z 7 tablic. Przy czym na bieżąco używam tylko czterech, pozostałe przydają się w specyficznych przypadkach. Ale tak naprawdę liczy się tylko jedna, zawierająca wszystkie dane serwisu - strony, newsy, menu, linki, galerie itp. Pozwoliło mi to nieźle zoptymalizować główną klasę obsługi systemu, bo wszystkie metody odnoszą się do tej jednej tablicy, a różnią się głównie dalszą obróbką odczytanych danych.

Przykład mojej tablicy

Jeśli myślisz o zrobieniu własnego Systemu Zarządzania Treścią, a nie bardzo wiesz, jak się za to zabrać, poniższy opis może pomóc Ci w zaprojektowaniu systemu. Możliwe, że opracujesz jeszcze lepsze rozwiązanie.

ID - unikalny identyfikator (indeks) rekordu. Wszystkie tablice go mają, bo bardzo przyspiesza pracę przy tworzeniu zależności między rekordami.
IDPARENT - identyfikator rekordu nadrzędnego (rodzica). W większości przypadków zachodzi bardzo proste powiązanie rodzic-dzieci. Buduję w ten sposób drzewiastą strukturę danego typu rekordów np. pozycji menu, albumów i zdjęć w galerii, folderów na pliki itp. W przypadku powiązań wielokrotnych (np. tagi do wpisów czy kategorie) używam dodatkowej tablicy wiążącej indeksy rekordów różnych typów. Jednak większość serwisów, które programuję, tego nie wymaga.
TYP - typ rekordu. Bardzo ważna zmienna, bo od niej zależy czy dany rekord jest stroną, newsem, linkiem, plikiem, zdjęciem w galerii czy pozycją menu. Można dodawać własne typy i rozbudowywać system wciąż korzystając z jednej tablicy danych.
STATUS - status rekordu. Standardowo używam 3: roboczy (ukryty), opublikowany (widoczny), oczekujący na akceptację. W przypadku newsów dodałem zaplanowany do publikacji, a jego obsługą zajmuje się CRON.
IDUSER - ID użytkownika tworzącego dany rekord. Większość serwisów ma jednego użytkownika, ale popełniłem kilka, gdzie obsługą i publikacją treści zajmuje się kilka osób i wtedy to już zaczyna mieć znaczenie.
DATE - data i czas utworzenia (edycji) rekordu. W przypadku newsów (wpisów blogowych) pozwala to na sortowanie od najnowszego do najstarszego wpisu.
TEMP - początkowo była to tylko nazwa szablonu dla stron (jak w WordPressie). Ale dla innych typów pozostawała niewykorzystana, więc obecnie przechowuję tu nazwy plików np. dla managera plików, galerii czy grafik nagłówkowych dla newsów i spisów blogowych. Dlatego nazwa jest może mało intuicyjna, ale nie chce mi się jej zmieniać.
NAME - nazwa rekordu, może to być tytuł podstrony, newsa, pliku w galerii itp.
URL - przyjazny adres strony albo docelowy adres w linkowni. W prosty sposób ogarnąłem unikalność tej nazwy. Podczas dodawania system sprawdza, czy dany URL jest już w bazie (bez względu na typ) i jeśli jest to dodaje do niej ID rekordu np. zminimalizuj_swoj_cms_i_uwazaj_na_bledy.html.
VALUE, EXTRA, CONTENT - zwykłe zmienne tekstowe, które zawierają różne treści i dodatkowe dane w zależności od typu danych. Pojawiały się w systemie sukcesywnie i mały różne przeznaczenia, stąd różne nazwy. Teraz pewnie nazwałbym je VALUE1, VALUE2 i VALUE3, ale podobnie jak w przypadku TEMP, nie chce mi się już tego zmieniać. Najczęściej VALUE zawiera krótkie testy np. zajawki wpisów blogowych, w CONTENT jest pełna treść (jak wskazuje nazwa), w EXTRA różne dodatkowe treści jeśli są dla danego rekordu potrzebne. Jeśli potrzebuję przechować więcej informacji, to po prostu wrzucam tu serializowaną tablicę.

Ta jedna tablica wystarczy, żeby utworzyć większość typów danych: menu, strony, newsy, kategorie newsów, linki, pliki, galeria, tagi, komentarze, newsletter. Wystarczy nawet do obsługi prostego sklepu: kategorie, asortyment, zdjęcia, klienci, zamówienia. A wszystko to mogę obsłużyć nieznacznie tylko rozbudowując główną klasę, która zwiera wszystkie potrzebne do tego mechanizmy. Często nawet nie trzeba pisać nowej klasy, tylko przekazać odpowiednie parametry do istniejących metod.

Nie ustrzeżesz się błędów nawet przy jednej tablicy

Oopsik

Grafika pochodzi z Adobe Stock

Nie odkryję Ameryki stwierdzeniem, że nie ma programu w 100% bezbłędnych. No chyba, że jest to prosty kalkulator albo wyświetlenie napisu „Hello World” :)

Oczywistością jest też, że im bardziej skomplikowany program, tym więcej błędów. Spójrzcie na częstość aktualizacji Windowsa i ile z nich jest poprawkami krytycznymi, zwłaszcza w zabezpieczeniach. Z Linuxem czy macOS jest trochę lepiej, ale od jakiegoś czasu twórcy IOS też mocno przeginają z wydawaniem aktualizacji, bo ciągle coś się sypie. Aktualizacje większych pakietów oprogramowania (np. Adobe) też częściej łatają błędy niż dodają nowe funkcje. A i tak bywa, że te łaty generują problemy w innych miejscach.

Na moim Atari 65XE nic nigdy się nie zwiesiło
Zatweetuj

Z sentymentem powracam myślami do dawnych czasów, z 8-bitowymi komputerami. Na moim Atari 65XE nic nigdy się nie zwiesiło, a sporadyczne błędy w grach wynikały z błędnego wczytania ich ze zjechanej taśmy. Chociaż... Kilka naprawdę rozbudowanych gier miało bugi (np. „Spy Master”) to potwierdza regułę, że bardziej skomplikowany program ma więcej błędów. A „Spy Master” podobno aż do bólu wypełniała całą pamięć Atarynki.

Wtedy nie było tak łatwo jak teraz, że łatka automatycznie pobierała się z netu i aktualizowała. Trzeba było pójść do sklepu z dyskietką lub kasetą i wymienić na nową grę. Niektórzy robili problemy, że brak paragonu, że otwarte pudełko, że coś-tam... Hmmm... Może jednak teraz jest lepiej :)

Kiedyś Alib CyMeS też nie miał błędów

Nie jestem zawodowym programistą, ale nieskromnie mogę stwierdzić, że pierwsze wersje mojego Alib CyMeS też nie miały błędów, co najwyżej nieco problemów w kwestii wyświetlania sprawiał Internet Explorer, ale z nim zawsze tak było. Potem zacząłem rozwijać CMS i... się zaczęło. Dochodziły nowe funkcjonalności, trzeba było zrobić kontrolę danych, zabezpieczenia przez włamaniami. Czasami paradoksalnie to zabezpieczenie powodowało błąd, bo zbyt nadgorliwie filtrowało dane. Teraz osiągnąłem już ten etap, że nie rozbudowuję głównego silnika i od kilku lat (odpukać) poważniejszych problemów nie miałem. Te drobne nie mają wpływu na stabilność działania systemu i objawiają się w bardzo specyficznych warunkach, do których chyba tylko ja doprowadzam :)

Już uszami duszy słyszę hejterskie głosy, że powinienem skasować i zapomnieć o własnym CMS-ie, skoro to taki gówno i powinienem przesiąść się na coś, co ma dużą społeczność, bo społeczność jest gwarancją szybszego znalezienia błędu czy innej dziury. No właśnie, czyli każdy system ma dziury, a im większy tym więcej. W końcu każdy ma prawo do popełniania błędów. Z tym po prostu musimy żyć...