extraweb.pl

Jak szybko usunąć wszystkie tabele z bazy MySQL?

luck — Fri, 13 Apr 2012 18:29:37 +0000

Ostatnio potrzebowałem ponownie zainstalować pewną aplikację opartą na MySQL i PHP, jednak przed instalacją należało usunąć istniejące w bazie tabele. Chwila szukania i trafiłem na ciekawy post, który opisuje świetny sposób: Drop all tables in a MySQL database.

Jedno polecenie załatwia cały problem od ręki:

mysqldump -u[USERNAME] -p[PASSWORD] --add-drop-table --no-data [DATABASE] | grep ^DROP | mysql -u[USERNAME] -p[PASSWORD] [DATABASE]

Oczywistości, jak to co oznaczają pola w kwadratowych nawiasach nie trzeba tłumaczyć. Dzięki temu otrzymujemy bazę pozbawioną tabel, zachowując przy tym pozostałe ustawienia – w przeciwieństwie do użycia DROP/CREATE DATABASE.

Czysty PHP vs Twig

luck — Sun, 11 Sep 2011 11:04:12 +0000

Ponieważ framework symfony2 już jakiś czas temu miał swoją oficjalną premierę zacząłem się poważnie zastanawiać, czy nie oprzeć na nim kolejnego projektu. Jedną z nowości w stosunku do wersji 1.4 jest Twig – system szablonów, którego autorem jest Fabien Potencier, główny developer symfony. Zastanawia mnie, czy stosowanie Twiga rzeczywiście usprawnia tworzenie projektów, czy jest tylko zbędnym gadżetem?

Do tej pory w symfony szablony opisywałem w czystym PHP i nigdy nie doświadczyłem jakichś negatywnych skutków. Dlaczego zatem twórcy sf zdecydowali, że własny język używany do budowania widoków jest potrzebny? W jednym z artykułów na swojej stronie Fabien przytacza kilka argumentów. Przede wszystkim stwierdza, że PHP przestał być dobrym systemem szablonów. Na zasadzie porównań z Django przedstawia wady stosowania PHP do opisywania widoków.

Zwięzłość

Nawet tak trywialny przykład jak wyświetlenie zmiennej pokazuje, że PHP wymaga dłuższego kodu:

 echo $var ?>

{{ var }}

Gdyby jednak w PHP nie zrezygnowano ze skrótu wyświetlania, to wystarczyłoby napisać:

 $var ?>

Wtedy przewaga systemu szablonów byłaby moim zdaniem żadna.
Następne na tapecie jest filtrowanie wyjścia:

 echo htmlspecialchars($var, ENT_QUOTES, 'UTF-8') ?>

{{ var|escape }}

Jest krócej, to fakt. Ale coś tu jest chyba nie tak? Myślałem, że szablon ma odseparować logikę od widoku, a ew. czyszczenie i przetworzenie zmiennych należy przeprowadzić choćby w kontrolerze. A skoro tak, to po co mi do tego system szablonów?

Składnia zorientowana na szablony

Następny przykład – pętla:

 if ($items): ?>
   foreach ($items as $item): ?>
    *  echo $item ?>
   endforeach; ?>
 else: ?>
    No item has been found.
 endif; ?>

{% for item in items %}
  * {{ item }}
{% else %}
  No item has been found.
{% endfor %}

Ok, format Django jest krótszy, ale dla mnie jako programisty konstrukcja „for…else” jest conajmniej dziwna i mniej czytelna niż wersja PHP. Ciekawe też, czy w Django (a więc pewnie i Twigu) jest więcej takich „ficzerów”, czy to tylko jednorazowa funkcjonalność – tak na pokaz.

Ponowne wykorzystanie kodu

Fabien wspomina również o funkcji dziedziczenia szablonów.



  
    {% block head %}
      
    {% endblock %}
  
  
    {% block content %}{% endblock %}
  

 

{% extends "base.html" %}
 
{% block head %}
  {{ block.super }}
  
{% endblock %}
 
{% block content %}
  Index content
{% endblock %}

Zgadzam się, że to jest ciekawa funkcjonalność i dopóki samo PHP nie umożliwi innego sposobu wstawiania zawartości jak „include/require”, to osobiście uważam ją za przydatną. Co prawda system szablonów suma-sumarum i tak zamieni te wszystkie instrukcje na PHPowe „include”, ale łatwość definiowania wartości domyślnych akurat mi się podoba. Tutaj daję plus.

Bezpieczeństwo i sandbox

