Jak w temacie :) Co polecacie? Miałem jakąś tam styczność z html, troche z c++, na poważne chcę się zająć teraz PHP? Jakie kursy polecacie? Darmowe/płatne? Książki/wydania online? Z góry dzięki za odpowiedź :)

http://phpkurs.pl/ ten chyba jest prosty i przystępny dla początkującego

echo "To jest $druga_nazwa";

Nadaje się do kategorii "Jak nauczyć newbie pisać dziurawe aplikacje".

Początkujący zdecydowanie powinni wystrzegać się tej konstrukcji. Może i jest nieco szybsza i nieco wygodniejsza, ale mimo wszystko, zupełnie niepodobna do tego, co oferują poważne języki programowania. Po prostu uczy złych nawyków.

Jak pamiętam to PHP uczyłem się poprzez darmowe kursy online.
Niestety jest w nich pełno kruczków podobnych do

echo "Cokolwiek $zmienna";

o którym wspomniał Demonical Monk.

Poszperałem i wydaje mi się, że na sam początek nauki wystarczy to:
http://webhosting.pl/Kurs.PHP..Wstep.do.programowania.w.popularnym.jezyku.skryptowym

Co prawda tutaj jest sucha wiedza, bez przykładów wykorzystania.
Można szukać przykładów, gotowych skryptów, lecz wg mnie lepiej wziąć się za pisanie chociażby swojej strony.
Uczysz się wtedy pisania, a nie przepisywania gotowych skryptów ze stron.
Co prawda z początku będzie Ci ciężko... ale myślę, że z odpowiednim zapałem dasz radę.

W razie czego jest google i forum.

Można z powodzeniem tworzyć dynamiczne strony internetowe w innych językach.

echo "To jest $druga_nazwa";

no niestety takiego stylu to uczą w większości książek od PHP

Hosting Javy, JRuby, Scali, Pythona jest za darmo na Google App Engine.

Na początek Python jest raczej OK, a używa się go w bardzo wielu dziedzinach.

Do języka C są biblioteki "intraweb" do błyskawicznego tworzenia aplikacji internetowych z minimalną potrzebą znajomości html, java script, ajax.

Po pierwsze - dla C++, nie dla C; po drugie - nikt poważny IntraWeb nie używa.

deus napisał(a)

Po pierwsze - dla C++, nie dla C; po drugie - nikt poważny IntraWeb nie używa.

Dopóki mi aplikacja działa w 100% nie muszę uczyć się czterech innych języków do budowy front-end'u i to jest bardzo pomocne. W USA można nawet sprzedawać takie aplikacje za duże pieniądze. Każdy kompilator powinien mieć takie biblioteki do html, żeby nie trzeba było składać kodu html ręcznie, po kawałku.

Znane podejście typu: "Ważne że działa"...
Składanie kodu ręcznie po kawałku? System szablonów, dzięki dobranoc.

Nie musisz się uczyć języków do budowy front-endu? Sorry, ale to śmierdzi groźbą posiadania lamerskiego kodu. Czy nie dbanie o to, jak będzie wyglądał wysyłany do użytkowników kod aplikacji jest profesjonalne? Czy może nieprofesjonalne?

I czy wygenerowany automatycznie HTML, CSS i JavaScript faktycznie będą dobre? Jeśli generator jest dobry, to aplikacja będzie działała w różnych przeglądarkach. Ale co z szybkością? Co z rozmiarem plików frontendowych? Co z zasadą progresywnego wzbogacania i dostępnością -- czy o to też dba generator?

Czy dba o semantykę HTML-a? Jak taka aplikacja będzie indeksowana przez roboty wyszukiwarek? Jak będzie odczytywana przez czytniki ekranu? Sprawdzałeś to, czy masz to gdzieś? I czy to jest profesjonalne?

Widziałem różne generatory kodu HTML. Od słabych (wyraźnie słabszych od kodu robionego ręcznie), po beznadziejne. Zarzuć jakimś linkiem do strony, która korzysta z tego czegoś dla C++ to zobaczymy, jakie są efekty. Może tylko wydaje Ci się, że to działa, a tak naprawdę w wyszukiwarkach jest dużo gorzej niż mogło być, a strona wczytuję się dwukrotnie wolniej niż by mogła. To wszystko przekłada się oczywiście na zmniejszenie zysków.

