Stosunkowo często możemy spotkać się z sytuacją, w której aplikacja działająca przez sieć udostępnia w sobie wbudowany serwer WWW nadający na określonym porcie. Problem rozpoczyna się w sytuacji, gdy jest to nasza jedyna opcja, a mimo to chcielibyśmy mieć jakiś bardziej przyjazny adres w postaci np. subdomeny.

Dziś na szybko zademonstruję konfigurację hosta w serwerze nginx właśnie tak, aby przechwytywał on ruch występujący na określonym porcie - w tym wypadku na przykładzie Gitea (społecznościowego forku Gogs, lekkiego serwisu w stylu GitHub do samodzielnego hostowania). Wystarczy nam wiedzieć, że domyślnie jest on dostępny na porcie 3000, a naszym celem jest subdomena git (na potrzeby wpisu załóżmy że będzie to git.sobak.pl). W celu przekierowania ruchu wykorzystamy jedno z powszechnych zastosowań serwera nginx, znane jako reverse proxy.

server {
	listen 80;

	server_name git.sobak.pl;

	location / {
		proxy_pass http://localhost:3000;
	}
}

Tak, tylko tyle i aż tyle. W wypadku gdy korzystamy z HTTPS, zmieniamy drugą linijkę na listen 443, czyli odpowiedni dla tego rodzaju komunikacji port. Podany plik prawdopodobnie będziecie musieli zapisać w lokalizacji /etc/nginx/sites-available/git.sobak.pl i zsymlinkować z sites-enabled, czyli tak jak dla każdego innego hosta w nginxie. Pamiętajcie o zmianie przykładowych wartości subdomeny i portu - pamiętajcie że to rozwiązanie absolutnie nie ogranicza się do tej jednej aplikacji lecz stanowi ogólny schemat postępowania.

Powyższy wpis jest realizacją wymogów konkursu "Daj Się Poznać". Więcej o nim możecie przeczytać w tym wpisie. Po nowe materiały poświęcone tworzeniu projektu Codice, z którym startuję w konkursie, zapraszam w każdy wtorek. Ponadto więcej wpisów, poświęconych temu projektowi lub ogólnej tematyce bloga przeczytacie co sobotę. Miejmy nadzieję że publikacja dwóch wpisów w niedzielę jest tylko niewinnym wypadkiem przy pracy ;)

Dzisiejszy wpis będzie skierowany do osób zaczynających swoją przygodę z systemami kontroli wersji (VCS). Mimo że porady będą bazowane na systemie git, większość z nich można z powodzeniem zastosować także dla jego alternatyw.

Rozmiar commitu

Jest to rzecz, z którą - według moich obserwacji - początkujący mają największy problem. Nie istnieje bowiem idealna ilość zmian w jednym commicie, którą możemy się kierować za każdym razem. Myślę, że commit o dobrym rozmiarze najprościej jest zdefiniować słowem samodzielny. Co takiego mam przez to na myśli?

• zmiany w commicie powinny stanowić działąjącą całość, nie powinno się commitować kodu, który generuje na przykład błąd parsera
• commit powinien obejmować jedną funkcjonalność. Ponownie, nie da rady zdefiniować jak dużo obejmuje jedna "funkcjonalność". Spróbuj jednak postąpić w ten sposób - wyobraź sobie, że commit, który masz zaraz wyślesz, będzie musiał zostać cofnięty (np. komendą git revert). Czy robiąc to, pozbędziesz się tylko jednego kroku, czy też będziesz musiał w osobnym commicie powtórzyć część z dokonanych wcześniej zmian (które właśnie hipotetycznie cofnąłeś). Jeżeli zachodzi druga sytuacja, to commit jest za duży.

Opis commitu

Bądźmy szczerzy, każdy lubi czasem popuścić wodze fantacji wpisując wiadomość commitu. Najczęściej jest to danie upustu frustracji, która towarzyszyła tworzeniu danego kodu. Powstały nawet specjalne strony jak whatthecommit.com. Warto jednak poświęcić kilka sekund więcej na napisanie wiadomości commitu, aby w przyszłości zaoszczędzić swój czas.