Tym razem autor porusza kwestię bezpieczeństwa i jako zaletę przytacza fakt, że symfony jako pierwszy framework dla web charakteryzował się automatycznym filtrowaniem, czy też „escapeowaniem” (dziwnie to wygląda) wyjścia. Co z tego, skoro po raz kolejny na warstwę widoku zrzuca się kwestie, za które moim zdaniem nie powinna ona odpowiadać. Oczywiście zależy, jaką główną funkcję naszym zdaniem ma spełniać system szablonów: jeśli ma ułatwiać i przyspieszać pracę, to może być dobre rozwiązanie. Ja natomiast system taki postrzegam jako mechanizm separowania różnych warstw aplikacji, którego zadaniem jest wyświetlanie odpowiednio przygotowanych danych, nie zaś ich obrabianie. Ma on jedynie ułatwić zadanie osobie projektującej layout. Nie rozumiejąc istoty, ani powodu umieszczenia niektórych zapisów może ona zwyczajnie usunąć pewne elementy szablonu. Zatem jaki rozsądny programista pozostawi grafikowi jedną z kluczowych kwestii bezpieczeństwa?

Pomijając powyższe, autor sam przyznaje, że domyślnie przyjęta polityka filtrowania wszystkiego, zamiast ułatwiać może uprzykrzać życie. W tym celu wprowadzono możliwość wyłączania omawianego mechanizmu na żądanie:

{% autoescape off %}
  {{ object.as_html }}
{% endautoescape %}

Wydaje mi się, że z domyślnym filtrowaniem może być więcej problemów niż pożytku – nie uważam tego za dobre rozwiązanie. Mam nadzieję, że w konfiguracji Twiga da się to jakoś wyłączyć.

Wyjątkiem może być tutaj „sandbox mode”. Jeśli nasza aplikacja z założenia musi pozwalać na osadzanie na stronie kodu wygenerowanego przez użytkownika, to tryb chroniony może się rzeczywiście przydać.

{% sandbox %}
    {% include "foo.twig" %}
    {% include "bar.twig" %}
{% endsandbox %}

Porównanie z innymi systemami szablonów

Jak nietrudno się domyślić, na stronie autora w porównaniu z konkurencją Twig zawsze wygrywa. Co z tego, jeśli w porównaniu autor nie umieścił najbardziej nas interesującego – czystego PHP. Mimo tego, że szablony Twiga są kompilowane do PHP, to podejrzewam, że programista musiałby być naprawdę kiepski, żeby stworzyć widok w PHP, który wydajnościowo przegrałby z takim samym generowanym przez system szablonów.

Jak zwykle – wszystko zależy…

Odniosłem wrażenie, że Twig jako podstawowy system opisu widoków w symfony2 jest rozwiązaniem dołożonym niejako na siłę, tylko dlatego, że taki jest obecnie trend. Jaki zatem może być sens stosowania systemu szablonów? Odpowiedź jest prosta: utrudniając pracę sobie, ułatwiamy życie grafikowi, czy projektantowi UI. Z pewnością elastycznemu programiście będzie łatwiej nauczyć się języka opisu szablonów by dostosować swoją wiedzę do potrzeb grafika, niż odwrotnie. Jeśli przyjazny wygląd aplikacji jest jednym z kluczowych wymogów stawianych przez klienta, to mając na uwadze dziedziczenie szablonów oraz ew. sandbox, warto rozważyć możliwość zastosowania mechanizmów Twiga. Przy dużych projektach, nad którymi pracuje zespół osób, gdzie można wyodrębnić grupę odpowiedzialną za UI, byłbym skłonny wykorzystać system szablonów na rzecz ułatwienia im pracy. W każdym innym wypadku raczej podziękuję i zostanę przy zwykłym, czystym PHP. Tak, czy inaczej, z czystej ciekawości na pewno wypróbuję Twiga, żeby zweryfikować wszystko, co napisałem.

Zaznaczam jeszcze raz, że Twiga dotąd nie używałem, a jedynie przymierzam się do jego wykorzystania. Opinię na jego temat opieram na materiałach zawartych na stronie autora projektu. Jeśli macie jakieś sugestie lub doświadczenia z używaniem systemów szablonów w PHP, ew. możecie podać inne „za” o „przeciw” – będę wdzięczny.

Sposób na losowe hasło

luck — Sat, 10 Sep 2011 08:49:06 +0000

W swojej pracy z pewnością nie raz spotkaliście zdarzyło się Wam otrzymać od klienta e-mail z prośbą o np. założenie w panelu administracyjnym WWW konta dla nowego użytkownika. Oczywiście wiąże się to zawsze z utworzeniem loginu i hasła. O ile z nazwą użytkownika raczej nie ma problemu, to już jakiś czas temu znudziło mi się wymyślanie nowych haseł „na poczekaniu”, dlatego ostatnio przypomniałem sobie, że istnieje o wiele wygodniejsze wyjście, pozwalające wygenerować losowe hasło.