Można by powiedzieć, że zatrudnienie słabszego zespołu developerów, o mniejszych kompetencjach (tj. nie znających podstawowych języków frontendowych) powodowałoby przynajmniej spadek kosztów. Coś za coś: niższa jakość, ale mniejszy koszt stworzenia aplikacji. Ale piszesz, że te aplikacje można sprzedawać i za duże pieniądze. Czyli co? Sprzedawanie szmelcu na jednej, ważnej warstwie w cenie normalnej, dopracowanej aplikacji? Mało chwalebne, mało profesjonalne. No chyba że generowany kod jest faktycznie dobry -- wtedy nie ma się o co martwić. Dlatego chętnie na niego zerknę.

@bswierczynski, IntraWeb to biblioteka głównie do Delphi, wspierana też przez borlandowskiego C++ Buildera. Takie klocki do robienia stron, taki 'FrontPage dla użytkowników Delphi', pozwalający robić szybko webowe frontendy dla softu po stronie serwera - najczęściej SaaS. Podobno fajne do momentu, kiedy trzeba zrobić coś więcej niż oferują klocki, przynajmniej takie opinie słyszałem. Kodu html/js generuje gigantyczne ilości, z wyglądu syf przy którym FrontPage to profesjonalne narzędzie...

@Mariusz Jędrzejowski, pokaż jakiś duży serwis, który tego używa. Kiedyś odpytałem sporo popularnych serwisów (wedle rankingów międzynarodowych, nie lokalnych) i niczego przedstawiającego się jako serwer z IntraWeb nie widziałem (IIS do którego IntraWeb może być pluginem powinien chyba podać w nagłówku, że to strona renderowana IntraWebem, prawda?).

Programując pod GWT i pochodne nie trzeba znać HTML i JavaScript :) Pewnie nawet do CSS są jakieś wtyczki.

http://vaadin.com/demo

Demonical Monk napisał(a)

echo "To jest $druga_nazwa";

Nadaje się do kategorii "Jak nauczyć newbie pisać dziurawe aplikacje".

A co jest w tym dziurawego? Możesz rozwinąć swoją wypowiedź?

Sprawa polega na tym, że składając stronę w html "ręcznie" mamy zawsze możliwość robienia poprawek. Zdarza się na przykład że kod html nie działa z nową przeglądarką i trzeba go dostosować. Przy ręcznym składaniu kodu mamy do niego dostęp i możemy to zrobić. Przy użyciu bibliotek intraweb mamy minimalny wpływ na kod html i może się zdarzyć że nie damy rady zrobić jakiejś drobnej czy większej poprawki dopóki producent tej biblioteki ich nie poprawi. Profesjonaliści nie chcą jednak żeby na przykład 2% kodu nie działało i są w stanie opanować technologie "niskopoziomowe" składania ręcznego kodu, żeby uniknąć takich sytuacji, czyli nauczą się olbrzymich ilości dodatkowych informacji i języków programowania, żeby te 2% problemów wyeliminować i żeby wszystko było cacy.

Jednak ja nie mam aż takich wymagań i dopóki moja strona intraweb jest w pełni funkcjonalna, to to mi wystarcza, bo dzięki temu nie muszę się uczyć rzeczy, które mnie nie interesują i mogę się skupić na uczeniu się czegoś innego.

W sumie dobre podejście, ale HTML + CSS + obrazki to działka grafika, a nie programisty tak czy siak.

Gościu napisał(a)

A co jest w tym dziurawego? Możesz rozwinąć swoją wypowiedź?

W tym kawałku kodu nie musi być nic dziurawego. Gorzej, jeśli w ten sposób wypisze się jakiś parametr wejściowy bez unieszkodliwienia. Np.:

$searchQuery = $_GET['q'];
// ...
echo "Nie znaleziono wyników dla frazy $searchQuery";

