Na czym postawić sklep internetowy
W końcu przerwa od filozoficznych wywodów i jakiś konkretniejszy wpis! Pytanie, na które szukałem odpowiedzi gdy pierwszy raz przyszedł do mnie klient z prośbą o sklep internetowy.
Jaki silnik wybrać, darmowy czy płatny a może lepiej napisać swój własny sklep? Co będzie najlepsze dla klietna, czego się uczyć?
Pomijam kwestie o czym sklep będzie, czyli co będzie sprzedawane. Przyjmuje, że przyszedł do Ciebie klient z prośbą o konkretny sklep, a Ty ten sklep musisz postawić, proponując wcześniej najlepsze rozwiązanie.
Jak na większość pytań, tak i na te nie dostaniesz szywnej odpowiedzi. Postaram się przynajmniej rozjaśnić Ci trochę kwestię czym się kierować.
Krok 1 – rozpoznanie
Wybór silnika zależy tak naprawdę od potrzeb klienta. Podkreślam „klienta„, nie Twoich. Oprogramowania nie dobierasz na zasadzie „a w sumie Preste umiem to ją zaproponuje” albo „nie lubię Presty więc powiem, że lepiej będzie kupić jakiś abonament” czy nawet „gdy zrobię swój silnik to będzie kilka razy droższy – uuuu.. czuje dobry biznes!„.
Wypytujemy jak duży będzie sklep, czy w grę wchodzą jakieś integracje z hurtowniami itp., jak dużo produktów przewidują, jakie funkcjonalności, budżet – standardowe rozpoznanie potrzeba jak w przypadku każdego innego zlecenia, tutaj jednak staramy się wyciągnąć jeszcze więcej informacji. Pamiętaj, że czym większy sklep (+ew. bardziej obciążająca platforma) tym lepszy i droższy będize hosting – warto i o tym wspomnieć klientowi.
Krok 2 – wybór silnika
Platformy sklepowe możemy podzielić na kilka kategorii: darmowe, płatne (licencja dożywonia/czasowa), lub nasze autorskie.
Tutaj uwaga dla klientów (jeśli tacy czytają ten artykuł): silnik darmowy nie oznacza, że sklep będzie darmowy lub nawet tani. Czasami sklepy oparte na darmowych silnikach mogą końcową ceną przewyższać te na silnikach płatnych. Co innego jeśli chodzi o silnik autorski, zaprojektowany pod klienta (taki będzie na pewno droższy ale jest to raczej oczywiste).
Darmowe:
WordPress + (np. WooCommerce)
Nie jest to platforma stricte sklepowa ale rozszerzenie, które pozwala sprzedawać produkty na naszym „blogu”. Czy to jest faktycznie dobre? Jasne, bardzo wiele osób prowadzi sklepy na takim rozwiązaniu. Jednak dodatek do bloga (WordPress nie jest jakimś framewordkiem, on powstał jako blog i takie było jego podstawowe zadanie) nie jest tym samym co cała platforma pisana od podstaw jako skelp. Dlatego wg mnie WP + (wooCommerce, e-Commerce) nie nadaje się do dużych sklepów.
Żebyś nie zrozumiał mnie źle. Nie twierdzę, że WP jako sklep to lipa i nie sprawdzi się. Jest to jak najbardziej dobre rozwiązanie w niewielkich sklepach.
Magento
Największa darmowa platforma sklepowa jaką możemy znaleźć. Jest to istny kombajn! Gdyby ktoś powiedział kiedyś „darmowe rozwiązania nie nadają się do profesjonalnych zastosowań” to powinien dostać po głowie i zostać skierowany do przestudiowania Magento. Wg danych z ubiegłego roku (2015) na Magento działa ponad 10% wszystkich sklepów internetowych na świecie.
Jakie są cechy takiego kombajnu? Posiada miliony opcji przez co jest bardzo obciążający dla serwera. Sprawdzi się bardzo dobrze przy naprawdę wieeelkich sklepach. Przy małych sklepach będzie się marnował, nie pokaże swoich możliwości – nawet gdy produktów będzie mało to silnik zacznie niepotrzebnie obciążać serwer a to dalej prowadzi do niepotrzebnych kosztów. Plusem jest na pewno wielka społeczność i duża ilość darmowych dodatków. Minusem może być dosyć skomplikowany panel administracyjny (klientowi może być go ciężko ogarnąć).
Podsumowując – bardzo profesjonalne narzędzie do budowy dużych i ogromnych sklepów.
Prestashop
Potężna platforma sklepowa. Jest to coś pomiędzy WordPressem a Magento (bliżej Magento). Posiada naprawdę bardzo duże możliwości przy jednoczesnym w miare optymalnym działaniu. Nie jest tak straszna dla serwera a bez problemu obsłuży całkiem spore sklepy. Duża społeczność i wiele darmowych wtyczek. Super dla sklepów małych, średnich i dużych (ale nie ogromnych). Jest w miarę prosty w obsłudze dla klienta.
Byłem zbyt leniwy aby szukać procentowego udział w rynku ale Dyrektor Generalny PrestaShop (Benjami Teszner) twierdzi iż dziennie powstaje 120 nowych sklepów na owym oprogramowaniu.
Minusem wg mnie jest toporność w modyfikacji. Tworząc własny szablon masz wrażenie, że autorzy zrobili wszystko aby Ci to utrudnić. Na pewno początki zabawy z szablonami będą bardzo ciężkie.. ale później już tylko z górki:)
Podsumowując – profesjonalne narzędzie do sklepów małych i średnich (i dużych ale bez przesady). Szkoda jednocześnie używać Presty do bardzo małych sklepów ponieważ co bym nie mówić, jest ona całkiem sporym silnikiem.
Quick.Cart
Bardzo mały silnik sklepu (waży zaledwie 1.5MB) ale jednocześnie ma baaardzo małą funkcjonalność. Szczerze powiedziawszy, taki silnik można napisać mają kilka dni wolnego. Posiada także płatną wersję Quick.Cart.Ext – cena może nie jest wielka jednak możliwosci jakie oferuje a nawet większe (znacznie) dostaniemy w poprzednich darmowych rozwiązaniach.
Warto pamiętać, że Quick.Cart oraz jej płatna wersja nie ma takiej społeczności jak, np. Presta, WP czy Magento a lista wtyczke jest bardzo ograniczona.
Podsumowując – nie ma co się rozpisywać. Wersja darmowa nadaje się do… sam nie wiem. Mająć tyle innych rozwiązań darmowych możemy dokonać lepszego wyboru. Na temat wersji płatnej nie będę się rozpisywał ponieważ nie miałem okazji jej przetestować.
OpenCart
Znowu mamy coś pośreniego. Tym razem, OpenCart jest czymś pomiędzy PrestaShop a Quick.Cart. Jest bardzo łatwy w obsłudze, posiada trochę wtyczek (jednak zdecydowanie mniej niż Prestathop czy Magento). Plusem będzie łatwość modyfikacji. Silnik działa na modelu MVC i nie posiada systemu szablonów. Dzięki niewielkim rozmiarom jest lekki i nie obciąży serwera.
Podsumowując – sprawdzi się przy małych sklepach.
Płatne:
W pewnym sensie, wszystkie darmowe skepu również mogą być płatne. Zaraz zaraz… o czym on gada? Może się zdażyć, że klient potrzebuję funkcjonalnośći, której domyślnie nie ma, może nie być jej nawet w darmowych dodatkach. Wtedy płatne wtyczki mogą swoją ceną dogonić nawet płatne sklepy. Są to oczywiśćie rzadkie przypadki jednak warto mieć to na uwadze:)
Płatnych programów niestety Ci nie opiszę. Jest ich wiele, a ja nie mam takich kompetencji aby powiedzieć Ci gdzie włożyć pieniądze.
Mogę powiedzieć za to zadanie do klientów: jeśli nie wieszy czy Twój biznes załapie, nie wiesz czy sklep będzie stał miesiąc czy dwa.. wtedy warto skorzystać z ofert obonamentowych. W razie niepowodzenia nie będziesz mocno w plecy a w razie sukcesu – możesz kontynuować abonament lub zamówić inny typ sklepu.
Własny silnik:
Tutaj również się specjalnie nie rozpiszę. Pisanie silnika od podstaw jest ryzykowne ponieważ trzeba zadbać o naprawdę milion rzeczy, kwestie bezpieczeństwa, płatności, ciągłe aktualiazcje itd. itp.
Oprócz tego jest bardzo czasochłonne a co za tym idzie – bardzo drogie. Jedyna opcja kiedy warto stworzyć sklep to albo specjalny klient, który tego wymaga, albo bisnes (który by polegał na sprzedaży licencji) 🙂
9 nawyków dobrego programowania
Poniżej kilka zasad, które warto stosować już od początku przygody z web developerką (a także jakimkolwiek językiem programowania). Kolejność punktów jest przypadkowa, są po prostu luźno zebraną listą reguł.
Jeżeli zajmujesz się web developerką, to zanim zaczniesz czytać chciałbym bardzo zachęcić Ciebie do wcześniejszego wpisu -> 9 błędów web developera
1.Podziel zadanie na mniejsze zadania
Sama istota programowania uczy nas, aby poszczególne problemy dzielić na mniejsze zadania. Pozwala nam to zaoszczędzić kodu i przewidzieć wszystkie możliwe zakończenia. Takie myślenie etapowe warto przenieść do naszego świata organizacji. Dzięki temu już na etapie planowania możemy dostrzec możliwe problemy i je rozwiązać. Dodatkowo pozornie trudne i wielkie zadania stają się proste i przyjemne w wykonaniu (to jakby spróbować przenieść wielki głaz zamiast go skruszyć i przenosić po kawałku).
2.Używaj tabulatorów jak należy
Stwierdzenie trochę banalne ale widziałem przypadki, że wcięcia robione były chyba losowo i bardziej przypominały wieże Hanoi w połowie układania. Używamy tabulatorów po to aby od razu było widać, która funkcja jest zagnieżdżona w której (pomijam Pythona, tam tabulatory jednocześnie pełnią rolę klamr). Niby oczywiste ale wiele początkujących osób nie specjalnie zwraca na to uwagi.
3.Komentarze
Uważa się, że kod sam w sobie powinien być na tyle czytelny, aby nie używać komentarzy. Staraj się nazywać zmienne i funkcje, aby same w sobie były komentarzem.
Jeśli komentarze są konieczne, stosuj możliwie krótkie i dokładne jednocześnie.
4.Nie mieszaj technologii
Już od początku nauki z językami webowymi staraj się oddzielać języki. Czyli PHP jest w plikach .php, funkcje JS jest załączone na osobnych plikach .js a jakiekolwiek stylowania niech będą w plikach .CSS.
Plik HTMLa bez CSSa powinien być całkowicie rozsypany, ogołocony, żadnych stylów. Co prawda można używać w dokumentach HTMLa tagu 'style’ ale unikaj go. Możemy też umieszczać funkcje JS między tagami <scirpt> ale oddzielanie plików na pewno zaowocuje w przyszłości. Projekty stają się czytelniejsze, łatwiejsze w modyfikacji czy rozbudowie.
5.Optymalizuj
W trakcie pisania kodu, od razu zastanawiaj się czy daną funkcję można napisać wydajniej. Dzięki temu w przyszłości będziesz pisał wydajny kod na bieżąco. Masa sytuacji się powtarza, a Ty wyrobisz w sobie już gotowe schematy.
6.Szukaj dziur
Bądź jednocześnie pentesterem. Postaw się na miejscu atakującego i sprawdzaj sam swój kod czy nie ma dziur. Jednym z częstych błędów back-end developerów jest brak zabezpieczenia zapytań SQL. Ale tyczy się to nie tylko baz.
7.Debuguj, testuj
Pisanie kodu etapami i sprawdzanie na każdym czy działa jest dobrym nawykiem. Zawsze masz pewność (w przypadku gdy program przestaje działać), która część kodu nawala. Oszczędzasz dzięki temu czas i nerwy.
Obecnie mamy do dyspozycji sporo narzędzi do testów automatycznych, które bardzo ułatwiają nam sprawę.
8.Planuj
Osobiście prawie każdy program rozpisuję na kartce papieru. Dopiero gdy mam cały obraz od początku do końca, opis wszystkich funkcji etc. zaczynam działać. Ciężko mi zliczyć sytuację, że napisałem całkiem pokaźną funkcję i nagle przypomniałem sobie o brakującej opcji – w wyniku czego musiałem przerabiać połowę kodu.
Edit: Pisz kod tak, aby był łatwy w przyszłej rozbudowie 🙂 Rozdzielaj różne zadania pomiędzy różne funkcje/klasy/pliki. Pomaga tu zasada, że jeden skrypt powinien robić jedną rzecz, a dobrze.
9.Programuj w języku angielskim
Dlaczego w angielskim? Przecież „Polacy nie gęsi…„. Tak już jest, że angielski jest językiem programistycznym. Po co tworzymy w jednym języku? Wyobraź sobie sytuację, że musisz pracować na plikach z chińskimi nazwami… Zresztą, praktcznie wszystkie dokumentację będą po angielsku. Jeśli jesteś programistą zwyczajnie tego języka nie unikniesz (co jest samo w sobie dobre 🙂 ).
Ps. Jeżeli jesteś już dobrym programistą, zobacz co zrobić aby pracować wydajniej: Jak zostać wydajnym programistą?
Jak rozpocząć naukę z tworzeniem stron
’Tworzenie stron’ to trochę obszerny temat, więc dobrze na wstępnie określić czego chcemy się konkretnie uczyć. Do wyboru mamy kilka dróg:
- web designer – czyli tworzenie layoutu
- web developer, programista, który też dzieli się na:
– front-end, czyli kodowanie warstwy widocznej, tego, co przygotował grafik. Podstawą jest znajomość HTML/CSS/JS
– back-end, czyli kodowanie całej mechaniki strony, tego, co jest pod spodem. Tutaj też możemy mieć kilka dróg, w jakich językach chcemy programować, obecnie najpopularniejszy jest chyba PHP/MySQL - web everything, czyli full stack developer, mam na myśli drogę, gdy chcesz się uczyć zarówno fron- jak i back- endu. Raczej większość osób odradzi ci tej drogi i zasugeruje specjalizację w jednej dziedzinie. Jednak nic nie stoi na przeszkodzie, póki masz czas i chęci uczyć się wszystkiego (ja tak zrobiłem).
Oczywiście to tylko nazewnictwo więc na początek ważne, żeby wiedzieć co chce się robić a nie jak się to nazywa;)
Web Designer
Masz duszę artysty? Lubisz projektować i pomysły nigdy ci się nie kończą? Potrafisz się już posługiwać Pothoshopem? Super! Mogłoby się wydawać, że to wystarczy, aby projektować stronki. Niestety ta opcja również wymaga nauki mnóstwa wiedzy teoretycznej.
Oczywiście podstawowym narzędziem będzie Photoshop. Jeśli nie chcesz inwestować to alternatywą będzie darmowy Gimp. Osobiście sam zaczynałem naukę grafiki w Gimpie i pracowałem w nim jakieś 1,5 roku. Mogę ci powiedzieć, że jeśli chodzi o web design jesteś w stanie zrobić praktycznie to samo co w Photoshpie jednak zajmie to więcej czasu, a PS zdecydowanie przyda się bardziej w przyszłości.
Jak uczyć się programów graficznych? Tworząc! Znajdź jakieś forum, tutoriale (na YT jest tego mnóstwo) i baw się – to najlepszy sposób.
Oprócz znajomości programów przyda Ci się wiedza teoretyczna, o której wcześniej pisałem. Możesz ją znaleźć na różnych forach, blogach czy książkach.
Front-end developer
W tej chwili jest to chyba najintensywniej rozwijająca się działka. Z jednej strony to dobrze, bo co chwile pojawia się nowe narzędzie ułatwiające prace, ale z drugiej strony coraz ciężej nadążyć za wszystkimi nowościami. Osobiście lubię front-end, jest to takie połączenie programowania z designem (w przypadkach, gdy strona jest bardziej interaktywna).
Droga jest prosta: HTML + CSS, następnie JS (i jego biblioteka jQuery – myślę, że jednak cały czas warto ją znać). Od razu dorzuciłbym Less albo Sass, żeby ułatwić sobie sprawę z CSS. Gdy to opanujesz to dobry początek, żeby wziąć się za frameworki;)
Back-end developer
Wspomniałem wcześniej, że istnieje kilka dróg. Możesz tworzyć strony w Pythonie, Ruby, Perl, ASP.NET, JS, PHP… Jest w czym wybierać.
PHP jest obecnie na większości stron dlatego o nim piszę. Jest łatwy w nauce, ale niestety ma burdel w nazewnictwie funkcji i trzeba się w nim sporo napisać. Od PHP ciężko uciec, ponieważ to właśnie w nim są stworzone wszystkie najpopularniejsze CMSy jak WordPress, Drupal, Joomla czy systemy sklepowe (Prestashop, Magento itd.). Nawet jeżeli wybierzesz inny język to znajomość PHP na pewno się przyda.
Oprócz PHP koniecznością jest znajomość baz danych, czyli dobrze znać chociaż podstawy składni SQL i system, które tę bazę obsłuży. Na początek najlepszy będzie MySQL. Te 2 technologie tak naprawdę wystarczą na początek. Z czasem dojdą frameworki PHP lub inne bazy.
Full stack
Jeśli chcesz poznać po trochu każdej opcji, bądź gotowy na poświecenie mnóstwa czasu. Podam ci w jakiej kolejności można się uczyć na przykładzie strony:
Na początek stwórz layout, czyli grafikę swojej strony. Następnie ją potnij i zakoduj w HTMLu oraz ostyluj w CSS. Masz już podstawę. Jeżeli są tam jakieś mechanizmy jak logowanie, wczytywanie różnych stron to zakoduj je w PHP, a jeżeli treść będzie dynamiczna to podłącz ją pod bazę danych (MySQL). Super w tej chwili masz już w pełni funkcjonalną stronę. Warto ją ożywić i dodać trochę JavaScriptu. Teraz już naprawdę koniec.
Żeby następnym razem przyśpieszyć pracę dorzuć jakiś framework, np. CakePHP (PHP), Sass/Less (CSS), jQuery (JS), Bootstrap (HTML/CSS). Dalej warto zacząć automatyzować prację i dorzucić, np. Gulpa, a to sprawi, że zaczniesz korzystać z npm, czyli menadżerem pakietów. Dla bezpieństwa warto zadbać o wersionowanie plików, czyli GIT… i tak jedno ciągnie drugie.
Jeśli jesteś na początku nauki to poprzednie zdania pewnie nic ci nie mówią, ale spokojnie, w ogóle się tym nie przejmuj – zacznij od początku, a w pewnym momencie będziesz już dobrze wiedzaił, co jest potrzebne dalej:)
Strony responsywne a mobilne
Dzisiaj każdy chce i co ważniejsze potrzebuje(!) responsywnej strony internetowej. Fakt, coraz więcej użytkowników stron to użytkownicy smartfonów czy tabletów. Jak w takim razie przygotować stronę responsywną?
Strony responsywne a strony mobilne
Wbrew pierwszej myśli strona responsywna i mobilna to 2 całkowicie różne rzeczy.
Strona mobilna – stworzona wyłącznie dla użytkowników urządzeń przenośnych. Tak naprawdę jest to całkowicie oddzielna strona, na którą są przekierowywani użytkownicy smartfonów. Czasem można ją rozpoznać po innym adresie, najczęściej umieszczana jest na subdomienie „m.nazwastrony.pl”. Strona przyjmując użytkownika automatycznie rozpoznaje z jakiego urządzenia korzysta i przekierowuje go odpowiednio albo na stronę dla smartfonów albo na stronę przygotowaną pod komputery. Jeśli strony nie korzystają z tej samej bazy to każdą aktualizację trzeba wykonywać na obu stronach. Możemy za to jednak dostosować stronę pod telefon praktycznie bez ograniczeń.
Strona responsywna – jest to jedna wersja strony, stworzona w taki sposób, że wyświetla się normalnie na komputerach ale dopasowuje się do każdej rozdzielczości ekranu. Dzięki czemu możemy na nią wchodzić ze smartfonów, tabletów, komputerów. Jeżeli ekran jest mniejszy to wczytuje inne właściwości CSS, zmniejsza szerokość, chowa niepotrzebne elementy – zmienia stronę w taki sposób, że jej obsługa jest równie wygodna na telefonie i na tradycyjnym komputerze. Czyli jest to ta sama strona tylko inaczej wyświetlana.
Wdrożenie
Wdrożenie strony mobilnej. Przykład: na wejście przygotowujemy plik, który rozpoznaje z jakiego urządzenia korzysta użytkownik. Możemy do naszego pliku index.php dodać na samym początku:
$iphone = strpos($_SERVER[’HTTP_USER_AGENT’],”iPhone”);
$android = strpos($_SERVER[’HTTP_USER_AGENT’],”Android”);
$palmpre = strpos($_SERVER[’HTTP_USER_AGENT’],”webOS”);
$berry = strpos($_SERVER[’HTTP_USER_AGENT’],”BlackBerry”);
$ipod = strpos($_SERVER[’HTTP_USER_AGENT’],”iPod”);
Co z aplikacjami mobilnymi?
9 błędów web developera
1. Blokada PPM
Blokada prawego przycisku myszy najczęściej stosowana w celu „zabezpieczenia” zdjęć, tekstów itd. Podobno wtedy użytkownik nie skopiuje zawartości strony. Nieogarnięty pewnie tak, ale dla coraz większej liczby ludzi to nie jest problem. Taka „blokada” mnie osobiście blokuje mentalnie przed ponownym odwiedzeniem tej strony, ponieważ jest to naprawdę irytujące.
Należy pamiętać, że blokując prawy przycisk myszy blokujemy wszystkie opcje, które się tam znajdują. Ok, można je znaleźć gdzie indziej ale wg mnie jest to niepotrzebne utrudnianie życia zwykłych użytkowników a i tak nie uchroni to przed kopiowaniem treści.
Jeśli chodzi o faktyczną blokadę pobrania zdjęcia za pomocą „Zapisz jako” – są na to o wiele lepsze sposoby.
2. Muzyka w tle
Nie każda muzyka jest zła, są strony gdzie nadaje ona klimatu, gdzie faktycznie jest potrzebna jednak jest to rzadkość. Strona firmy budowlanej czy usług kosmetycznych zdecydowanie się w nie nie wpasuje. Jeśli jednak jesteś pewien, że muzyka będzie idealna i być musi – to jedna prośba: DOBRZE WIDOCZNY przycisk wyciszenia.
Wyobraź sobie sytuacje, gdy Kowalski, który w pracy przegląda różne strony wpadnie na Twoją i na całą salę poleci Twoja muzyka na stronie. Przykład może trochę trywialny, ale nikt nie lubi, gdy na stronie zaczyna nagle lecieć na muzyka cały głośnik, jakkolwiek fajna by nie była .
Osobiście zawsze gdy przeglądam jakiekolwiek strony, to zawsze mam włączoną swoją muzykę, wtedy ta ze strony jest szczególnie irytująca.
3. Flash
Temat może już przestarzały ponieważ oficjalnie wiadomo, że flash na stronach nie żyje, a właściwie jeszcze kona. Bodajże za rok przestanie był całkowicie wspierany i przestanie działać. Strony często były przesycone gadżetami w stylu „flashowy zegar”, „animacja” etc. Strony jednak w dalszym ciągu można przesycić zbędnymi bajerami JavaScriptowymi, dobrze zawsze zachować umiar.
4. Darmowe domeny i hostingi
Myślę, że nie dotyczy to raczej użytkowników zaczynających przygodę z web developerką. Sam gdy zaczynałem, korzystałem z tego typu rozwiązań. Obecnie jednak domeny i hostingi tak potaniały, że nie warto bawić się w darmówke. Dlaczego nie warto? W końcu to nic nie kosztuje. Tak, ale darmowe domeny i hostingu wsadzą nam na strony reklamy, do tego całkowicie nie wpasowane ale zwyczajnie wstawione na dole lub górze psując cały wygląd strony.
Dodatkowo zwykle są bardzo duże ograniczenia w konfiguracji hostingu. Kolejnym powodem przeciw – jest brak kopii zapasowej. Padnie serwer to wszystko tracisz, zresztą wcale nie musi paść.. właściciel serwera sam może w każdej chwili usunąć Twoją zawartość bez ostrzeżenia i powodów.
Darmowa domena z kolei już nawet źle wygląda. Nie dostajesz swojej domeny ale subdomenę (np. mojastrona.darmowyserwis.pl). W tej chwili koszt domeny z końcówka .pl to 15zł za pierwszy rok i ok. 50 (edit: ostanio delikatnie podrożały do 80zł) za każdy następny. Koszt małego hostingu to ok. 50zł/rok. Sam widzisz, za 100zł rocznie posiadasz elegancki hosting z kopiami bezpieczeństwa i swoją domenę.
5. Duże pliki
Problem trochę mniejszy niż kiedyś, ponieważ mamy lepsze łącza, szybszy internet ale… Mamy też smartfony gdzie nie każdy posiada 100Mb/s. Pisząc 'duże pliki’ mam na myśli głównie zdjęcia. Obecnie na stronach pojawia się coraz mniej treści a coraz więcej zdjęć, dlatego należy zadbać o to aby strona mogła się szybko załadować mimo wielu zdjęć.
Jeśli przygotowujesz jakąkolwiek grafike na stronę, pamiętaj o jak najlepszej kompresji. Wg mnie dobrym nawykiem jest nieprzekraczanie wagi 500KB pojedynczej grafiki (i to juz jest duża grafika).
6. Mieszanie języków w jednym pliku
Mieszanie języków jest złe z kilku oczywistych powodów. Kod nie jest przejrzysty, ciężko się w nim połapać, zgaduj co za co odpowiada. Zapomnij o większej rozbudowie, zresztą jakakolwiek próba uporządkowania będzie męczarnią… a i wyobraź sobie innego programistę, który miały przejąc po Tobie opiekę nad kodem… Te błędy są ważne, ale wg mnie jest jeszcze ważniejszy powód – rozdzielanie różnych języków jest naturalnym etapem nauki programowania.
Jeśli tego nie opanujesz ciężko będzie Ci pójść dalej, do programowania obiektowego, MVC.Jest to po prostu kolejny etap nauki. Jeśli widzisz, że ktoś miesza HTML, JS, PHP, CSS w jednym pliku to są dwie opcje: jest leniwy albo dopiero się uczy… ewentualnie są sytuacje gdzie wyjątkwo ciężko o oddzielić.
7. Brak zabezpieczeń formularzy
Jest to chyba coraz rzadsze zjawisko, ale wciąż występuje. Ktoś zrobił walidacje formularza przez JS… fajnie bo jest ona ładna, interaktywna ale można ją również samodzielnie edytować w przeglądarce – czyli każdy użytkownik może ją wyłączyć. Dlatego walidacja zawsze, ale to zawsze musi obywać się po stronie serwera, czyli np. w PHP. Dzięki temu użytkownik jest nie obejdzie.
Najlepszym wyjściem byłoby zastosowanie jednocześnie walidacji po stronie użytkownika i serwera czyli w JS i w PHP lub po prostu w AJAXie.
8. Powielanie ID
Mowa tutaj o kodzie HTML. Ten błąd mogą popełniać osoby, które nie widzą różnicy pomiędzy 'id’ a 'class’, czasami może się też komuś zwyczajnie zapomnieć i powielić ID, ale trzeba tego pilnować. 'Class’ można powielać wielokrotnie na tej samej stronie. 'ID’ nie może się powtarzać na pojedynczej stronie – jest to niezgodne z zasadami HTML i nie przejdzie przez walidator, ale również może powodować błędy w działaniu skryptów JS (które na tych elementach pracują).
9. Brak przygotowania pod wszystkie przeglądarki
Często web developer tworzy stronę wyłącznie pod przeglądarką, na której pracuje, zapominając o wszystkich innych. Czyli w chromie wyświetla się OK ale w firefoxie są jakieś dodatkowe marginesy i nikt nie wie o co chodzi.
Przed wypuszczeniem projektu należy go zawsze sprawdzić na każdej przeglądarce (IE pomijam…). Jednak już na początku można zminimalizować ryzyko innego wyglądu na przeglądarkach przez 2 rzeczy: pisanie ładnego semantycznie kodu oraz stosownie tzn. resetu CSS (czyli zdefiniowanie na początku wszystkich marginesów zewnętrznych i wewnętrznych itd.).
A co z dobrymi nawykami?
Gratulacje jeżeli dotrwałeś do końca artykułu. Jeżeli teraz chciałbyś spojrzeć na temat z drugiej strony, to koniecznie przeczytaj wpis o dobrych nawykach-> 9 Nawyków dobrego programisty