Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM    Subskrybuj kanał ATOM dla tagu php Kanał ATOM (tag: php)

Autor wpisu: Tomasz Kowalczyk, dodany: 24.08.2011 22:47, tagi: php

Język PHP to dla wielu programistów sposób patrzenia na tworzenie różnego rodzaju stron internetowych. W wielu miejscach krytykowany, w wielu chwalony - w pewnym sensie podzielił środowisko webdeveloperów na zwolenników oraz przeciwników tej technologii. Ja mam przyjemność stać po pierwszej z wymienionych stron, dlatego zapraszam do przejrzenia kolejnej partii linków związanych z językiem PHP i [...]

Autor wpisu: Kamil, dodany: 22.08.2011 15:15, tagi: apache, javascript, php

Od czasu do czasu trafiam na taką bibliotekę, która nierozłącznie towarzyszy przy 80% wykonywanych przeze mnie projektów. Tak było z jQuery, 960 Grid System, PHP Mailer czy HTML Purifier. Jakiś czas temu zostało wydane Boilerplate 2.0, biblioteka mająca usprawnić życie web developera pracującego z HTML5 & CSS3. Boilerplate 2.0 jest jedną z takich bibliotek. Czym [...]

Autor wpisu: Śpiechu, dodany: 21.08.2011 18:58, tagi: php

Mamy niedzielę. W ramach leniuchowania zachciało mi się poznać jakiś nowy język programowania. Padło na Pythona (nieznacznie wygrał z Rubym).

Na pierwszy rzut oka to w zasadzie taki JavaScript ogólnego przeznaczenia bez przeglądarki. Python reklamowany jest jako język typu batteries included, czyli standardowa biblioteka powinna zawierać wszystko to, co w typowych zastosowaniach programista potrzebuje.

Od razu widać puryzm kodu Pythona. Żadnych klamerek, żadnych średników — wszystko załatwiamy wcięciami i końcami linii. „Kompresja kodu” widoczna jest na każdym kroku, np. funkcje deklarujemy poprzez def, a nie przydługawe function, obiekty tworzymy bez new. Weźmy na przykład najprostszą funkcję żądającą od użytkownika wpisania z klawiatury jakiejś liczby:

def getIntInput(message):
    while True:
        try:
            return int(input(message))
        except ValueError:
            print("You were supposed to enter integer!")

W 6 liniach mamy załatwioną prośbę o wpisanie czegoś, przetworzenie wejścia i wyłapanie ewentualnych błędów. Funkcja nie odczepi się od użytkownika dopóki nie wpisze poprawnie jakichś cyferek.

wiek = getIntInput("Podaj rok urodzenia")

Poniżej w punktach ciekawostki, które w Pythonie są, a których nie ma w PHP (tyle co w ciągu kilku godzin udało mi się wyłapać):

  • wspomniane już braki klamerek i średników — czy naprawdę potrzebujemy tego wszystkiego w PHP?
  • wszystkie metody publiczne — tego nie popieram, może powodować bajzel w API; zgodnie z konwencją metody prywatne należy oznaczać przedrostkiem _
  • fajne konstrukcje przy iterowaniu: for zmienna in array oraz for zmienna in range(5)
  • dziwne zasady dokumentowania kodu — komentarze idą po deklaracji klasy czy metody
  • array comprehension (nawet nie wiem jak to przetłumaczyć) — w jednej linijce możemy stworzyć nową tablicę na podstawie starej i przejechać jakąś funkcją po każdej wartości przed dodaniem:
    nowaTablica = [funkcja(wartosc) for wartosc in staraTablica]
  • proste losowanie:
    zagadka = random.choice(["wartosc1","wartosc2","wartosc3"])
  • tuple, czyli niedająca się modyfikować tablica; co ciekawe, funkcje bardzo często zwracają to ustrojstwo, możemy od razu złapać je do dwóch różnych zmiennych
    wynik1, wynik2 = funkcja()
  • obiekt None zamiast null
  • == i != do sprawdzania wartości zmiennych, is i is not do porównywania z None lub referencji, mało tego, możliwa jest konstrukcja 0 <= a <= 10
  • próba porówania if „3” < 4 wywali TypeError
  • konstrukcja final do kompletu z try/except
  • bajer dla mnie: if szukanaZmienna in tablica oraz if „wyraz” in przeszukiwanyString

Tyle na początek. Widzę, że Python to fajna sprawa. O wszystkim pomyśleli. Nawet o wbudowaniu bazy danych sqlite w bibliotekę standardową. Jeżeli ktoś waha się czego by tu nowego się pouczyć to polecam!