(ew. można wstawić $_GET bezpośrednio w łańcuch znaków)

Takie wyświetlanie niefiltrowanych danych jest bardzo niebezpieczne. I dotyczy nie tylko wyświetlania postów, które są widoczne dla wszystkich, ale nawet takich dupereli jak formularz wyszukiwania. Jakiś gnojek może bowiem dać ofierze specjalnie spreparowany link, w którym za parametr q zostanie podany skrypt JavaScript. Skrypt ten zostanie odpalony przez przeglądarkę ofiary, na jej koncie na danym serwisie, ze wszystkimi uprawnieniami. Skrypt może odczytać np. cookies (z danymi weryfikacyjnymi) i przesłać ich zawartość do serwera napastnika.

I jeszcze inna sprawa... Zobacz na takie coś:

echo "Pod etykietą $label masz zapisany numer {$numberMap[$label]}";

Czy to odwołanie na końcu stringa jest prawidłowe, czy nie? A gdyby konstrukcja była bardziej skomplikowana? Twój edytor by to dobrze pokolorował?

A co jeśli musiałbyś odwołać się do metody? Jeśli chciałbyś wypisać $product->getPriceAfterDiscount()? Czy to też wstawisz w string i czy wtedy będzie to czytelne? A może część odwołań do zmiennych wstawisz do wnętrza stringa, a część będziesz wypisywał wychodząc na chwilę ze stringa? Wtedy dopiero będziesz miał jednolity, spójny standard kodowania ;).

Umieszczając zawsze odwołania do zmiennych poza stringami nie będziesz miał takich kłopotów. Zawsze będziesz robił to samo i będzie to dokładnie to, co zrobiłbyś w innych językach programowania.

donki7 napisał(a)

W sumie dobre podejście, ale HTML + CSS + obrazki to działka grafika, a nie programisty tak czy siak.

