Temat: Za co się teraz zabrać?

Tomasz K.:

Mateusz Jaworski:
Grzebiąc w projektach open source można się przy okazji nauczyć bardzo wiele pod kątem "tak właśnie NIE powinno się robić" ;)

True story

To samo działa w odwrotną stronę: grzebiąc w projektach OS można nauczyć się bardzo wiele pod kątem "tak właśnie POWINNO się robić", a więc grzebiąc w OS można nauczyć się jak dobrze i jak źle robić.

Truizm :)

Tylko jak jesteś początkujący, nigdy nie wiesz, co z tego całego śmietnika jest dobre, a co złe. I to jest problem, który próbuję tutaj wytykać. Tak naprawdę zrobiła nam się wojna i odeszliśmy od głównego tematu. Ja nie neguję PHP jako języka, nadal go używam co jakiś czas, ale wiem z doświadczenia (a zajmowałem się przeróżnymi platformami i frameworkami), że PHP dla początkującego to średni wybór - chyba, że nie zależy mu na nauczeniu się dobrych rozwiązań.

Temat: Za co się teraz zabrać?

Jarek Żeliński:

Z biznesowego punktu widzenia nie ma absolutnie żadnego znaczenia, jakie wzorce zapakowałeś w swój soft.

ma, dobre wzorce (czyli dobre praktyki i sprawdzone rozwiązania) to oszczędność czasu i zdrowia a także zrozumienie większości frameworkow, uczenie się na własnych błędach to jedno a ignorowanie dorobku "dziedziny inżynierii" to drugie.

Stosowanie wzorców to aplikacje wymagające dużo na etapie tworzenia ale znacznie tańsze w utrzymaniu (a utrzymanie to stały rozwój i zmiany wymagań).

Zgadza się, ale napisałem z "bisnesowego punktu widzenia". Biznesu nie interesuje jak, ale na kiedy i dlaczego tak drogo ;) To, jak sobie zorganizujesz pracę wewnątrz zespołu wytwatarzającego oprogramowanie to Twoja broszka. Oczywist jest to, że stosowanie frameworków i wzorców obniży docelowo koszty, liczbę błędów, zwiększy jakoś produktu.

Temat: Za co się teraz zabrać?

Jacek Romanowski:

Dariusz Półtorak:
Tylko że w języku dynamicznie typowanym to może być zaleta. Np metoda może zwrócić chociażby 20 RÓŻNYCH obiektów które implementują ten sam interfejs.

Ależ w językach typowanych sygnatura metody jak najbardziej może opierać się na interfejsie, a nie klasie. Rzecz w tym, żeby go wymusić - przez przypadek nie przekażesz żadnego śmiecia... :)

Nom. Tylko że to zbędny wysiłek i zbędna komplikacja. W programowaniu nie ma "przypadków". Wszystko trzeba napisać. Komputer to nie człowiek. Odpal go 2x tak samo to zwróci Ci to samo.
No ale nie ma co filozofować. Wiadomo o co chodzi. Różnica polega na tym że w PHP robi się to o wiele prościej i przyjemniej.

Także dla mnie to ogromna zaleta w wielu wypadkach.

Oczywiście, że to może być zaleta, ale to może być też wada, zwłaszcza dla początkujących :)

Ale to akurat działa ze wszystkim. Daj laika do C# to też będzie robił głupoty. Bo i w C# i każdym innym języku głupoty możesz robić.

Kiedy mamy debugger. Sam to napisałeś. Spokojnie można je kontrolować poprzez DOBRE PRAKTYKI PROGRAMISTYCZNE i debuger. Do tego mam phpUnit do zabawy. Ten Twój nieszczęsny var_dump() i porządne IDE jak phpStorm które POTRAFI MI POKAZAĆ W TRYBIE DEBUGOWANIA co zawiera dana zmienna itp zwyczajnie najeżdżając myszką na zmienną w kodzie źródłowym... Żeby było śmieszniej mogę debugować kod na zdalnym serwerze. Żeby było jeszcze śmieszniej nic nie stoi na przeszkodzie by zmieniać wartości zmiennych w trakcie debugowania. Sam akurat jeszcze tego ostatniego nie robiłem ale z tego co widziałem - jest taka możliwość.