Opis commitu jest wykorzystywany w bardzo wielu sytuacjach - komendach git log, git rebase, git blame, czy ich odpowiednikach w serwisach typu GitHub. Traktuj opis commitu tak, jakbyś musiał go przeczytać i szybko zrozumieć kilka dni później. Staraj się być zwięzłym i rzeczowym - jeżeli nie ze względu na siebie, to na współpracowników.

Kolejną sprawą jest możliwość podzielenia commitu na krótki opis główny i dłuższą (opcjonalną!), bardziej szczegółową część, która nie jest pokazywana w niektórych sytuacjach. Wspiera to oryginalny klient gita (np. komenda git log --abbrev-commit) i np. GitHub (w widoku listy commitów pokazywana jest tylko krótka wiadomość, a reszta rozwija się po kliknięciu). Git oddziela streszczony opis commitu od jego pełnej treści za pomocą jednej pustej linii.

Oto skrótowy, kontretny opis Twojego commitu

Tutaj możesz zawrzeć długi opis, w którym przykładowo omówisz przyczyny
wprowadzenia danej zmiany i jej konsekwencje dla projektu. Może być to
przydatne szczególnie dla Twoich współpracowników.

Na koniec kilka dodatkowych (częściowo subiektywnych, lecz popartych obserwacjami) zaleceń dotyczących formy samej wiadomości:

• żadna z linii w opisie commita nie powinna przekraczać 72 znaków (konsola ma domyślnie 80 znaków szerokości)
• rozpocznij opis od wielkiej litery
• na końcu pierwszej linii commitu nie stawiaj kropki
• użyj trybu rozkazującego (zwłaszcza w języku angielskim; powód - git używa takiego samego trybu dla wiadomości generowanych przez siebie, na przykład "Merge a from remote b")

Weryfikacja commitu

Przed zatwierdzeniem dowolnego commitu, przejrzyj go - najlepiej dwa razy. Służy do tego oczywiście diff, czyli wykaz wszystkich zmian poczynionych w ramach danego commmitu. Generalnie do jego wyświetlenia służy komenda git diff (trudne, prawda?), ale oczywiście jest haczyk. Domyślnie nie pokazuje ona zawartości plików właśnie dodanych do repozytorium, a jedynie zmiany w przestrzeni roboczej (przed wykonaniem git add).

Metodą uniwersalną jest wydanie komendy git add . (lub git add . --all dla gita 1.x - wszystko, aby uwzględnić też pliki właśnie usuwane z repozytorium) a następnie git diff --cached. Po tych dwóch poleceniach dostaniemy pełną listę zmian, zarówno w dodawanych, zmienianych, jak i usuwanych plikach - pozwala to zaoszczędzić naprawdę wielu pomyłek w kodzie.

Łączenie (squashowanie) commitów

Łączenie kilku commitów w jeden, zwłaszcza po ich wysłaniu do zdalnego repozytorium (remote), zaburza poniekąd historię zmian i może prowadzić do tego, że system kontroli wersji nie będzie spełniał swojej roli. Zachodzą jednak sytuacje, w których może być to przydatne, a nawet wymagane przez innych developerów. Najczęściej dzieje się tak w wypadku Pull Requestów lub ich odpowiedników z serwisów innych niż GitHub.

Powodem, dla którego w tej sytuacji możemy użyć squashowania (dosł. zgniatania) commitów jest zachodzący workflow. Zmiany są wykonywane w obrębie naszego własnego repozytorium (forka) i wysyłane jako propozycja zmian dla jakiegoś projektu. Bardzo często ludzie zarządzający tym projektem będą mieli do nas pewne uwagi i wskazówki, w związku z czym do Pull Requesta dołączają kolejne commity. Warto je na końcu połączyć, bo Pull Request z założenia powinien obejmować jedną funkcjonalność, a więc często być też jednym commitem (jak pisałem na początku artykułu). Kilka różnych metod squashowania commitów znajdziecie w tym wątku na SO.

Zakończenie

Mimo, że opisałem tutaj całkiem sporo założeń i może się wydawać, że teraz wysłanie dobrego commita miałoby zajmować wieczność i oznaczać sprawdzanie każdego punktu z listy, to nie ma czym się przejmować. Większość z wniosków wyciągniętych w artykule jest bardzo logiczna i nie powinna być dla Was niczym nowym, a reszta szybko wejdzie w nawyk. Należy brać poprawkę na dozę subiektywizmu zawartą w tym tekście.