Niekoniecznie. Mało który grafik jest dobrym koderem HTML i CSS. Zgodzę się, że kodowanie HTML-a i CSS samo w sobie troszkę trudno nazwać programowaniem pełną gębą. Ale żeby zrobić to dobrze, trzeba dysponować inżynierską wiedzą. Trzeba wiedzieć, jak działają przeglądarki i w jaki sposób wykonywane są żądania. Trzeba wiedzieć, czemu ich liczbę należy minimalizować. Trzeba mieć pojęcie o semantyce i działaniu robotów wyszukiwarek (czemu

Foo

Wreszcie, mamy JavaScript. Język typowo programistyczny, w dodatku dość ciężki do nauczenia i często nierozumiany, bo jest inny od innych (dziedziczenie prototypowe, funkcyjność). Nie zawsze wystarczy napisanie paru linijek w jQuery. Zleciłbyś grafikowi wykonanie choćby trochę skomplikowanych skryptów? Jaką by ten kod miał jakość, skoro programiście nauczenie się uniwersalnych zasad tworzenia kodu wysokiej jakości zajmuje LATA?

I teraz ta część zabawna: JavaScript jest powiązany z CSS i HTML-em. Jeśli chcesz zrobić to dobrze, powinieneś panować nad tym wszystkim. Albo przynajmniej osoba pisząca HTML (i CSS) powinna wiedzieć jak pisać kod, z którym może potem współpracować JavaScript. W przypadku techniki nieinwazyjnego JavaScriptu (unobtrusive JavaScript) i rozdzielenia warstw (struktura, prezentacja, zachowanie) poszczególne warstwy są od siebie niezależne, ale wszystkie muszą być zrobione PORZĄDNIE. Bo gdy koder HTML oleje trochę semantykę i zrobi coś tak, by łatwiej było mu to było ostylować w CSS, to jest spora szansa, że taki pokraczny i semantycznie bezsensowny kod HTML wybitnie utrudni napisanie nakładki w postaci skryptów.

@Mariusz Jędrzejowski:
Ja w ogóle raczej nie uczestniczę w projektach, w których praktycznie cały interfejs poskładany był z klocków. U mnie wszystko jest szyte na miarę pod danego klienta i jego potrzeby (i w bardzo dużej części: pod potrzeby jego klientów). Bardzo duże znaczenie mają również kwestie brandingu.

Dlatego pomimo tego, że komponenty po stronie serwera często się powtarzają, to jednak ich wygląd zmienia się dość znacznie od aplikacji do aplikacji. I dosyć często wprowadzane są pewne modyfikacje, np. dodanie jakiegoś pola czy cechy do danego elementu. Zmieniają się proporcje, wymiary, kolory i look'n'feel. Dotyczy to również przycisków, pokazów slajdów, menu nawigacyjnego -- praktycznie wszystkiego.

Spróbuj to złożyć z gotowych klocków, bez ręcznego modyfikowania HTML-a/CSS/JS-u (HTML bywa często używany ponownie, pozostałe rzeczy -- szczególnie CSS -- rzadziej).

I tu właśnie chodzi o tą problematykę, nauczymy się:

echo("Nick: $nick.");

To zaraz pomyślimy że z tablicą też zadziała:

echo("Nick: $data['nick'].");

Zonk, nie działa. "Czemu mi skrypt nie hodźi?????"

Pomylą się cudzysłowy z apostrofami:

echo('Nick: $nick');

"PHP sie popsuło, nie pokazuje zmiennych"

Kiedy pomyśli sobie że to ograniczenia ze strony PHP, to każde jego następne echo będzie wyglądało tak:

$cena = Shop::afterDiscount($this->type, $this->price);
echo "Cena: $cena";

I robi się kaszana.

bswierczynski napisał(a)

Gościu napisał(a)

A co jest w tym dziurawego? Możesz rozwinąć swoją wypowiedź?

W tym kawałku kodu nie musi być nic dziurawego. Gorzej, jeśli w ten sposób wypisze się jakiś parametr wejściowy bez unieszkodliwienia. Np.:

$searchQuery = $_GET['q'];
// ...
echo "Nie znaleziono wyników dla frazy $searchQuery";

(ew. można wstawić $_GET bezpośrednio w łańcuch znaków)

Takie wyświetlanie niefiltrowanych danych jest bardzo niebezpieczne. I dotyczy nie tylko wyświetlania postów, które są widoczne dla wszystkich, ale nawet takich dupereli jak formularz wyszukiwania. Jakiś gnojek może bowiem dać ofierze specjalnie spreparowany link, w którym za parametr q zostanie podany skrypt JavaScript. Skrypt ten zostanie odpalony przez przeglądarkę ofiary, na jej koncie na danym serwisie, ze wszystkimi uprawnieniami. Skrypt może odczytać np. cookies (z danymi weryfikacyjnymi) i przesłać ich zawartość do serwera napastnika.

I jeszcze inna sprawa... Zobacz na takie coś:

echo "Pod etykietą $label masz zapisany numer {$numberMap[$label]}";

Czy to odwołanie na końcu stringa jest prawidłowe, czy nie? A gdyby konstrukcja była bardziej skomplikowana? Twój edytor by to dobrze pokolorował?

A co jeśli musiałbyś odwołać się do metody? Jeśli chciałbyś wypisać $product->getPriceAfterDiscount()? Czy to też wstawisz w string i czy wtedy będzie to czytelne? A może część odwołań do zmiennych wstawisz do wnętrza stringa, a część będziesz wypisywał wychodząc na chwilę ze stringa? Wtedy dopiero będziesz miał jednolity, spójny standard kodowania ;).

Umieszczając zawsze odwołania do zmiennych poza stringami nie będziesz miał takich kłopotów. Zawsze będziesz robił to samo i będzie to dokładnie to, co zrobiłbyś w innych językach programowania.

donki7 napisał(a)

W sumie dobre podejście, ale HTML + CSS + obrazki to działka grafika, a nie programisty tak czy siak.