Właśnie, miliony IDE, każdy ma inne możliwości, różne sposoby debugowania... Już widzę, jak początkujący się w to zagłębia :) C# w zasadzie wymusza Visual Studio (które jest naprawdę świetne nawet w darmowej wersji Express) i problem wyboru i konfiguracji środowiska znika :)

No właśnie. I jak Ci Visual Studio nie podchodzi to właściwie jesteś w ciemnej dupie programistycznej. Dzisiaj dominują 3 IDE. Eclipse, Netbeans i phpStorm. I zasada jest debilnie prosta. ALBO firma uzgadnia w jakim środowisku się pracuje albo zawierza programiście i pozwala mu pracować w środowisku jakie preferuje.
Wybór środowiska to lepsze niż BRAK wyboru środowiska. Konfiguracja ? Jaka konfiguracja ? Na ogół są skonfigurowanie pod PHP i XDEBUG. Często też pod debugger Zenda. Same wykrywają co trzeba. Resztę jak kolorowanie, czcionki, odstępy, przedstawianie kodu, zachowanie kursora w edytorze itp możesz sobie ustawić jak Ci się podoba albo zostawić jak jest.

Także wybacz ale kontrola kodu i debugowanie to żaden problem.

Nie mówię, że się nie da - mówię, że nie ma tego out-of-the-box :)

I co to zmienia ? Jest ? Jest.

Temat: Za co się teraz zabrać?

Jacek Romanowski:

Tomasz K.:

Mateusz Jaworski:
Grzebiąc w projektach open source można się przy okazji nauczyć bardzo wiele pod kątem "tak właśnie NIE powinno się robić" ;)

True story

To samo działa w odwrotną stronę: grzebiąc w projektach OS można nauczyć się bardzo wiele pod kątem "tak właśnie POWINNO się robić", a więc grzebiąc w OS można nauczyć się jak dobrze i jak źle robić.

Truizm :)

Tylko jak jesteś początkujący, nigdy nie wiesz, co z tego całego śmietnika jest dobre, a co złe. I to jest problem, który próbuję tutaj wytykać. Tak naprawdę zrobiła nam się wojna i odeszliśmy od głównego tematu. Ja nie neguję PHP jako języka, nadal go używam co jakiś czas, ale wiem z doświadczenia (a zajmowałem się przeróżnymi platformami i frameworkami), że PHP dla początkującego to średni wybór - chyba, że nie zależy mu na nauczeniu się dobrych rozwiązań.

Ten sam problem będziesz miał w DOWOLNEJ innej technologii. Kod piszą ludzie, a nie maszyny i to z założenia powoduje że nawet najlepszy dev może strzelić babola. W każdym języku znajdziesz przykłady dobrych i złych praktyk. Może faktycznie w przypadku PHP jest trochę więcej złych przykładów, ale to ma też związek z powszechnością tego języka i IMO dość niskim progiem wejścia dla początkującego - nie musisz się zgodzić :).

Nie zgodzę się na pewno z tezą że w PHP nie ma dobrych przykładów. Bezbłędnie napisana aplikacja to utopia i w każdym oprogramowaniu znajdziesz coś do czego można się czepić.

Poza tym gdzie jest napisane, że dev musi się ograniczyć tylko do PHP? W codziennej robocie zawsze przyda się znajomość kilku innych języków bo nie wszystko osiagniesz PHP i czasem trzeba robić spinki w C# czy Pythonie.

Temat: Za co się teraz zabrać?

Dariusz Półtorak:

Jacek Romanowski:
Ależ w językach typowanych sygnatura metody jak najbardziej może opierać się na interfejsie, a nie klasie. Rzecz w tym, żeby go wymusić - przez przypadek nie przekażesz żadnego śmiecia... :)

Nom. Tylko że to zbędny wysiłek i zbędna komplikacja. W programowaniu nie ma "przypadków". Wszystko trzeba napisać. Komputer to nie człowiek. Odpal go 2x tak samo to zwróci Ci to samo.
No ale nie ma co filozofować. Wiadomo o co chodzi. Różnica polega na tym że w PHP robi się to o wiele prościej i przyjemniej.