Często zachodzi potrzeba sprawdzenia tego, jak wygląda czas generowania naszej strony lub ile generuje ona zapytań do bazy danych. Pomijając tutaj użycie profilerów (choćby ze względu na brak dostępności na większości hostingów) pokażę jak uzyskać takie informacje w skrypcie Wordpress.

Pobieranie ilości zapytań
Aby uzyskać ilość zapytań wykonanych do bazy przez Wordpressa należy skorzystać z funkcji get_num_queries() - zwraca ona liczbę tylko liczbę wykonanych zapytań. Przykład użycia pokażę na końcu wpisu.

Pobieranie listy zapytań
Pobranie samej treści wykonanych zapytań jest już lekko trudniejsze. Należy zacząć od zdefiniowania jednej stałej w pliku wp-config.php. Gdzieś w nim (można to zrobić np. po stałej WP_DEBUG) należy umieścić następujący zapis.

define('SAVEQUERIES', true);

W tym momencie Wordpress zacznie logować informacje na temat wszystkich wykonanych przez siebie zapytań. Aby je wyświetlić możemy użyć kodu oferowanego przez oficjalną dokumentację WP:

<?php
if (current_user_can('administrator')){
  global $wpdb;
  echo "<pre>";
  print_r($wpdb->queries);
  echo "</pre>";
}
?>

Zasada działania jest prosta: jeżeli dany użytkownik ma uprawnienia administratora, to pokaże się dump tablicy wielowymiarowej zawierającej informację o zapytaniu. Na każde zapytanie składają się trzy klucze. Pierwszy określa treść zapytania, drugi: czas jego wykonania, a trzeci mówi o tym jak po kolei wyglądała droga do wykonania tego zapytania (dołączane pliki i wywoływane funkcji).

Jeżeli jednak, tak jak ja, nie potrzebujecie aż tak szczegółowych informacji o każdym zapytaniu, możecie użyć takiego kodu:

<?php
global $wpdb;
foreach ($wpdb->queries as $query) 
  echo $query[0]."\n";
?>

Ten kod pokazuje jedynie treść wykonanych zapytań. Uwaga: ja używam tego kodu do wsadzenia tej informacji w HTML-owy komentarz. Jeżeli chcecie wyświetlić to na stronie, to pamiętajcie o zamianie nowej linii na br. Oczywiście można dodać sprawdzanie uprawień użytkownika, aby takie informacje udostępnić tylko dla administratorów (to wskazane posunięcie!).

Pobieranie czasu generowania strony
Do pobrania czasu generowania strony opartej na WP służy funkcja timer_stop(). Przyjmuje ona dwa parametry, pierwszy określa czy wartość ma być wyświetlona (1), czy zwrócona (0; ustawienie domyślne). Drugi określa zaś precyzję, czyli ilość cyfr po przecinku w czasie generowania (domyślnie 3). Przykład użycia za chwilkę.

Sprawdzanie ilości użytej pamięci
Tutaj skorzystamy już z wbudowanej w PHP funkcji memory_get_usage(). Zwraca ona wynik w bajtach, tak więc dla lepszej czytelności zatroszczymy się o przeliczenie na megabajty.

<?php echo number_format(memory_get_usage()/1024/1024, 2); ?>

Drugi parametr funkcji number_format() także określa liczbę miejsc po przecinku.

Kompletny przykład
Oto przykładowa implementacja powyżej pokazanych rozwiązań.

<!--
Zapytania: <?php echo get_num_queries();
global $wpdb;
foreach ($wpdb->queries as $query) 
  echo $query[0]."\n";  ?>
Czas generowania: <?php timer_stop(1, 2); ?>s
Użyta pamięć: <?php  echo number_format(memory_get_usage()/1024/1024, 2); ?>MB
-->

I to by było na tyle. Mam nadzieję, że przedstawione rozwiązanie do czegoś się Wam przydało. Pamiętajcie też, że po skończonym debugu lepiej jest usunąć stałą SAVEQUERIES z konfiguracji lub przestawić ją na false, gdyż włączenie opcji logowania zapytań zwiększa zużycie zasobów.

