Wpis z mikrobloga

@HalEmmerich: @zakopiak: jak ktoś na local lub stagging nie potrafi ogarnąć sniffera i/lub włączyć debuger'a np. w WP czy drupalu lub spojrzeć na logi w laravelu, symfony czy cokolwiek wykorzystuje no to klient faktycznie wraca z listą bugów.
  • Odpowiedz
@internet3000: no sorry, ale bzdury troche piszesz.

A teraz popatrz na Symfony i ich BC.

Symfony1 vs Symfony2 vs Symfony3 vs Symfony4 (ktore np. zaczyna sie wzorowac na L5).


Symfony 1 to był osobny framework, 2 jest przepisana od zera, wiec ciężko było migrować z 1 na 2 ale i to robiłem parokrotnie. Prowadze kilka projektów od Symfony 2.0 i były może dwie lub trzy kosmetyczne zmiany aż do teraz
  • Odpowiedz
@Nizax: :) nie zrażaj sie, własna opinia jest ważna, ale dobrze jest pogadać i wymienić się argumentami :P ja mam po prostu dobry widok na to bo tak jak mowilem pracuje przy silniku więc na codzień spotykam się z złożonością projektów, które napędzają javascript. I z drugiej strony perspektywa - siedziałem trochę przy kodzie PHPa ( w sensie też samego silnika ) i jest on duuuuużo prostszy co w sumie
  • Odpowiedz
@uirapuru: Akurat tutaj bym sie zgodzil z @internet3000 - Od wersji 4 Symfony wydaje sie wreszcie doceniac swoje PHP-owe srodowisko, podczas gdy Laravel robil to od poczatku.

Wczesniej Symfony dzialalo na zasadzie "Przeniesmy wszystko co sie da z Javy". Sporo rzeczy bylo fajnych i profesjonalnych, ale niektore konieczne dla kompilowanego jezyka ze statycznym typowaniem byly troche na sile wprowadzane do PHP. Laravel od poczatku staral sie laczyc to co
  • Odpowiedz
@duncanidaho2: Po prostu PHP ma inne silne strony. Jak ktos chec programowac w PHP jak w Javie to rzeczywiscie bedzie to mordega. Podobnie jakby ktos chcialby uzywac PHP-owego sposobu piszac w Javie.
  • Odpowiedz
@be_a_st: Całkiem możliwe. Ja po prostu nie lubię domyślać się co dostanę na wejściu w metodzie. ;)

Po prostu PHP ma inne silne strony.


@be_a_st: Bez uszczypliwości, jakie to silne strony w samym języku (a nie w jego powszechności)?
  • Odpowiedz
@GratisLPG: Faktycznie, programy napisane w CPP są wolne od błędów, w tym od wycieków pamięci, przepełnienia buforu, przekroczenia zakresu, nawet nie ma sensu pisać testów jednostkowych, funkcjonalnych czy integracyjnych nie wspominając o przeprowadzaniu testów manualnych...
  • Odpowiedz
Jak dla mnie:

- Magiczne metody, http://php.net/manual/en/language.oop5.magic.php ktore umozliwiaja bardzo wiele (dlatego Active Record jest taki popularny w PHP)
- Zajebiste tablice
- Slabe typowanie gdy masz ochote z niego korzystac
- Typowe uzycie oznacza ze przy kazdym requescie WWW startujesz aplikacje, zamiast typowego podejscia z innych jezykow gdzie aplikacja caly czas dziala i realizuje kolejne requesty.
  • Odpowiedz
@GratisLPG: W PHP robi to Behat i PhpUnit, zależy na jakim etapie ( ͡° ͜ʖ ͡°)

To, że PHP ma taką łatkę to wina Januszyprogramistów15k, którzy w życiu testów na oczy nie widzieli. Tymczasem testowanie z PHP jest w dzisiejszych czasach ultra przyjemne. Testy Integracyjne w Behacie + Selenium to coś świetnego.
  • Odpowiedz
troche dzikie PHPowe podejscie - te wszystkie magiczne funkcje, brak koniecznosci pisania tyle kodu co Javie.


@be_a_st: "te wszystkie magiczne funkcje" to raczej nie jest zaleta, a wada ( ͡° ͜ʖ ͡°)

Zresztą co do funkcji magicznych odsyłam do wujka Boba, ma świetne wypowiedzi na ten temat ;)
  • Odpowiedz
@WydajnaJednostkaIndywidualna: Wujek Bob tez ma korzenie Javowskie. To takie troche narzekanie "bo to nie Java". PHP nigdy Java nie bedzie. Jak ktos woli pisac jak w Javie, to niech po prostu pisze w Javie zamiast narzekac ze PHP nie jest takie jak Java.

Niektorzy narzekaja ze testy to wada. Bo jak tu przetestowac jakis kod napisany 10 lat temu kiedy nikt o tym nie myslal? No tak, bo testy to
  • Odpowiedz