Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM

Autor wpisu: zleek, dodany: 06.06.2013 10:14, tagi: javascript, jquery

Pracując z pluginem jQuery validation czasami okazuje się, że domyślnie wbudowane walidatory są niewystarczające dla naszych potrzeb. W takiej sytuacji nie pozostaje nic innego, jak stworzenie własnych walidatorów. Dodawanie własnej metody walidującej Aby dodać własną metodę walidującą należy skorzystać z następującej funkcji jQuery validation: Jako parametry funkcja ta przyjmuje: name – nazwa walidatora validationFunction – [...]

Autor wpisu: Diabl0, dodany: 03.06.2013 14:20, tagi: php

Przed chwilą straciłem prawie dwie godziny walcząc z instalacją php-imagick na maku. Aby zaoszczędzić sobie (i innym) podobnego problemu w przyszłości gotowa solucja:

  1. port install php-imagick Zainstaluje nam wszystko co potrzebne
  2. ln -s /opt/local/include/ImageMagick-6 /opt/local/include/ImageMagick/ Brak tego dowiązania zmarnował mi tyle życia…
  3. pecl install imagick Ważne pytanie: Please provide the prefix of Imagemagick installation [autodetect] : /opt/local

    Build process completed successfully Installing ‚/usr/include/php/ext/imagick/php_imagick.h’ Installing ‚/usr/include/php/ext/imagick/php_imagick_defs.h’ Installing ‚/usr/include/php/ext/imagick/php_imagick_shared.h’ Installing ‚/usr/lib/php/extensions/no-debug-non-zts-20090626/imagick.so’ install ok: channel://pecl.php.net/imagick-3.0.1 configuration option „php_ini” is not set to php.ini location You should add „extension=imagick.so” to php.ini

  4. edytujemy /etc/php.ini i dodajemy na końcu: extension=”/usr/lib/php/extensions/no-debug-non-zts-20090626/imagick.so” (ścieżka może się różnić, będziecie ją mieli pod koniec pecl install:

 

I to tyle. Niby takie proste, a jednak upierdliwe.

Autor wpisu: bastard13, dodany: 03.06.2013 09:14, tagi: design

czy warto pisać testy przed implementacją?

Testowanie samo w sobie przynosi korzyści, zazwyczaj w dłuższej (oby:) perspektywie czasu, ale prędzej czy później jesteśmy w stanie dostrzec ich wartość i nieraz oddychamy z ulgą, gdy widzimy, że ludzie pracujący nad kodem przed nami, poświęcili trochę czasu na napisanie solidnych zestawów. Lecz o zaletach posiadania testów już pisałem ostatnio (tutaj i ciąg dalszy :). I o ile z tym, że posiadanie testów przynosi korzyści i jest to jedna z tych rzeczy, którą wielu programistów chce praktykować nie kłóci się nikt, o tyle nie wszyscy widzą jakikolwiek sens w pisaniu testów przed implementacją. Że niby sprawia, że kod jest lepszy, że jeszcze raz myślimy o problemie, że patrzymy na niego od innej strony, itp., itd.Problem z tymi wszystkimi stwierdzeniami jest taki, że to są jedynie oklepane zwroty, którymi karmią nas bardziej doświadczeni, mądrzejsi znawcy tematu, którzy powołują się na własne doświadczenie i którym powinniśmy zaufać. I ja wcale nie twierdzę, że nie mają racji, czy też nie neguję ich kompetencji, ale człowiek (a programista też człowiek :) woli uczyć się na własnych błędach. Przynajmniej do momentu, gdy nie zobaczy konkretnego przykładu, który pokazuje mu, że jednak jest tak, jak podpowiada starszy kolega.Czytaj więcej »
Wszystkie wpisy należą do ich twórców. PHP.pl nie ponosi odpowiedzialności za treść wpisów.