System kodowania Unicode UTF-8 jest najlepszym, i zarazem najpopularniejszym który obsługuje znaki diakrytyczne. Niestety często spotykanym problemem jest to, że wykonany skrypt PHP ma problemy z ich wyświetleniem lub przetworzeniem. Może to być spowodowane zła konfiguracją serwer, brakiem meta tagu lub kodowaniem pliku. Poniżej postaram się pokazać, jak w prosty sposób temu zaradzić.   1. Zła konfiguracja serwera. Może się zdarzyć, że Twój serwer ma ustawione błędne kodowanie. Aby to sprawdzić wywołaj funkcję phpinfo(), a następnie odszukaj pozycję default_charset. Jeżeli przyjmuje ona wartość no value lub utf-8, to twój serwer jest skonfigurowany poprawnie. W przeciwnym wypadku, jeżeli posiadasz Windows’a wystarczy odtworzyć w edytorze plik php.ini, a następnie zakomentować linijkę default_charset(u mnie 814). Jeżeli postawiłeś serwer na systemie Linux, w pliku httpd.conf dodaj AddDefaultCharset utf-8 (o ile nie jest już tak ustawione. Możesz zrobić to jeszcze w całkiem inny sposób, dodając zaraz po otwarciu klamry PHP:

1	ini_set('default_charset', 'UTF-8');

  2. Kodowanie pliku. Każdy plik wykonywany wraz z uruchomieniem Twojej strony (zaincludowany też), musi mieć ustawione odpowiednie kodowanie. Zmienić je możesz za pomocą większości edytorów, jak np. Notepad++. Wystarczy że wejdziesz w sekcję Format, a następnie wybierzesz Koduj w UTF-8 (bez BOM).   3. Nagłówek. Jeżeli Twój kod znajduję się w szkielecie dokumentu HTML, upewnij się że zawiera on meta-tag:

1	<meta http-equiv="Content-type" content="text/html; charset=utf-8">

W przypadku samego kodu PHP, dodaj na samym początku:

1	header('Content-Type: text/html; charset=utf-8');

  4. Zapytanie MySQL. Jeśli Twoje dane pobierane są z bazy danych, to właśnie w niej może tkwić problem. Aby to naprawić, dodaj to zaraz po połączeniu się z bazą danych:

1	mysql_query("SET NAMES utf8");

  I to by było na tyle. Pozdrawiam Jakub Cieślak.

Nawigacja

• Wprowadzenie (Tu jesteś)
• Przygotowanie środowiska i instalacja

Na wstępie pragnąłbym zaznaczyć, że jest to tylko pierwszy wpis, mam nadzieję cotygodniowej serii wprowadzającej do frameworka Laravel.

Jako, że tak na prawdę jest to mój początek z blogowaniem i pisaniem czegokolwiek innego niż kod, maile, wypracowania w czasach liceum lub <160 znakowe wiadomości na blipie czy innym twitterze. Tylko nie przypominajcie mi o moim poprzednim blogu. Powiedzieć, że jestem niezadowolony z jego wartości merytorycznej to za mało.

Pozwolę sobie zarzucić sucharem rozluźniającym atmosferę:

A SQL query goes into a bar, walks up to two tables and asks, „Can I join you?”  

Czas jednak przejść do rzeczy, mianowicie czym będzie, a raczej czym chcę aby była ta seria. Moim celem jest napisanie kompletnego wprowadzenia do frameworku Laravel,  nauczenie kogoś, kto zna PHP tylko w podstawowym stopniu. O MVC coś tylko słyszał (lub nawet nie). Nie będzie to seria wpisów przydatna dla kogoś, kto od 2 lat pisze w Symfony lub kogoś kto choć raz w życiu pisał swój własny framework. Najbardziej chciałbym aby tą serią zainteresowały się osoby całkowicie nowe w świecie programowania, które obrały PHP jako coś czego chcą się uczyć. Zależałoby mi też na osobach, które nawet zarabiają na pisaniu kodu jednak nie są świadome możliwości jakie dają im frameworki, biblioteki, dobre praktyki.

Pozwolę sobie zwracać się do czytelnika, jakby był bardzo początkujący. Proszę przy okazji osoby, które są bardziej doświadczone, aby nie czuły się obrażone.

„Czemu miałbym się uczyć Laravel skoro…co to jest w ogóle framework?!”

Wyobraź sobie, że jesteś freelancerem przyjmującym zlecenia na tworzenie różnych prostych stron oraz bardziej zaawansowanych aplikacji internetowych. Nie stronisz także od poprawek w istniejących serwisach. Czemu miałbyś je odrzucać, przecież to duża część rynku.  Dostajesz maila z powiedzmy taką treścią:

Witam, jestem właścicielem małej firmy, w której pracuje 5 osób. Wszystkie te osoby siedzą w jednym biurze. Lwią częścią ich pracy jest rozmowa przez telefon oraz praca w excelu. Ważnym szczegółem jest jednak to, że zbiory zewnętrznych rozmówców pracowników nachodzą na siebie. Innymi słowy pracownicy często rozmawiają z osobami, do których wcześniej dzwonił, któryś z współpracowników. Klienci często są bardzo specyficzni i potrzebują specjalnej opieki (nie troski). Na jednego na przykład nie wolno w ogóle krzyczeć ponieważ jego lekarz twierdzi, że może to spowodować u niego zawał, inny w ogóle nie odbiera telefonów przed 14. Jeszcze inny chce rozmawiać tylko z kobietami. Są też tacy, którzy wymagają włączenia im rosyjskiego hymnu zanim się w ogóle można przywitać.

Obecnie w mojej firmie funkcjonuje aplikacja zainstalowana na wewnętrznym firmowym serwerze, gdzie każdy klient ma swoją podstronę z tekstem, który opisuje zasady rozmowy z nim. Niestety (dla mojego portfela wprost przeciwnie) w ostatnim roku baza naszych stałych klientów zwiększyła się z 2 aż do 400. Można sobie tylko wyobrazić jak to wpłynęło na przydatność owego rozwiązania (aplikacji). Pracownicy zaczęli się przerzucać na żółte karteczki. Dziś przyjeżdża kolejna ciężarówka z dostawą karteczek – mówię Panu, te karteczki śnią mi się już po nocach, chcę z tym skończyć!

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

Zwiń
Czytaj na blogu autora...

Dzisiejszy wpis jest tym z rodzaju błahych, ale nie do końca. Często zapominamy, że przeniesienie słowa z życia codziennego (w tym wypadku: float) do świata maszyn nie zawsze jest właściwe.

Często w projektach, w których uczestniczę projektowanie bazy danych oddaje się w ręce niedoświadczonych osób. Bo dlaczego nie może jej zaprojektować osoba, która będzie tworzyła logikę w aplikacji do niej?

Zaprojektować owszem – może, ale często osoba odpowiedzialna za część programistyczną aplikacji ma nikłe pojęcie o projektowaniu bazy, a szczególnie dostępnych typach, procedurach itp.

INT(10) != VARCHAR(10)

Szczególnie studenci i osoby z firm, gdzie wyznaje się zasadę „człowiek-orkiestra” popełniają ten błąd. Korzystając z typu VARCHAR i podając jego wielkość (10) sądzą, że tak samo można ograniczyć wielkość (długość) pól liczbowych, np. INT.

Tym bardziej powielają ten błąd, gdy silnik bazodanowy podczas tworzenia tabeli nie zwraca błędu. Zapis INT(10) jest poprawny, ale nie powoduje on, że ograniczymy INT do 10 miejsc (pomijam fakt, że niektórzy sądzą, że podając INT(18) przeskoczą definicję długości samego INT-a). Z założenia zapis INT(X) powinien iść w parze z opcją ZEROFILL. Konstrukcja:

CREATE TABLE `codes` (

`code` INT(5) ZEROFILL COMMENT 'kod, ktory zostanie dopełniony zerami'

)

To spowoduje, że gdy dodamy kod o wartości 1, to wynik zapytania zwróci nam 00001 (czyli cyfrę 1 uzupełnioną do 5 miejsc zerami – ZEROFILL). I tylko dlatego istnieje zapis INT(X), a nie z powodu ograniczenia długości pola danego typu numerycznego. Od tego mamy masę aliasów (jak SMALLINT czy TINYINT).

FLOAT czy DECIMAL/INT?

Jedną sprawę mamy wyjaśnioną. Teraz poważniejsza sprawa, która wpływa na wyniki zapytań bazy danych. Raz na jakiś czas zdarza mi się zetknąć z kodem, gdzie kwoty z faktur, rachunków są umieszczane w polach typu FLOAT. Wydaje mi się, że autorów takich konstrukcji popycha posługiwanie się tłumaczeniem FLOAT na język polski jako liczba zmiennoprzecinkowa. Człowiek widzi hasło „liczba … przecinkowa” i sądzi, że służy do zapisu ogólnie pojętych cen. Dlatego lepiej odwołać się do angielskich definicji, które moim zdaniem są jaśniejsze: float jest to liczba aproksymowana, czyli przybliżona. A najlepiej posłużyć się przykładem. Utwórzmy tabelę:

CREATE TABLE `invoice_record` (

`price` FLOAT NOT NULL

)

Następnie umieśćmy w niej dane z wartościami po przecinku, np. kwotę „29.99„. Cała operacja się powiedzie, a zapytanie SELECT zwróci nam odpowiednie wyniki. Oto nam chodziło. Na pewno?

W przypadku, gdy będziemy chcieli uzyskać faktury, które mają pozycje z ceną ”29.99” lub są większe równe to nie zobaczymy żadnych wyników. Dlaczego? Ponieważ jest to liczba zmiennoprzecinkowa, a prościej nieprecyzyjna. Nasze „29.99” wygląda tak naprawdę tak:

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

Zwiń
Czytaj na blogu autora...

Często słyszę oburzenie przeciwników JavaScriptu, jakoby przez wieczne funkcje zwrotne (callbacks) JavaScript był prymitywnym i strasznym językiem narzucającym trudne do opanowania zależności i zagnieżdżenia kodu. Owszem, JavaScript ma wiele słabych stron i można mu sporo zarzucić, jednak sterowanie poprzez zdarzenia jest piękną cechą tego języka. Często można trafić na kod początkujących programistów JavaScript, przypominający ten [...]

Unia Europejska uszczęśliwiła nas przepisami, które wymuszają umieszczanie na stronie www informacji o polityce dotyczącej cookies, gdy strona korzysta z ciasteczek. W związku z tym stworzyłem gotowy skrypt, który będzie wyświetlał stosowne informacje na stronie www wraz z linkiem do polityki prywatności dla strony www. Skrypt jest tak skonstruowany, że w momencie zamknięcia informacji o [...]

Na jednym z forów trafiłam na świetną prezentację na temat programowania w PHP, w której autor podejmuje się pokazać różnice między programowaniem w PHP a klepaniem kodu nazwanym przez niego PHPowaniem. Błądzić jest rzeczą ludzką, ale najważniejsze by się umieć krytycznie przyjrzeć sobie. Na szczęście stać mnie na to, więc się sobie przyglądam. Od kilku [...] No related posts.

Po mojej ostatniej recenzji trochę bałem się następnej książki, jednakże przemogłem się i dzięki temu właśnie teraz czytacie recenzję pozycji HTML5 Canvas: Receptury, udostępnionej mi przez Wydawnictwo Helion. I powiem Wam, że nie żałuję, po jest to pozycja interesująca, przynajmniej dla osoby, która nie miała zbyt dużej styczności z Canvas API, a do takiej właśnie się zaliczam.

Uprzedzając – czy jest to artykuł sponsorowany? W jakiś sposób tak – książka zostanie u mnie i zostanie przeznaczona na nagrodę na następnym meet.php. Czy moje opinie są sponsorowane? Zdecydowanie nie.

HTML5 Canvas:Receptury

Tematyka

Na okładce możemy przeczytać:

Ponad 80 receptur prezentujących użycie elementu canvas, które zrewolucjonizują strony WWW.

I jest tak faktycznie. W książce znajdziemy 9 rozdziałów, od podstaw rysowania, poprzez tworzenie animacji a na wprowadzeniu do WebGL kończąc. Po ok. 20 stronach poznawania materiału wiemy już jak korzystać z podstawowych elementów (linie, krzywe, tekst) i dokładnie na 34 stronie piszemy kod rysujący fraktale – moim zdaniem całkiem niezłe tempo.

Jednakże jeden fragment wydał mi się śmieszny – na początku książki napisane jest, że pozycja przeznaczona jest dla programistów aplikacji internetowych znających HTML i JavaScript. Ale akapit wcześniej słowa, że do pracy wystarczy zwykły Notatnik. Ta… już to widzę, jak programista (!) aplikacji internetowych używa Notatnika na codzień – chyba jakiś masochista :P

Mamy osobne rozdziały poświęcone pracy z elementami video, obsłudze eventów (dzięki tej książce dowiedziałem się, że nie jest to takie hop-siup) czy też pisaniu własnej gry. I nie jest to kółko i krzyżyk, ale platformówka z detekcją krawędzi czy też miejsc o specjalnym znaczeniu.

Jeśli chodzi o treść książki i poruszone w niej tematy, to jako osoba która o Canvas API ma bardzo nikłe pojęcie nie zauważyłem jakiś rażących braków.

Treść

Praktycznie każde opisywane zastosowanie opatrzone jest przykładem w postaci kodu i screenów, który to kod podzielony jest najczęściej na kilka części, opatrzonych stosownym komentarzem. Dzięki temu nie ma problemu ze zrozumieniem kodu, który zajmuje np. 4 strony, a i takie się zdarzają.

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

Zwiń
Czytaj na blogu autora...