Widzisz, tu właśnie jest błąd w Twoim podejściu. Wyobraź sobie, że nowy programista siada do Twojego projektu, w którym metoda abc() zwraca 3 różne typy i do tego nie wiadomo jakie. I teraz po pierwsze, musi on sam zajrzeć do kodu (albo dokumentacji) i go przeanalizować, by sprawdzić, co się może stać i co zostanie zwrócone, a po drugie, IDE nie będzie mu ładnie podpowiadać co może z wynikiem zrobić dalej. Dlatego grom programistów PHP stara się symulować statyczne typowanie z użyciem PHP doca, a środowiska takie jak Netbeans wykorzystują to nawet do generowania podpowiedzi (szkoda, że nieudolnie). Niestety, to jest dopiero dodatkowa robota, zwłaszcza że to są tylko hinty dla programisty, a nie dla interpretera PHP (i trzeba często robić sprawdzenie, czy zmienna jest może intem, a może obiektem jakiejś klasy..., aby się gdzieś skrypt nie wysypał).

To tyle odnośnie static vs dynamic typing :)

Dynamicznie jest super, pod warunkiem, że wiesz co robisz... Początkujący nie wie :)

Temat: Za co się teraz zabrać?

Jacek Romanowski:

Dariusz Półtorak:

Jacek Romanowski:
Ależ w językach typowanych sygnatura metody jak najbardziej może opierać się na interfejsie, a nie klasie. Rzecz w tym, żeby go wymusić - przez przypadek nie przekażesz żadnego śmiecia... :)

Nom. Tylko że to zbędny wysiłek i zbędna komplikacja. W programowaniu nie ma "przypadków". Wszystko trzeba napisać. Komputer to nie człowiek. Odpal go 2x tak samo to zwróci Ci to samo.
No ale nie ma co filozofować. Wiadomo o co chodzi. Różnica polega na tym że w PHP robi się to o wiele prościej i przyjemniej.

Widzisz, tu właśnie jest błąd w Twoim podejściu. Wyobraź sobie, że nowy programista siada do Twojego projektu, w którym metoda abc() zwraca 3 różne typy i do tego nie wiadomo jakie. I teraz po pierwsze, musi on sam zajrzeć do kodu (albo dokumentacji) i go przeanalizować, by sprawdzić, co się może stać i co zostanie zwrócone, a po drugie, IDE nie będzie mu ładnie podpowiadać co może z wynikiem zrobić dalej. Dlatego grom programistów PHP stara się symulować statyczne typowanie z użyciem PHP doca, a środowiska takie jak Netbeans wykorzystują to nawet do generowania podpowiedzi (szkoda, że nieudolnie). Niestety, to jest dopiero dodatkowa robota, zwłaszcza że to są tylko hinty dla programisty, a nie dla interpretera PHP (i trzeba często robić sprawdzenie, czy zmienna jest może intem, a może obiektem jakiejś klasy..., aby się gdzieś skrypt nie wysypał).

To tyle odnośnie static vs dynamic typing :)

Dynamicznie jest super, pod warunkiem, że wiesz co robisz... Początkujący nie wie :)

Z doświadczenia mogę powiedzieć, że:

1. początkujący programista PHP nie będzie się bawił z kodem obiektowym (większość tutoriali jest proceduralna)

2. początkujący programista nie czuje zbytnio pojęcia typów, dla niego "1" to po prostu liczba a nie string, int czy float i chce żeby to co robi ze zmienną, która zawiera tą wartość dawało oczekiwane efekty a nie błędy kompilatora :), dlatego też PHP jest bardzo dobrym językiem na początek, w momencie gdy początkujący zetknie się z pojęciem walidacji, wtedy zacznie się nad tym zastanawiać i zrozumie o co chodzi...

Temat: Za co się teraz zabrać?

Zamiast wymyślać za co się zabrać - zabierz się za coś komercyjnego. Cokolwiek. Klient Cię szybko nauczy co jest ważne.

Jak się nie pomylisz milion razy to się nie nauczysz.

Możesz też spróbować pracy jako wdrożeniowiec w jakiejś firmie od WWW. Ucz się w ogniu walki ;) Dział jakości takiej firmy sprawdzi Twoją pracę i powie Ci co robisz źle.

Temat: Za co się teraz zabrać?

Adam Piotrowski:

Mateusz Jaworski:
Grzebiąc w projektach open source można się przy okazji nauczyć bardzo wiele pod kątem "tak właśnie NIE powinno się robić" ;)

True story

Oj tam oj tam. Do tego przecież mamy phpclasses.org ;).

Już była kiedyś na ten temat obszerna dyskusja. Projekty OS nastawione na masowe wykorzystanie, najlepszy przykład to WordPress, muszą po prostu z góry zakładać ich wykorzystanie w najróżniejszych konfiguracjach. To oczywiście wiąże ręce i bardzo często konieczne są kompromisy i ustępstwa względem sztuki. W takich sytuacjach developer zawsze stanie przez pytaniem czy bawić się w artystę i robić zgodnie ze sztuką czy może zastosować sprawdzone (nie zawsze ładne) rozwiązanie.

Nie chodzi mi o "corowe" systemy open source, bardziej o rozszerzenia 3rdparty

Temat: Za co się teraz zabrać?

Wojciech Soczyński:

1. początkujący programista PHP nie będzie się bawił z kodem obiektowym (większość tutoriali jest proceduralna)

2. początkujący programista nie czuje zbytnio pojęcia typów, dla niego "1" to po prostu liczba a nie string, int czy float i chce żeby to co robi ze zmienną, która zawiera tą wartość dawało oczekiwane efekty a nie błędy kompilatora :), dlatego też PHP jest bardzo dobrym językiem na początek, w momencie gdy początkujący zetknie się z pojęciem walidacji, wtedy zacznie się nad tym zastanawiać i zrozumie o co chodzi...

No widzę, że argumenty w zasadzie przeciwko PHP, a nie za ;) Moim zdaniem rozsądniej jest zacząć programować w języku statycznie typowanym i przejść do dynamicznego, niż odwrotnie. I tak samo z programowaniem obiektowym. Przerabianie tych fatalnych tutoriali uczących programować proceduralnie to cofanie się. Do epoki innych wymagań, oczekiwań i możliwości technologicznych.

Temat: Za co się teraz zabrać?

Ja jeszcze dodam, że napisanie własnego FW, czy jakiegoś CMS-a albo innego tworu, wymiernie podnosi umiejętności programistyczne i przede wszystkim PROJEKTOWE, bo trzeba samemu ogarnąć jakąś większą całość. Sam pisałem swój FW i CMS i powiem, że bardzo wiele się dzięki temu nauczyłem, także dla celów dydaktycznych jest to naprawdę świetna sprawa :)

Dobra praktyka zeby cokolwiek sie nauczyc zobaczyc jak dziala i zdobyc doswiadczenie.

Początkującemu programiście wystarczy spokojnie var_dump, to raz. Dwa, że może teraz wyjdę na jakiegoś głupka/debila (nie potrzebne skreślić) ale przez 4 lata mojej profesjonalne kariery zawodowej używałem z powodzeniem var_dump i jakoś nie czułem potrzeby zmiany, bo po prostu działało :). 



Teraz co prawda używam debuggera i uważam, że to świetna rzecz, ale programuje w Javie, a tutaj po prostu inaczej się nie da (zwłaszcza przy projektach JEE).

Wystarczy dobrze zaimplementowany error i exception handler i zwykle print_r()/var_dump wystarcza ;) sam robie tak od zawsze i nie widze potrzeby debugowania kodu przynajmniej w php wystarcza dobre praktyki i juz 50% sukcesu otrzymane.

Ależ w językach typowanych sygnatura metody jak najbardziej może opierać się na interfejsie, a nie klasie. Rzecz w tym, żeby go wymusić - przez przypadek nie przekażesz żadnego śmiecia... :)

Jakiego smiecia w php tez mozesz wymusic interfejs/klase na argumencie tak samo jak i tablice od od php 5.4 czy troche wyzej maja wprowadzic wlasnie typowanie dla typow prostych o ile mnie pamiec nie myli.

PHP w reku kogos kto wie co robi nie jest zle sam od kilku dni kodze w django bo php poprostu mnie juz znudzilo a python jako jezyk jest o wiele ciekawszy i oferuje duzo fajnych rzeczy nie wspominajac juz o tym ze pisanie w django a symfony to calkiem inna bajka zamiast tracic czas na pisanie 30 plikow konfiguracyjnych jakis dekoratorow i walidatorow django robi to za nas wystarczy wiedziec jak to dziala.