Chociaż z podobnymi rozwiązaniami spotykałem się już wcześniej, to opisywaną metodę zacząłem stosować po przeczytaniu książki „Asterisk: The Definitive Guide” wydawnictwa O’Reilly. W rozdziale zatytułowanym „User device configuration” podczas omawiania szczegółów dotyczących konfiguracji kont SIP dla urządzeń został podany następujący sposób na wygenerowanie losowego i dość „silnego” hasła przy użyciu linuksowej konsoli:

$ dd if=/dev/random count=1 bs=8 2>/dev/null | base64 | sed -e 's/=*$//'

Wystarczy wklepać (lub wygodniej wkleić) to polecenie w terminalu i jako wynik otrzymamy wygenerowane np. takie hasło: Vecls7Dm5O4yTgJo. Parametr bs=8 mówi nam o długości hasła – w tym przypadku będzie ono miało 8 znaków.

Zakładam, że każdy programista web ma podczas pracy dostęp do konsoli linuksa, dlatego praktycznie w każdej chwili możemy w/w sposób wykorzystać. Jeśli chodzi o generowanie hasła pod Windowsem, jedyne co mi przychodzi do głowy, to jakiś generator online. Być może macie jakieś sprawdzone sposoby. Jeśli tak, to chętnie je poznam.

Czy programista powinien prowadzić blog?

luck — Sun, 04 Sep 2011 12:48:00 +0000

Pracując nad nową wersją mojej strony napotkałem na pewien dylemat. Czy przy okazji wprowadzanych zmian powinienem również założyć bloga? W dobie wszechobecnych „social mediów” i bloggerów taka forma przedstawienia swojej działalności wydaje się być konieczna.

Mnie jednak w tym wypadku nie przekonał argument „wszyscy tak robią”. Od dość długiego czasu poza forami internetowymi nie uprawiałem innej formy komunikacji z ludźmi z branży, o ile z nimi nie współpracowałem.
Spróbowałem krótko rozważyć wszystkie zalety posiadania bloga.

Czerpiesz wiedzę – dziel się nią.

Jestem czytelnikiem blogów dla programistów. Dla przykładu Jacek Laskowski w swoich wpisach nie raz otwierał mi oczy na wiele aspektów związanych z programowaniem Java. Czasem czyjś kilkulinijkowy post nagle rozjaśniał mi w głowie chroniąc przed wymyślaniem koła na nowo. Blogi są zatem dla programistów źródłem wiedzy, które trudno przecenić. Skoro więc sam z tej wiedzy korzystam, będzie jak najbardziej w porządku jeśli dołożę coś od siebie. Pozostaje mieć nadzieję, że korzyści będą obopólne: czytelnicy zdobędą nowe informacje, a ja będę mieć świadomość, że moja wiedza i doświadczenie mogły posłużyć nie tylko osobom, które za nie zapłaciły.

Konstruktywna krytyka.

Z doświadczenia wiem, że pisząc artykuły mimo najszczerszych chęci należy się liczyć z niepochlebnymi opiniami. Mogą one być zarówno niezasłużone, jak i w pełni uzasadnione. Przy zdrowym podejściu do siebie i komentujących będziemy w stanie wyłuskać spośród fali krytyki konstruktywne opinie i nauczymy się ich poprawnej interpretacji oraz wyciągania prawidłowych wniosków. Programiście pozwoli to zarówno na dostrzeżenie błędnego pojmowania niektórych mechanizmów, jak również skonfrontowanie opisywanych rozwiązań z innymi osobami „z branży”, nierzadko bardziej doświadczonymi w danym temacie.

Dokładne poznanie zagadnienia.

Opisywanie zagadnienia jest najlepszym sposobem na jego lepsze zrozumienie. Pisząc na dany temat, liczymy się z możliwością wystąpienia wspomnianej krytyki. Dzięki temu mamy motywację do jak najdokładniejszego poznania szczegółów poruszanego tematu i podania możliwie najbardziej rzetelnych informacji.

Blog to doskonała forma promocji.

Nawet najładniej opakowana w marketingowy bełkot prezentacja nie powie potencjalnemu klientowi tyle na temat programisty, co przeczytanie kilku artykułów na jego blogu. Pozwoli to ocenić komunikatywność, charakter oraz – co najważniejsze – rzeczywistą wiedzę i kompetencje. Zatem: pozwolimy się poznać przyszłemu klientowi.

Z wymienionych powodów do całej blogosfery dołączam również moją skromną osobę. Mnie przytoczone argumenty przekonały. Jeśli znacie jeszcze jakieś, będę wdzięczny za podzielenie się nimi.