Niekoniecznie. Mało który grafik jest dobrym koderem HTML i CSS. Zgodzę się, że kodowanie HTML-a i CSS samo w sobie troszkę trudno nazwać programowaniem pełną gębą. Ale żeby zrobić to dobrze, trzeba dysponować inżynierską wiedzą. Trzeba wiedzieć, jak działają przeglądarki i w jaki sposób wykonywane są żądania. Trzeba wiedzieć, czemu ich liczbę należy minimalizować. Trzeba mieć pojęcie o semantyce i działaniu robotów wyszukiwarek (czemu

Foo

jest dobre, a

Foo

jest bezużyteczne?). Ciągle trzeba czytać specyfikacje techniczne.</p>

Wreszcie, mamy JavaScript. Język typowo programistyczny, w dodatku dość ciężki do nauczenia i często nierozumiany, bo jest inny od innych (dziedziczenie prototypowe, funkcyjność). Nie zawsze wystarczy napisanie paru linijek w jQuery. Zleciłbyś grafikowi wykonanie choćby trochę skomplikowanych skryptów? Jaką by ten kod miał jakość, skoro programiście nauczenie się uniwersalnych zasad tworzenia kodu wysokiej jakości zajmuje LATA?

I teraz ta część zabawna: JavaScript jest powiązany z CSS i HTML-em. Jeśli chcesz zrobić to dobrze, powinieneś panować nad tym wszystkim. Albo przynajmniej osoba pisząca HTML (i CSS) powinna wiedzieć jak pisać kod, z którym może potem współpracować JavaScript. W przypadku techniki nieinwazyjnego JavaScriptu (unobtrusive JavaScript) i rozdzielenia warstw (struktura, prezentacja, zachowanie) poszczególne warstwy są od siebie niezależne, ale wszystkie muszą być zrobione PORZĄDNIE. Bo gdy koder HTML oleje trochę semantykę i zrobi coś tak, by łatwiej było mu to było ostylować w CSS, to jest spora szansa, że taki pokraczny i semantycznie bezsensowny kod HTML wybitnie utrudni napisanie nakładki w postaci skryptów.

@Mariusz Jędrzejowski:
Ja w ogóle raczej nie uczestniczę w projektach, w których praktycznie cały interfejs poskładany był z klocków. U mnie wszystko jest szyte na miarę pod danego klienta i jego potrzeby (i w bardzo dużej części: pod potrzeby jego klientów). Bardzo duże znaczenie mają również kwestie brandingu.

Dlatego pomimo tego, że komponenty po stronie serwera często się powtarzają, to jednak ich wygląd zmienia się dość znacznie od aplikacji do aplikacji. I dosyć często wprowadzane są pewne modyfikacje, np. dodanie jakiegoś pola czy cechy do danego elementu. Zmieniają się proporcje, wymiary, kolory i look'n'feel. Dotyczy to również przycisków, pokazów slajdów, menu nawigacyjnego -- praktycznie wszystkiego.

Spróbuj to złożyć z gotowych klocków, bez ręcznego modyfikowania HTML-a/CSS/JS-u (HTML bywa często używany ponownie, pozostałe rzeczy -- szczególnie CSS -- rzadziej).

No, jeśli chce się zrobić zaawansowany front-end to raczej trzeba samemu pisać coś w java-script bo tego biblioteka nie wygeneruje, przynajmniej na razie nie ma takich bibliotek. Dodatkowo coraz częściej używa się flash i to już osobny język. Niestety ale właściciele stron prześcigają się w rozbudowywaniu ich o takie zupełnie nieistotne elementy, które mają przyciągnąć uwagę. Robi się z nich "ruchoma gazeta" i niektórzy oglądający lecą na to. Faktycznie jest to inny rodzaj reklamowania tej strony poprzez umieszczenie takiej "przewagi formy nad treścią". Ludzie jeszcze nie przyzwyczaili się do tego, że najczęściej te dodatki są zbędne a skoro firmom coraz trudniej przyciągnąć klientów to zaczynają stosować coraz bardziej wymyślne kombinacje dla front-end'u.

W rozwiązaniach B2B są na szczęście znacznie mniejsze wymagania co do konieczności użycia tych dodatków i front-end może być prosty.

ok, to proste pytanie:
co zamiast echo $zmienna?