Problem stary jak świat. Po odpaleniu aplikacji (często na innym serwerze) wyskakuje szereg komunikatów typu notice (podkreślmy od razu bardzo ważną rzecz: notice to nie błąd). W tym wypadku przedstawiane są dwie szkoły: jedna mówi, że aplikacja nie powinna generować żadnych komunikatów, a druga uznaje, że skoro notice błędem nie jest, to może wystąpić, bo to tylko informacja dla programisty. Niezależnie od tego, którą z nich wyznajemy, ukrycie notice (jak i  błędów) jest konieczne w środowisku produkcyjnym, ze względów bezpieczeństwa.

Wykonanie tego zadania sprowadza się do dodania jednej linijki gdzieś na początku pliku PHP.

<?php
error_reporting(E_ALL ^ E_NOTICE);

To sposób jednorazowy/doraźny. Jeżeli chcemy załatwić sprawę na stałe i mamy taką możliwość to po prostu edytujemy plik php.ini i tak jak wyżej zmieniamy wartość dyrektywy error_reporting na E_ALL ^ E_NOTICE.

PS: Wiem, ze problem jest oklepany, ale będzie gdzie odsyłać kolejnych ludzi mówiących o "błędach notice".

Sobak, jako wybitny specjalista w dziedzinach accessability, usability i innych –ity ma dla Was najnowszą super-wypasioną poradę przydatną w dzisiejszych czasach. Będzie ona dotyczyć… cookies. Małych, niewinnych ciasteczek, które od maja tego roku zostały skazane na bycie piętnowanymi przez Unię Europejską miłościwie nam panującą.

Mam ja krótkie pytanie: dlaczego prawie nikt nie umieścił komunikatu o cookies na dole strony bez fixed? Najczęściej widuję strony, które taki komunikat mają przyczepiony na górze. Dosyć rzadko dzieje się tak, że po przewinięciu w dół komunikat zostaje na górze (czyli po prostu nie ma fixed). Wiele stron zdecydowało się umieścić taki komunikat na dole, jednak w takim rozwiązaniu mamy permanentnie ucięte kilkanaście pixeli z dołu strony.

Natomiast zestaw, do którego chciałbym Was przekonać, czyli informacja umieszczona na dole strony i nie przylepiona do dołu ekranu na fixed, mimo że zdaje mi się najlepszy, widziałem raptem na kilku stronach WWW (choćby Google/Youtube czy Forumweb). Dlaczego takie rozwiązanie jest wg mnie najlepszym wyjściem? Przede wszystkim nie zabieramy na stałe przestrzeni z ekranu. Komunikaty z fixed rezerwują sobie nieraz wiele przestrzeni i dopóki użytkownik ich nie zamknie będą wędrować z nami podczas czytania strony. Komunikat umieszczony na dole może być przeczytany przez użytkownika po zobaczeniu tego, po co przyszedł na stronę. To przecież nie informacja o ciasteczkach jest dla niego najważniejsza.

Dlaczego więc webmasterzy tak bardzo upodobali sobie inne formy? Zwięzłą i bardzo ciekawą analizę przedstawił logeen na Forumweb.pl. W skrócie: jako pierwsze komunikat o cookies wprowadziły witryny rządowe. Webmasterzy, a raczej ich zleceniodawcy pod natłokiem całego szumu jaki wywołała zmiana prawa uznali strony rządowe za dobry wzorzec i gwarancję zgodności ze znowelizowaną ustawą ("to nie może być złe bo tak robi strona prezydenta/premiera etc").

Tymczasem przedstawione przeze mnie rozwiązane w żaden sposób nie narusza ustawy Prawo Telekomunikacyjne. Ustawa o samym komunikacie mówi jedynie, że ma być on jednoznaczny, bezpośredni i zrozumiały dla użytkownika.

abonent lub użytkownik końcowy zostanie uprzednio jednoznacznie i bezpośrednio poinformowany, w sposób łatwy i zrozumiały