Temat: Za co się teraz zabrać?

Jacek Romanowski:

Wojciech Soczyński:

1. początkujący programista PHP nie będzie się bawił z kodem obiektowym (większość tutoriali jest proceduralna)

2. początkujący programista nie czuje zbytnio pojęcia typów, dla niego "1" to po prostu liczba a nie string, int czy float i chce żeby to co robi ze zmienną, która zawiera tą wartość dawało oczekiwane efekty a nie błędy kompilatora :), dlatego też PHP jest bardzo dobrym językiem na początek, w momencie gdy początkujący zetknie się z pojęciem walidacji, wtedy zacznie się nad tym zastanawiać i zrozumie o co chodzi...

No widzę, że argumenty w zasadzie przeciwko PHP, a nie za ;) Moim zdaniem rozsądniej jest zacząć programować w języku statycznie typowanym i przejść do dynamicznego, niż odwrotnie. I tak samo z programowaniem obiektowym. Przerabianie tych fatalnych tutoriali uczących programować proceduralnie to cofanie się. Do epoki innych wymagań, oczekiwań i możliwości technologicznych.

Wszystko zależy od indywidualnych preferencji, ja opisałem jak to u mnie wyglądało. To podejście zdało w moim przypadku egzamin, czy zda w innym to zależy od przypadku.

Dla jednego 20 stopni to upał, dla innego chłodnia :p

Temat: Za co się teraz zabrać?

Jacek Romanowski:

Dariusz Półtorak:

Jacek Romanowski:
Ależ w językach typowanych sygnatura metody jak najbardziej może opierać się na interfejsie, a nie klasie. Rzecz w tym, żeby go wymusić - przez przypadek nie przekażesz żadnego śmiecia... :)

Nom. Tylko że to zbędny wysiłek i zbędna komplikacja. W programowaniu nie ma "przypadków". Wszystko trzeba napisać. Komputer to nie człowiek. Odpal go 2x tak samo to zwróci Ci to samo.
No ale nie ma co filozofować. Wiadomo o co chodzi. Różnica polega na tym że w PHP robi się to o wiele prościej i przyjemniej.

Widzisz, tu właśnie jest błąd w Twoim podejściu. Wyobraź sobie, że nowy programista siada do Twojego projektu, w którym metoda abc() zwraca 3 różne typy i do tego nie wiadomo jakie. I

Ty na prawdę przyszedłeś do działu o PHP żeby nawracać do C# ?? Poważnie ? Bo szukasz dziury w całym.
1. Pracując przy JAKIMKOLWIEK dużym projekcie, niezależnie czy to C#, C++, PHP, Java czy cokolwiek innego pracę ZACZYNASZ OD DOKUMENTACJI i kończysz ją sporządzając dokumentację. Dlaczego ? Bo często nie będziesz pracował w swoim kodzie. Poczytaj sobie blogi programistów FB dla przykładu.
2. Od razu wiem jakie typy zwraca dana metoda bo to KAŻDA NIEJASNOŚĆ powinna być opisana w phpDoc. A robi się to dziecinnie prosto:

@return Foo | Bar

Mało tego. Jak ktoś wpadnie na "genialny" pomysł że metoda może zwrócić obiekt Foo albo tablicę obiektów Bar to na to również jest sposób:

@return Foo | Bar[]

i IDE będzie podpowiadać prawidłowo w zależności od kontekstu w jakim użyjemy zmienną.

teraz po pierwsze, musi on sam zajrzeć do kodu (albo dokumentacji) i go przeanalizować, by sprawdzić, co się może stać i co zostanie zwrócone, a po drugie, IDE nie będzie mu ładnie podpowiadać co może z wynikiem zrobić dalej. Dlatego

Źle. IDE będzie nadal podpowiadać. Od tego jest phpDoc. Nic nie trzeba analizować. Nie trzeba tracić czasu.Nie trzeba robić nic. Po prostu z pomocą prostego wpisu phpDoc który programista ma zrobić IDE będzie w pełni podpowiadać. Nawet dokumentacji nie trzeba.

grom programistów PHP stara się symulować statyczne typowanie z użyciem PHP doca, a środowiska takie jak Netbeans wykorzystują to nawet do generowania podpowiedzi (szkoda, że nieudolnie).

