Komentarze do: Frontend

Autor: Matikx

Matikx — Thu, 14 Jul 2011 21:46:26 +0000

A jak wygląda sytuacja na dzisiejsze czasy (połowa 2011) :P?
btw. według mnie front-endowiec każdy język powinien znać chociaż z podstawy i logiki – takie moje zdanie, jestem matematykiem mózgowo, ale narysować na kartce arcydzieło też potrafię [co się przenosi na photoshopa].
Moim zdaniem, jeżeli ktoś nie rozumie języka programistycznego, powinien przysiąść nad matematyką i analizować kod logicznie.

Autor: Szkolenia dla firm

Szkolenia dla firm — Sat, 29 May 2010 18:16:48 +0000

[...] Front-end [...]

Autor: GoON

GoON — Wed, 09 Dec 2009 23:53:02 +0000

A ja znam dość dobrze (x)HTML i CSS. Dodatkowo Photoshop jest mi bardzo dobrze znany więc cięcie to dla mnie taka sama praca jak narysowanie łezki w paincie. JS i PHP tylko na podstawie tutoriali on-line i ewentualnie jak coś trzeba skumać z kodu i lekko to zmienić to też da radę, ale jakbym miał napisać coś z palca w jednym, czy drugim to już gorzej, a jeszcze jakby mi kazano trzymać się jakichś określonych reguł (jak np. obiektowy, a nie strukturalny kod PHP, czy inne dziwo) to siadam i milczę…

Nie przeczę, HTML i CSS są bardzo proste, ale i w tej dziedzinie liczy się doświadczenie, znajomość pewnych sztuczek, zagadnień z dziedziny usability i dostępności (choćby po to, by być zgodnym z WAI i/lub 508). Nie bez znaczenia jest też wiedza na temat tego co obsługują popularne przeglądarki (niewiele przeglądarek wspiera w pełni CSS2.1, a już tym bardziej CSS3, w którym można zaokrąglać rogi).

Trzeba dobrze poznać wroga (różnie interpretujące kod przeglądarki) i wiedzieć jakiej broni przeciw nim użyć, by było jak najmniej szkód (po co robić kod napchany hackami lub warunkami pod IE, czy głowić się nad niuansami innych przeglądarek, skoro można to napisać w jednym, walidującym się CSS-ie i dostępnym, niezaśmieconym zbędnymi DIV-ami (x)HTML-u).

Na koniec dodam, że bolączka wymagającego pracodawcy teraz i mnie dotyka… Szukam pracy już od jakiegoś czasu i zawsze (jak do tej pory) byłem odrzucany właśnie za brak znajomości JS. Na dodatek marny angielski dodatkowo nie pozwala mi nauczyć się jakiegokolwiek frameworka… Chyba, że znacie jakiś dobry kurs w sieci lub dobrą książkę, dzięki której poprawię tą paskudną sytuację ;)

Autor: Wokiee

Wokiee — Mon, 05 Oct 2009 05:21:24 +0000

Często mam przyjemność pracować z grafikami nie znającymi się kompletnie na HTML, CSS. Wizja artystyczna to jedno jest świetna ale zakodowanie tego… masakra

Autor: Adrian Kalbarczyk

Adrian Kalbarczyk — Thu, 12 Mar 2009 23:18:48 +0000

Przypadkiem znowu wpadłem na ten artykuł. Oczywiście wielbiciela ortografii nie skomentuje – najwyraźniej sprawia mu/jej przyjemność szukania literówek w postach pisanych „na szybko”.
Skomentuję natomiast wypowiedz Uzi123 aby osoby czytający komentarze mieli pełniejszy obraz sprawy:
1. Osoba od JS nie musi znać SQL. W pewnych przypadkach SQLa nie muszą znać ludzie od PHP. To jest kompletna bzdura, tak samo jak to, żeby pozwalać losowym osobom grzebać w kodzie PHP.
2. Polecam zapoznanie się z JavaScriptem – w szczególności z Google Gears. HTML i CSS jest tak rozbudowany jak budowa cepa. Każdy kumaty licealista-humanista go zrozumie i będzie umiał zastosować po miesiącu nauki.
3. Nikt nie mówi o wizytówkach. W artykule była mowa o poważnej aplikacji internetowej. PHP do JS ma się tak do siebie jak PHP do assemblera. JS jest językiem funkcyjnym a PHP obiektowym. Trzeba być chyba robotem żeby rano trzymać się sztywnych reguł klasyfikacji obiektów, a wieczorem robić z nimi co się chce (a raczej ze słownikami a nie obiektami bo tak to się powinno nazywać w JS). I jeszcze jedno. Podział przede wszystkim zależy od zespołu jakim się dysponuje. Ja opisałem sytuację idealną – algorytm na stworzenie dobrze prosperującego zespołu. Może się okazać, że nie znajdziemy odpowiedniej osoby na któreś stanowisko i trzeba będzie połączyć pewne funkcje.
Mam nadzieję, że czytelnicy zrozumieją na czym polega różnica między wytwarzaniem profesjonalnych aplikacji a projektami „chałupniczymi” i nikt nie będzie w podobnej dyskusji podawał argumentów na podstawie doświadczenia w pisaniu wizytówek.

PS. CSS pozwala na implementację rozwijanych menu co nie znaczy, że to działa w przeglądarkach. CSS nie pozwala na animację rozwijania menu itp itd.
PS2. Nie ma czegoś takiego jak „silnik oparty na AJAXie” dla jasności. Sam AJAX to niewiele mówiąca nazwa. Przeglądarka składa się z: silnika HTML, JS i DOM. Więcej w wykładach Crockforda.

Autor: uzi123

uzi123 — Mon, 26 Jan 2009 19:08:32 +0000