W związku z tym porada na dziś będzie taka: nie marnujcie miejsca na monitorach Waszych czytelników, nie marnujcie ich uwagi na czytanie tego samego komunikatu po raz kolejny. Odpowiednia wzmianka w stopce spokojnie wystarczy.

Tematem dzisiejszej krótkiej porady będzie Minecraft - popularna gra sandboksowa. Pokażę, jak w prosty sposób można wyłączyć wszelki griefing wykonywany przez moby. Wlicza się w to:

• niszczenie bloków poprzez eksplozje creeperów, ghastów i witherów
• podnoszenie bloków przez endermany
• wyłamywnanie drzwi przez zombie

Swego czasu stworzyłem plugin MobsControl, który realizował powyższe zadania, ale od Minecrafta w wersji 1.4.2 wyłączenie powyższych zachowań jest możliwe przez wykonanie jednej komendy.

Multiplayer
Wykonanie komendy wymaga uprawnień operatora. Z konsoli serwera lub wykonaj następującą komendę:

/gamerule mobGriefing false

Singleplayer
Wykonanie tej czynności w trybie singleplayer wymaga włączenia cheats (oszustw) przy tworzeniu świata. Inaczej nie będzie możliwe wykonanie komendy. Komenda tak jak powyżej:

/gamerule mobGriefing false

Uwagi na koniec
Rozróżniana jest wielkość znaków! Jeśli chcemy przywrócić ustawienia domyślne to po prostu zmieniamy false na true i wykonujemy komendę raz jeszcze.

Witajcie po bardzo długiej przerwie. W wyniku kilku spraw nie mogłem znaleźć weny i czasu na naskrobanie czegoś na bloga. Nadszedł czas troszkę to nadrobić - zacznę, mam nadzieję, konkretnie.

Dziś na warsztat pójdzie sprawdzanie typu pliku na podstawie jego MIME. Jak dobrze wiadomo, sprawdzanie po rozszerzeniu jest niepewną i ryzykowną formą - rozszerzenie można zmienić, a nieraz (wskutek takiej czy innej konfiguracji serwera) można wykonać plik zamaskowany rozszerzeniem .jpg jako normalny plik PHP. Potencjalnych skutków chyba nie trzeba opisywać ;) Przechodząc do rzeczy:

1) Korzystając z klasy Fileinfo
To rozszerzenie PHP powstało właśnie do tego celu i jest aktualnie najlepszą metodą na osiągnięcie naszego celu. Poniżej krótki i treściwy przykład działania klasy.

<?php 
$file1 = 'image.png'; // Faktyczny obrazek w PNG
$file2 = 'kod.png'; // Plik PHP ze zmienionym rozszerzeniem

$finfo = new finfo(FILEINFO_MIME);

echo $finfo->file($file1, FILEINFO_MIME_TYPE); // Wyświetli: image/png
echo $finfo->file($file2, FILEINFO_MIME_TYPE); // Wyświetli: text/x-php

W tym miejscu już doskonale widać przewagę tego rozwiązania nad sprawdzaniem rozszerzenia pliku - oszust został zdemaskowany.

2)  Poprzez funkcję mime_content_type
Uwaga, ten sposób jest gorszy! Wspomniana funkcja została zdeprecjonowana, więc nie powinno się jej używać. Jednakże dosyć często zachodzi sytuacja, w której na serwerze nie jest dostępna pierwsza metoda (klasa fileinfo), a możemy użyć owej funkcji - dlatego o niej wspominam.

<?php
echo mime_content_type('php.gif'); // Wyświetli: image/gif

3) Sprawdzanie typu pliku po jego zawartości Każdy typ pliku zawiera na swoim początku zestaw charakterystycznych dla niego kilku bajtów. Sprawdzając je, możemy określić typ pliku - należy jednak wspomnieć, że to właśnie z tej metody korzystają powyższe rozwiązania, więc zabawę z ręczną jej implementacją możemy rozpocząć gdy jesteśmy zdesperowani i nie mamy żadnej z powyższych możliwości.

Poniżej krótki przykład, pobranie trzech pierwszych bajtów pliku, skonwertowanie ich do postaci heksadecymalnej i porównanie ich z bajtami charakterystycznymi dla pliku MP3

<?php
$file = fopen('plik.mp3', 'r');
$bytes = bin2hex(fread($file, 3));