Źle. Nie symulują niczego. Po prostu dają informację co zwraca dana metoda jeżeli z jakiegoś powodu jest to niejasne.

Niestety, to jest dopiero dodatkowa robota, zwłaszcza że to są tylko hinty dla programisty, a nie dla interpretera PHP (i trzeba często robić sprawdzenie, czy zmienna jest może intem, a może obiektem jakiejś klasy..., aby się gdzieś skrypt nie wysypał).

Znowu źle. Tą samą robotę robiłem jak pisałem w C++ czy w Javie. Parametry trzeba opisać tak czy siak. phpDoc to właściwie to samo co javaDoc itp. Praktycznie się nie różni. Każdy normalny projekt ma tego typu komentarze. Każda normalna klasa. Różnica polega na tym że IDE w PHP wykorzystują je żeby podpowiadać tam gdzie nie idzie wyczaić typu z kodu źródłowego.
Jeżeli tego jeszcze nie robisz to po prostu musisz się tego nauczyć. Bywa. Dokumentowanie kodu nie jest zależne od języka w żadnym wypadku.

To tyle odnośnie static vs dynamic typing :)

Niewiele...

Dynamicznie jest super, pod warunkiem, że wiesz co robisz... Początkujący nie wie :)

Dlatego jest początkujący. C# też ma swoje do nauczenia. Tak samo jak C++ i Java. Niepokierowany początkujący programista nauczy się głupot w każdym języku. Po prostu w PHP nauczy się kilku takich jakich nie widział w innych językach.Dariusz Półtorak edytował(a) ten post dnia 15.03.12 o godzinie 15:58

Temat: Za co się teraz zabrać?

@Dariusz - niezbyt utopijnie?

Ostatnio pracuję z kodem, który albo nie ma w ogóle komentarzy, albo ma błędne - muszę analizować co się dzieje, inaczej się nie da...
O dokumentacji tego mogę pomarzyć, bo albo nie ma albo ma się nijak do faktycznego stanu.
Więc dla mnie opisywana przez ciebie sytuacja jest... marzeniem :D

Obawiam się że w innych językach, początkujący będzie mógł nauczyć się więcej głupot niż w PHP'ie - choćby z racji tego że będzie miał więcej możliwości :D

@Jacek Romanowski
Bajdurzysz.

Dobre ide w większości przypadków będzie w stanie określić zwracany na podstawie kodu typ.
phpDoc będzie wykorzystywany jako uzupełnienie, szczególnie w oczywistych przypadkach gdzie nie jest jawnie podany a jest wynikiem działania (np. DI Container).

Co więcej, sporo IDE będzie w stanie znaleźć rozbieżności między komentarzem w phpDoc a faktycznymi typami parametrów czy typem zwracanym i zasygnalizować to.

Wracając do dziwnego przykładu.
Co on ma obrazować?
Ani C#, ani PHP przed głupotą się nie obroni.
W obu da się napisać wywołanie funkcji/metody podając int'y zamiast float'ów, czy obiekty zamiast string'ów.
Różnica jest taka, że PHP przełknie pewne przypadki, C# już niekoniecznie.

Temat: Za co się teraz zabrać?

Dariusz Półtorak:

Jarek Żeliński:

pisać od zera własnego CMS-a, własnego frameworka czy sklep.

też tego nie rozumiem...

Allegro, FB, NK i wiele innych.

:)
jeżeli problem -> próg opłacalności (budżet) na projekt jest nie duży, to żaden od zera tworzony bajer nie ma sensu, każdy z nas może sobie zamówić frak i krawca ale raczej kupujemy gotowe garnitury, mimo tego, ze zawsze celem jest "ubrać się"....

Temat: Za co się teraz zabrać?

Dariusz Półtorak:
Jeżeli masz doświadczenie z C++, Javą czy chociażby nieszczęsnym C# od którego radzę się trzymać z daleka (uzależnisz się od platformy a to najgorsze co można zrobić) to będziesz wiedział co jest złą a co jest dobrą praktyką.
Jeżeli zaczniesz od PHP to bez kogoś kto pokieruje Tobą na początku i wytłumaczy zasady możesz źle skończyć.