P.S.: Tak, wiem, na tych waszych polibudach Pythona uczą już na I roku, ble ble srutututu. Samoucy typu np. ja muszą sami. Dobra, kończę, bo i piwo mi się skończyło :-(

Autor wpisu: Tomasz Kowalczyk, dodany: 19.08.2011 23:58, tagi: php, doctrine, sql, symfony

Pobieranie informacji z baz(y) danych to jedna z podstawowych czynności, jaką wykonujemy podczas tworzenia różnego rodzaju stron internetowych. Aby uzyskać potrzebne dane w zdecydowanej większości przypadków wystarczy proste zapytanie SQL [w przypadku Doctrine możemy też wykorzystać język DQL]. Niektóre przypadki wymagają jednak potrzeba bardziej ambitnej ekwilibrystyki, aby przygotować odpowiedni zbiór rekordów. W dzisiejszym wpisie chciałbym [...]

Autor wpisu: widmogrod, dodany: 14.08.2011 13:16, tagi: javascript, php

Dzisiaj zabrałem się za porządkowanie mojej wiki, która jest dla mnie najlepszym sposób kolekcjonowania informacji. Wiki znajdziecie pod adresem wiki.widmogrod.info.

Tak „biblioteka wiedzy” wzbogaciła się m.in. w:

Jak by ktoś z was był zainteresowany różnego rodzaju dodatkowymi informacjami o Cappuccino Framework i społeczności wokuł niego to zapraszam do działu Szkice i różne materiały dodatkowe o Cappuccino Framework.

Z działu programowanie najbardziej podoba mi się ciekawy wzorzec projektowy Circuit Breaker. Umieściłem w tym dziale link do artykułu, który zawiera  POC implementacji go w Zend Framework.

Natomiast w dziale JavaScript podoba mi się nowy język programowania, który jest kompilowany do JavaScript – CoffeeScript.

To tyle, pozdrawiam!

Autor wpisu: Tomasz Kowalczyk, dodany: 13.08.2011 21:32, tagi: symfony, php

Komponent formularzy frameworka symfony jest naprawdę bardzo potężnym narzędziem, pozwalającym na tworzenie zaawansowanych rozwiązań przetwarzających dane pochodzące od użytkownika na odpowiednią formę. O ile przetwarzanie formularza zazwyczaj sprowadza się do operacji na przesłanych do niego danych, o tyle czasem potrzebujemy innych, zawartych poza jego polami. W dzisiejszym wpisie chciałbym pokazać, w jaki sposób przekazać te [...]

Autor wpisu: bastard13, dodany: 12.08.2011 00:41, tagi: php

pre { border: #aaa solid 1px; padding: 10px; margin: 5px 5px 15px 5px; font-family: "Courier New",Courier,monospace; background-color: #f9f9f9; } pre span.key_word { color: #006699; font-weight: bold; } pre span.comment { color: #008200 } pre span.variable{ color: #AA7700} p { margin: 0px; } O tym czym różnią się operatory widoczności można przeczytać tutaj.Ostatnio zauważyłem dziwną tendencję do używania jedynie dwóch z nich, a mianowicie protected i public. Publiczne są metody (ewentualnie dane), które mają być dostępne na zewnątrz, a wszystko inne jest chronione. W myśl zasady: może kiedyś będę tą klasę rozszerzał. Osobiście nie zgadzam się z takim podejściem. Projektując klasę wiemy, co chcemy aby robiła, a takie wybieganie w przyszłość 'bo może coś się przyda' powoduje niepotrzebny śmietnik.Moim zdaniem głównymi operatorami, na których powinien się opierać programista projektując klasę, to private i public, a dopiero w dalszej kolejności protected.Decyzja o tym, którego operatora należy użyć będzie łatwiejsza o ile będzie się pamiętało o kilku rzeczach:
  • Enkapsulacja, czyli atrybuty klas powinny być prywatne. Dlaczego? Krótko i rzeczowo jest to wyjaśnione tutaj.
  • Gdy już mamy atrybuty klasy, trzeba zastanowić się do czego ta klasa będzie wykorzystywana i na tej podstawie należy zdefiniować metody publiczne, czyli te, które będą wykorzystywane przez inne klasy.
  • Jeżeli nie planujesz w obecnej chwili, aby klasa była rozszerzana, to wszystkie metody, które nie są wykorzystywane poza klasą powinny być prywatne. Jeżeli zakładasz, że "może w przyszłości", to również zostaw je jako prywatne. Kod nie jest stałym bytem, może ewoluować, a więc jeżeli zajdzie potrzeba, to zawsze możesz go rozszerzyć lub zmienić.
  • Jeżeli klasa będzie rozszerzana, to metodami chronionymi powinny być jedynie te, które są potrzebne w klasie pochodnej, a nie wszystkie niepubliczne.
  • Jeżeli klasa pochodna powinna mieć dostęp do atrybutów klasy, do których nie ma akcesorów, to nie oznacza, że należy zmienić widoczność atrybutów na protected. To oznacza, że można dodać chronione settery i/lub gettery.
  • Zastanów się trzy razy zanim podejmiesz decyzję o zmianie operatora private na protected w metodach, dziesięć razy jeżeli chcesz to zrobić z atrybutem.
  • Gruntownie przemyśl decyzję o wyciągnieciu metody na zewnątrz, czyli zmianie operatora na public. Rób to tylko wtedy, gdy metoda jest rzeczywiście potrzebna poza klasą.
  • Rzadko istnieje rzeczywista potrzeba zmiany operatora widoczności atrybutu z private na mniej restrykcyjny - protected. Jeszcze rzadziej zachodzi potrzeba upublicznienia atrybutu.
Mam nadzieje, że tych kilka wskazówek się przyda:)
Wszystkie wpisy należą do ich twórców. PHP.pl nie ponosi odpowiedzialności za treść wpisów.