if($bytes == '494433') {
    // Sprawdzany plik jest plkiem MP3
}
else {
    // Inny plik
}

fclose($file);

Dużą listę takich charakterystycznych bajtów możecie znaleźć tutaj, można też skorzystać z serwisu FileExt.com.

Mam nadzieję, że komuś przydał się ten wpis. Dziękuję za uwagę :)

Dzisiaj przedstawię prostą funkcję do walidacji numeru PESEL w PHP. Przyjmowany argument i zwracana wartość nie powinny być niespodzianką - bierzemy numer PESEL, a dostajemy wartość logiczną (prawda/fałsz).

Aby sprawdzić poprawność numeru PESEL, należy obliczyć jego tak zwaną cyfrę kontrolną. Jest to ostatnia cyfra numeru PESEL, obliczana na podstawie jego wcześniejszych cyfr i sprawdzana na podstawie wzoru (zakładamy, że a - j to kolejne cyfry PESEL-u licząc od lewej):

a+3b+7c+9d+e+3f+7g+9h+i+3j+k

Teraz należy obliczyć resztę dzielenia powyższej sumy przez 10. Jeżeli ostatnia cyfra otrzymanego wyniku jest równa 0, to numer jest poprawny. W przeciwnym przypadku cyfra kontrolna nie zgadza się z resztą. Przykładowa implementacja w PHP, może wyglądać następująco:

function peselValidate($pesel)
{
    $sum = 0;
    $weights = array(1, 3, 7, 9, 1, 3, 7, 9, 1, 3, 1); // Wagi dla kolejnych cyfr numeru PESEL
    
    foreach (str_split($pesel) as $position => $digit) {
        $sum += $digit * $weights[$position];
    }

    return substr($sum % 10, -1, 1) == 0;
}

Należy jednak zwrócić uwagę na dwie rzeczy:

• poprawność cyfry kontrolnej nie gwarantuje, że dany numer PESEL istnieje - tylko tyle, że jest zgodny wymogami co do numeru. Faktyczne potwierdzenie istnienia danego numeru jest niemożliwe bez dostępu do ewidencji.
• w Polsce odnotowano przypadki wydania nieprawidłowych numerów PESEL

Aktualizacja (21.02.2015): aktualizacja kodu funkcji, reorganizacja treści

Piszę ten artykuł, ponieważ zauważyłem, że naprawdę wiele początkujących osób nie zwraca na to najmniejszej uwagi.

Zacznijmy od początku. Być może zastanawiasz się dlaczego trzeba dbać o czytelność kodu?

Podstawową zasadą jaką powinieneś przyjąć jest to, że z kodem będą pracować także inni ludzie, a nie tylko Ty. Może do tego dojść choćby przy udzielaniu pomocy na forum lub pisania projektu przez kilka osób. Wtedy czytelność kodu staje się naprawdę ważna, choć uwierz mi, że w momencie kiedy napiszesz naprawdę dużo kodu, bez zwracania uwagi na jego czytelność, to sam bez problemu się w nim pogubisz.

Komentarze
Po to bozia dała chyba praktycznie w każdym języku programowania możliwość komentowania kodu, żeby z niej korzystać. Jak pewnie wiesz, w PHP mamy 3 rodzaje komentarzy.

// komentarz jednolinijkowy

# inny komentarz jednolinijkowy (wywodzący się z Perla)

/* komentarz
wielolinijkowy
może się ciągnąć
w nieskończoność */

Pamiętaj o tym, aby wybrać jeden sposób tworzenia komentarzy jednolinijkowych. W przeważającej większości używa się komentarza //. Komentarze rozpoczynające się od znaku hash #) są już prawie niespotykane, choć część skryptów wykorzystuje je np. do oznaczania sekcji w plikach konfiguracyjnych.

Wcięcia
Ośmielę się napisać, że jest to najważniejsza kwestia jeśli chodzi o czytelność kodu. Porównaj te 2 przykładowe listingi.

if ($petla == true)
{
foreach ($zmienne as $zmienna) {echo strtolower($zmienna); }
} else {
echo 'nie ma pętli';
}

versus