Nie mam doświadczenia z innymi, nie bardzo mam kogoś kto by mną pokierował.

Dariusz Półtorak:
Na pewno nie porzucał bym PHP jeżeli chcesz zająć się aplikacjami i stronami www. Haterzy mogą sobie mówić co chcą ale prawda jest taka że PHP jest bardzo elastyczne, bardzo popularne i ogólnie rzecz biorąc - dobre. Więc co robić ?

~ wiadomo, musisz poznać PHP
~ polecam tą książkę: http://helion.pl/ksiazki/php-i-mysql-tworzenie-stron-w...
~ zapoznaj się z tematem OOP (będzie również w książce troszkę na ten temat choć podstawy) i wzorców projektowych
~ zapoznaj się z systemami kontroli wersji GIT i SVN
~ rozbierz jakieś projekty i poznawaj rozwiązania
~ zatrudnij się w jakiejś firmie gdzie panuje jakiś konkretny poziom - sporo się nauczysz
~ programuj

Tak jak napisałeś chciałbym zająć się aplikacjami i stronami www.

Jeśli chodzi o książkę z której czerpałem wiedzę to:
http://helion.pl/ksiazki/head-first-php-mysql-edycja-p...

Wojciech Soczyński:
Natomiast, jeżeli chciałbym odpowiedzieć na pytanie postawione w tytule tego postu - "Za co się teraz zabrać" to powiedziałbym, że aby się rozwijać w programowaniu trzeba dużo programować. Problemów do rozwiązania jest wiele. Tak jak powiedział, któryś z przedmówców, możesz napisać sobie swój sklep internetowy, możesz też spróbować szukać jakiś prostych zleceń np. pisanie template'ów do wordpressa, albo też spróbować dostać się gdzieś na praktykę / staż.

Również bym chciał przyjąć się na praktykę lub staż, ale teraz to chyba raczej za wcześnie (kto by mnie przyjął?).
Moim zdaniem właśnie jak pisałeś powinienem mieć kogoś kto by mnie poprowadził, mówił co mam zrealizować.

Temat: Za co się teraz zabrać?

Kolega, trochę przesadzasz. Doskonale znam narzędzia do dokumentowania kodu. I tak jak pisałem, PHPdoc *jest* używany również jako symulowanie statycznego typowania.

Dariusz Półtorak:
2. Od razu wiem jakie typy zwraca dana metoda bo to KAŻDA NIEJASNOŚĆ powinna być opisana w phpDoc. A robi się to dziecinnie prosto:

@return Foo | Bar

Świetnie, właśnie zadeklarowałeś typy, jakie zwraca metoda. W Javie czy C# tego się nie robi, bo typ jest określony w sygnaturze metody. W PHP wpisujesz typ bo... nigdzie indziej go wpisać nie możesz. I tak, wypada to zrobić na potrzebę dokumentacji. Ale w języku statycznie typowanym zostanie to wyjęte automatycznie, nie podaje się tego "dodatkowo", a tag @return służy do OPISANIA co jest zwaracane, a nie jaki jest tego typ.

Źle. IDE będzie nadal podpowiadać. Od tego jest phpDoc. Nic nie trzeba analizować. Nie trzeba tracić czasu.Nie trzeba robić nic. Po prostu z pomocą prostego wpisu phpDoc który programista ma zrobić IDE będzie w pełni podpowiadać. Nawet dokumentacji nie trzeba.

No właśnie, parę postów wyżej pisałeś, że:

string nazwaMetody()

{...}

to nadmierne komplikowanie, a teraz piszesz, że:

/**

 * @return string

 */

function nazwaMetody()

{...}

jest w porządku i każdy powinien robić... :) Nie będę wskazywać, co ma mniej znaków i jest czytelniejsze :) Poza tym, widzisz, to jest pomoc dla programisty, pod warunkiem, że sobie to dopisze! PHP tego nie wymaga i początkujący programista się tego nie nauczy. Język statycznie typowany wymusi na nim podawanie typów i nauczy zachowywać porządek.

Znowu źle. Tą samą robotę robiłem jak pisałem w C++ czy w Javie. Parametry trzeba opisać tak czy siak. phpDoc to właściwie to samo co javaDoc itp. Praktycznie się nie różni.