1. Znać podstawy HTML/CSS/JS/PHP/SQL powinien każdy kto zajmuje się www (czyli jak chcę sobie przez php zainkludować już istniejącego HTML to nie pędzę do kodera php aby mi to zrobił, tylko po odpaleniu googli jestem w stanie to zrobić, jak koduje php to nie pędzę do specjalisty od HTML aby mi wstawił dwie linijki kodu…)
2. Obecnie technologia HTML/CSS jest tak rozbudowana i daje takie możliwości (do rozwijanego menu nie trzeba zapuszczać JS :) a w css3 do okrągłych rogów nie trzeba JS lub wklejania grafiki) więc nie widzę powodów dla którego osoba znająca biegle(!!!) HTML/CSS musiała tracić czas na poznawanie wszystkich zawiłości JS. Bardzo często nieznajomość możliwości HTML/CSS pcha ludzi w kierunku JS.
3. Podział powinien być dostosowany do potrzeb: jak firma robi głownie wizytówki to można wepchnąć razem HTML+CSS+JS jak firma robi głownie poważne aplikacje webowe to HTML+CSS a kodowanie druga kupka JS+PHP, jak firma nastawila się na wizytówki „graficzne” z wodotryskami to niech szuka dobrego grafiki i specjalistę od flash

Autor: Tomasz Nastulak :: Blog » Blog Archive » Aula#27 za nami

Tomasz Nastulak :: Blog » Blog Archive » Aula#27 za nami — Thu, 23 Oct 2008 21:55:04 +0000

[...] dla “kombajnów”, to jestem zwolennikiem dzielenia kompetencji i podobnie uważam jak Damian Wielgosik w swoim wpisie sprzed kilku miesięcy o frontendowcach, że taka praktyka ma po pro…. Otwarcie przyznaję, że JS mi nie leży i wolę tę działkę zostawić prawdziwym wyjadaczom. [...]

Autor: wielbiciel ortografii

wielbiciel ortografii — Fri, 01 Aug 2008 14:33:18 +0000

chierarchia –> hierarchia, Panie architekcie

Autor: Adrian Kalbarczyk

Adrian Kalbarczyk — Fri, 04 Jul 2008 20:17:44 +0000

Podział ról powinien być zgoła inny. Powinien być architekt przedsięwzięcia, który zna się na WSZYSTKICH aspektach aplikacji. Powinien on określić protokoły wymiany danych z uwzględnieniem specyfiki każdego modułu. Moduły są następujące: baza danych, środowisko serwerowe (system operacyjny, serwer WWW, języki skryptowe), dzielenie zadań na systemy komputerowe oraz określanie ich konfiguracji, protokół HTTP i protokoły aplikacyjne tj XML, SOAP, JSON, REST, środowiska przeglądarek (tych które dla systemu są kluczowe = te których wymaga klient). Protokołem wymiany danych jest też HTML! Ten format nie musi wcale służyć do wyświetlania stron internetowych. Może np przechowywać dane dla komponentów JS (co jest o wiele szybsze niż generowanie HTMLa w JS). Architekt oczywiście nie musi znać dokładnie poszczególnych modułów ale powinien wiedzieć co można w nich zrobić. Głównym jego zadanie jest określenie formatów danych przekazywanych między modułami i specyfikacja ich zadań. Musi też wybrać samą architekturę – tak całego systemu (czy baza będzie na tym samym serwerze co serwer WWW?) jak i modułów (czy będą one oparte na architekturze warstwowej?).
Każdy moduł oddaje do opieki osobnej osobie, która dokładnie wie jaki interfejs oraz zadania ma jego moduł. Jedną z tych osób jest powiedzmy „szef od przeglądarek”. On ma za zadanie orientować się we wszystkich technologiach po stronie przeglądarki. Składają się na to: HTML, XML, XSLT, JS, frameworki, informacje ogólne o tym co można wycisnąć z przeglądarki. Osoba taka ma za zadanie opracować interfejsy poszczególnych modułów, zasadę działania itp. Dopiero pod nim są koderzy, którzy dostają zadanie: napisz funkcję, napisz widget itp. Zadanie musi być zaopatrzone w szczegółową specyfikację.
Ja jestem architektem głównym i chierarchia ta się sprawdza. Niestety trudno dzisiaj o pracowników za rozsądną cenę więc męczymy się w czwórkę plus zlecenia zewnętrzne. Przez to, że umiem co nieco (no może trochę więcej) każde środowisko jakiego używamy (oprócz grafiki) nie mamy wpadek tj dublowanie kodu czy widget, który dodany do całości nie działa.
Myślę, że większość firm nie ma architektów i tu jest jedyny problem. Nie mówię żeby opisywać wszystko w Rational Rose ale ktoś kto orientuje się w całości jest niezbędny.
Ja nigdy nie oddam opracowania struktury dokumentu HTML pracownikowi. W takich aplikacjach jest to główne zadanie architekta. Podział ról natomiast jest taki, że jedna osoba robi CSS (skórkę) a inna JS (program).

Autor: Chlebik

Chlebik — Mon, 23 Jun 2008 17:33:25 +0000

Nalezy odroznic robienie HTML+CSS+JS, od opierania 90% funkcjonalnosci strony na AJAxie. Bo o ile taki frontendowiec moze znac JS by zrobic show/hide, zrobic jakis bajerek layoutowy czy animowane przejscie, to o tyle chocby usuniecie kawalka listy to nie jest wyrzucenie kawalka HTMLa, ale pod maska pracuje silnik oparty na AJAXie (czyli dziala serwer, czyli PHP) i w tym momencie gdyby przyszedl do mnie taki frontendowiec, ze on chce miec bajerek i zebym mu zakodowal to by mnie krew zalala. Odroznijmy te 2 rzeczy bo wiedze, ze nie jest to jasne.