Ja niewielki sens widzę w uczeniu początkującego OD RAZU tego, że wszystkie zmienne od użytkownika powinny być walidowane i włączania w podstawowy kurs zaraz na początku"co to jest XSS i SQL injection"- owszem, idea szczytna, ale zaciemnia podstawowe przykłady i utrudnia zrozumienie (tylko, że zaraz po nauczeniu podstaw języka powinno się początkującemu to powiedzieć).
Naprawdę nie widzę nic złego w tym, że początkującym tłumaczy się: echo wyświetla zmienną. Pod warunkiem, że w rozdziale o GET,POST będzie na czerowno i boldem: "zanim zrobisz coś ze zmiennymi od użytkownika sprawdź czy nie wysłał Ci śmieci"

Nie wiem, jak przeglądałem jakiś archaiczny podręcznik od PHP, to tam informacje o zabezpieczaniu się przez XSSem (szczątkowe) były już po nauce wyświetlania stringa.

@void-tec:
Ja tam wcale nie jestem pewien, że od razu trzeba straszyć XSS-ami i bezpieczeństwem zaraz w praktycznie pierwszej lekcji. Bo już pierwsze programy muszą coś tam wyświetlać.

Jeśli by komuś mówić o unieszkodliwianiu, to chyba tylko dlatego, by bezmyślnie i bez zrozumienia wbił to sobie do głowy od samego początku. Na zasadzie: może sobie zakoduje i tak już będzie robił.

Można jednak zrobić w książce coś innego. Od początku nie pisać (pomijam filtrowanie):

echo "Witaj, $username!";

tylko pisać:

echo 'Witaj, ' . $username . '!';

i taki standard kodowania sobie przyjąć. W tak krótkich i prostych przykładach ten drugi styl wydaje się bardziej rozwlekły i niewiele dający, ale pisanie w ten sposób ma plusy gdy już będziemy mieli bardziej skomplikowany, doroślejszy kod.

Pomyślałby kto, że osoba pisząca bardziej skomplikowany kod sama się skapnie (lub gdzieś wyczyta) o wyższości tego drugiego sposobu przynajmniej w niektórych zastosowaniach, ale kod, który widzimy niestety na co dzień, temu przeczy :P.

Naturalnie, trzeba wspomnieć o pierwszej możliwości, by czytelnik wiedział potem o co chodzi widząc to w innych programach.

Mariusz Jędrzejowski napisał(a)

Dodatkowo coraz częściej używa się flash

A to ciekawe stwierdzenie, bo mi się wydawało, że jest dokładnie odwrotnie. Że Flash ostatnio jest w defensywie i w najgorszej formie od kilku lat. Przestał być cool, strasznie wjeżdża na niego Apple. W iPadach i iPhone'ach nie ma Flasha i Apple promuje i wręcz lobbuje używanie HTML-a 5. Inne firmy zresztą też wywęszyły dobrą okazję i Flashowi coraz bardziej się dostaje (Google też woli semantyczny HTML5 niż Flasha!). Microsoft również skłania się ostatnio mocno ku standardom, a jeśli chodzi o zastosowania niestandardowe, to ma swojego Silverlighta i Flasha też nie lubi. W zasadzie wszyscy twórcy przeglądarek preferują i promują natywne rozwiązania.

Jakoś tak wszyscy oni powychodzili z ukrycia. Może za sprawą ostrej gry Apple, firmy bardzo liczącej się, szczególnie za granicą. A może chodziło o to, że wreszcie video HTML5 zaczęło powoli być dostępne (jest już na YouTube, choć jako jedna z opcji) i Flash nie musi być już używany wszędzie tam, gdzie jest jakiś odtwarzacz video.

Zaczęła się ślepa, tępa promocja buzzworda jakim jest HTML5. Apple używa nawet określenia "HTML5" w stosunku do... elementów CSS3 i niestandardowych rozszerzeń Webkita.

Zastanawiam się, jak to teraz wygląda w praktyce. Może tylko mi się zdaje, że Flash jest rzadziej używany? Jak tak sobie o tym myślę to statystyk nie widziałem i patrzę tylko na ogólny klimat w branży.