Dokładnie, opisywać. W swoich przykładach nie zrobiłeś opisu, tylko podałeś, co metoda zwraca. Opis wyglądałby tak (z opisu JavaDoc ze strony Oracle, zauważ BRAK podania typu):

 * @return      the image at the specified URL

Każdy normalny projekt ma tego typu komentarze. Każda normalna klasa. Różnica polega na tym że IDE w PHP wykorzystują je żeby podpowiadać tam gdzie nie idzie wyczaić typu z kodu źródłowego.

Nie każdy, bo przy statycznym typowaniu *takie* komentarze nie są w ogóle potrzebne :)

Jeżeli tego jeszcze nie robisz to po prostu musisz się tego nauczyć. Bywa. Dokumentowanie kodu nie jest zależne od języka w żadnym wypadku.

Oczywiście, że jest - zależy od tego, jak wiele narzędzie do dokumentowania kodu jest w stanie wyciągnąć z kodu samego w sobie. W przypadku PHP może wyciągnąć bardzo mało, stąd w PHPdoc musisz wpisywać więcej rzeczy, żeby dokumentacja miała ręce i nogi :)

Temat: Za co się teraz zabrać?

O! Flame! How much blood will you shed to show that mothacoders their language is wrong?!Łukasz K. edytował(a) ten post dnia 15.03.12 o godzinie 17:19

Temat: Za co się teraz zabrać?

No, ja już kończę dyskusję, bo straszna wojna się wywołała, a jesteśmy po tej samej stronie. Szkoda, że większość odbiera to jako atak, że piszę o PHP jako zbyt liberalnym języku dla początkujących. Kolejno koledzy Dariusz czy Michał wypisują, że wszystko da się w PHP zrobić, kiedy nie jest problemem to, że się nie da, tylko to, że nie jest to wymuszone przez język, który nie pilnuje programisty. Ot cały problem.

Chcesz się uczyć PHP - warto mieć dobrego nauczyciela, który będzie pilnować.

Chcesz się uczyć języka statycznie typowanego - kompilator i język sam w sobie mocno cię przypilnuje.

Ot, cała różnica, którą chciałem tu przedstawić.Jacek Romanowski edytował(a) ten post dnia 15.03.12 o godzinie 17:27

Temat: Za co się teraz zabrać?

Kiedy własnie całość sprowadza się do tego że "wymuszenie przez język" wcale nie jest takie dobre :P Dla początkującego programisty to zaleta. Ci bardziej zaawansowani już robią cuda (zwłaszcza w C++) żeby obejść wiele problemów które koniec w końcu statyczne typowanie stwarza. Uciekając się nieraz do dość brudnych zagrywek.
Kiedy parałem się w C++ dużo takich "kwiatków" poznałem.

Ale zgadzam się że nauka programowania od PHP to marny pomysł jeżeli nikt nami nie kieruje. Dynamiczne typowanie to niewątpliwa zaleta PHP która w nieodpowiednich rękach jest sporą wadą.

PS: "string nazwaMetody()" -- wróć do mojego postu i przeczytaj go jeszcze raz bo chyba nie do końca zrozumiałeś o co mi chodziło.

Temat: Za co się teraz zabrać?

Obawiam się Jacku że nie masz racji.

W czasach gdy zaczynałem cokolwiek z programowaniem, do dyspozycji miałem tylko dosowe narzędzia firmy Borland - czyli dawno :)

Jakoś nie przypominam sobie, że mnie młodego szczyla w jakiś cudowny magiczny sposób napisanie void czy string przed słowem function chroniło przed popełnianiem błędów podczas odwoływania się do funkcji/metody czy przy przekazywaniu parametrów.

Po wielu latach wracając do C++, używając dzisiejszych IDE nadal nie jestem zmuszany. Jedynie informuje że jestem ciołkiem i piszę nieuważnie.
Ale to robi IDE, nie język. A IDE jest takie jakie sobie wybierzesz lub firma ci narzuci.
Język wymusza tylko taki a nie inny zapis a głupota i nieuwaga nie jest przypisana do konkretnego języka.

Ja się odcinam od dalszej dyskusji i poświęcę się wykonywaniu NOP :)Michał Wachowski edytował(a) ten post dnia 15.03.12 o godzinie 17:51