if ($petla == true) { // w tym wypadku lepiej po prostu if ($petla)
    foreach ($zmienne as $zmienna) {
        echo strtolower($zmienna);
    }
}

else {
    echo 'nie ma pętli';
}

Z ułożenia kodu pokazanego na drugim listingu wynika dużo korzyści. Przede wszystkim na pierwszy rzut oka widać, że mamy do czynienia z dwoma warunkami, z czego w pierwszym z nich zawarta jest pętla foreach. Ważne jest to, aby „głębokość” wcięć przy każdym kolejnym poziomie zagnieżdżenia była jednakowa w całym skrypcie.

Nazewnictwo
Kolejna bardzo ważna kwestia. Tutaj liczy się zarówno sposób zapisywania nazw zmiennych, funkcji, klas, metod itd. jak i język w jakim je zapisujemy. Bardzo wielu początkujących zapisuje zmienne w języku polskim. Ponownie przyjrzymy się dwóm przykładom kodu.

$tablica = array(1, 3, 66);
$napis = ‘To prawda’;

if (count($tablica) == 3)
    echo $napis;

$array = array(1, 3, 66);
$text = ‘To prawda’;

if (count($array) == 3)
    echo $text;

Przyznacie chyba, że dużo logiczniej brzmi sekwencja if count array == 3, echo text niż if count talica == 3, echo napis. Skoro instrukcje oraz wbudowane funkcje w języku PHP są w języku angielskim, to nie ma najmniejszego sensu miksować tego z innym językiem i robić bałaganu.

Tutaj zrobię też krótką dygresję do osób, które w tym momencie pomyślały „ale ja nie znam angielskiego. Nie będę się go uczyć, tylko po to, żeby nazwać kilka zmiennych”. Otóż angielski w każdym języku programowania jest językiem podstawowym. Pomijając to, o czym już mówiłem, czyli to, że wszystkie wbudowane instrukcje i funkcje są nazwane po angielsku, niezaprzeczalnym faktem jest, że dużo więcej materiałów na temat programowania jest właśnie w języku angielskim (choćby większość dokumentacji PHP).

Drugą kwestią jest to jak zapisujemy nazwy zmiennych, klas, funkcji, metod itd. Oto niektóre ze sposobów, przedstawię je na przykładzie zmiennej  o nazwie simple var.

echo $simplevar; // totalnie nieczytelne
echo $simple_var ; // metoda pierwsza
echo $simpleVar; // metoda druga (tzw. camelCase)

Oczywiście, że poza tym mamy jeszcze wiele mniej lub bardziej stosowanych sposobów nazewnictwa – chociażby notację węgierską, jednak temu tematowi można by poświęcić spokojnie cały wpis, a ja chciałem jedynie pokazać przykładowe sposoby nazewnictwa.

Zaletami nazywania w stylu $simple_var, jest to, że wszędzie stosowane są tylko małe litery, a PHP rozróżnia je, jeśli chodzi o nazwy zmiennych.

Podsumowanie
Ten artykuł omawia zaledwie zalążek tematu, jednak być  może po jego przeczytaniu łatwiej będzie Wam tworzyć kod łatwiejszy w zarządzaniu. Pamiętajcie, że ważne jest bycie konsekwentnym w decyzjach (zresztą nie tylko w programowaniu…). Kiedy już zdecydujecie się np. na pisanie zmiennych po angielsku, metodą camelCase, to trzymajcie się tego przez cały skrypt, nie róbcie bałaganu i nie utrudniajcie roboty, tym, którzy będą czytać kod po Was.

Na samym początku zaznaczam, że pierwowzór skryptu przedstawionego poniżej nie jest mojego autorstwa! Skrypt znalazłem tutaj (skrypt na samym dole artykułu). Dokonałem w nim kilku przeróbek i w tym miejscu zostawiam dla potomnych - może się komuś przyda!

{{{ more }}}

Wprowadzone zmiany:

• Umieszczenie daty wykonania backupu na górze zrzutu bazy
• Lekkie ogarnięcie kodu PHP. Wiem, że wiele mu brakuje - jak komuś chce się bawić, to proszę bardzo - dla mnie aktualnie liczy się fakt, że skrypt działa
• Zmiana formatu nazwy pliku (na taki który mi bardziej odpowiada :P). Jakby się komuś nie podobał, to zmiana jest przecież banalna.
• Możliwość ustawienia katalogu w którym będą lądowały backupy
• Kilka zmian czysto estetycznych

<?php
header('Content-type: text/html; charset=utf8');

try{
    // KONFIGURACJA - START
    $dbName = 'revival'; // Nazwa bazy danych do zbackupowania
    $dbHost = 'localhost'; // Nazwa serwera baz danych
    $dbUser = 'root'; // Nazwa użytkownika
    $dbPass = ''; // Hasło

    $backupsDir = 'backups'; // Katalog do którego będą zapisywane backupy. Bez końcowego ukośnika!
    // KONFIGURACJA - STOP
    // Dalej lepiej nie ruszać!

    // Stworzenie nowego obiektu klasy PDO
    $pdo = new PDO("mysql:host=$dbHost;dbname=$dbName", $dbUser, $dbPass, array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8"));
    $pdo -> setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    $sqlResult = $pdo -> query("SHOW tables FROM $dbName");

    // Stworzenie nagłówka informacyjnego
    $sqlData = "-- Data wykonania kopii: ".date('d.m.Y')." r. o godzinie ".date('H:i')."
    -- Baza: $dbName
    SET SQL_MODE=\"NO_AUTO_VALUE_ON_ZERO\";";

    while ($queryTable = $sqlResult -> fetch(PDO::FETCH_ASSOC)){
        $sqlTable = $queryTable['Tables_in_'.$dbName];
        $sqlResultB = $pdo -> query("SHOW CREATE TABLE $sqlTable");
        $queryTableInfo = $sqlResultB -> fetch(PDO::FETCH_ASSOC);

        // Dodanie nagłówków dla konkretnych tabel
        $sqlData .= "\n\n--
        -- Struktura dla tabeli `$sqlTable`
        --\n\n";
        $sqlData .= $queryTableInfo['Create Table'] . ";\n";
        $sqlData .= "\n\n--
        -- Wartości tabeli `$sqlTable`
        --\n\n";

        $sqlResultC = $pdo -> query("SELECT * FROM $sqlTable");

        // Stworzenie INSERT-a dla każdego rekordu
        while ($queryRecord = $sqlResultC -> fetch(PDO::FETCH_ASSOC)) {
            $sqlData .= "INSERT INTO `$sqlTable` VALUES (";
            $sqlRecord = '';
            foreach( $queryRecord as $sqlField => $sqlValue ) {
                $sqlRecord .= "'$sqlValue',";
            }
            $sqlData .= substr($sqlRecord, 0, -1);
            $sqlData .= ");\n";
        }
    }

    // Zapisujemy wynik do pliku
    file_put_contents($backupsDir.'/backup_'.$dbName.'_'.date('d_m_Y').'.sql', $sqlData);
    echo 'Backup został zapisany.';
}

catch(PDOException $e){
    echo 'Połączenie nie mogło zostać utworzone: '.$e->getMessage();
}

Skrypt umieścić u siebie na FTP i uzupełnić sekcję konfiguracyjną. Wywoływać ręcznie (poprzez wpisanie URL-a) albo przez CRON-a.

Musisz koniecznie pamiętać o zabezpieczeniu katalogu z backupami (chociażby przez plik .htaccess). Dobrze by było też zabezpieczyć sam skrypt backupujący, aby nikt nie zajechał nam bazy danych przez wywoływanie w pętli.

Mimo tego, że skrypt testowałem, to nie biorę żadnej odpowiedzialności za jakiekolwiek szkody wynikłe z jego korzystania! Boisz się to nie używaj.

Mam nadzieję, że ten skrypt pomoże Wam w tworzeniu kopii swoich baz danych i sprawi, że będzie się to działo częściej niż raz na rok :P. Bo jak wiadomo:

"Ludzie dzielą się na tych, którzy robią backupy i tych, którzy zaczną je robić".

Pozdrawiam.

PS: Jakby ktoś zdecydował się rozbudować ten skrypt np. o wysyłanie backupów na e-mail czy ich uploadowanie na zewnętrzny serwer FTP, to niech go udostępni, może innym też się przyda.