• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

Ile powinien umieć Junior Web Developer?

VPS Starter Arubacloud
0 głosów
7,062 wizyt
pytanie zadane 7 maja 2017 w PHP przez marcin99b Szeryf (81,480 p.)
Ile i co powinienem umieć, aby móc iść do pracy na stanowisko juniora?

Idę w stronę backendu, jednak spokojnie mogę robić frontend.
Znam dość dobrze html5 i css3, z js umiem tylko podstawy (ogarniam programowanie obiektowe, jednak nie robiłem projektów z js większych niż jakieś zmienianie wyglądu, czy programów liczących coś)

Idę głównie w kierunku php, w którym jestem w stanie zrobić... w sumie wszystko to, co sobie wymyśle
Ogarniam żądania get/post, więc mogę przekazywać dane, wiem czym jest sesja więc moge zrobić system logowania, umiem pracować z bazą danych, nie mam problemów z elementami programowania obiektowego oraz umiem robić projekty w wzorcu projektowym MVC. Nie długo zaczynam się uczyć Symfony albo Laravela (prawdopodobnie jako wstęp do frameworków przejdę jakiś kurs z CodeIgnitera, bo słyszałem że jest prosty, w przeciwieństwie do np Symfony)

Dodatkowo dopowiem, że ogarniam podstawy baz danych (podstawy sql, relacje, normalizacja itp, takie podstawowe elementy)

Wydaje mi się że umiem dość dużo, przed tym pracowałem z innymi językami programowania, głównie C# w którym też mogę tworzyć programy, gdyby klient chciał.
Sytuacja z kontrolą wersji (git) wygląda dość średnio, to znaczy umiem wysłać pliki na serwer, jednak nigdy się nie interesowałem tym, co może być problemem, jednak stopniowo się tego ucze. Coś czuję że git będzie czymś prostym do opanowania w tej niezbędnej części.

Mógłby ktoś napisać co powinien umieć taki junior, oraz czego się wymaga od takich osób? Jakie są przykładowe zadania.
Oraz czy wy byście mnie przyjęli na obecnym poziomie, jeśli nie, to w czym muszę sie podszkolić aby spełniać wymagania.

3 odpowiedzi

+1 głos
odpowiedź 7 maja 2017 przez Ehlert Ekspert (212,630 p.)
wybrane 8 maja 2017 przez marcin99b
 
Najlepsza

System kontroli wersji, przeważnie git, to absolutna podstawa. W firmach pracuje się w grupie i bez niego nic nie zrobisz. 

Co do backendu zapomnij o swoich konstrukcjach takich jak system logowania. Mocą PHP  są frameworki, czysty kod w standardach PSR, a przede wszystkim bezpieczeństwo. 

Możesz spokojnie zacząć od Symfony. Potrzebujesz chęci, czasu, angielskiego na poziomie dokumentacji i trochę cierpliwości devil

1
komentarz 7 maja 2017 przez Tomek Sochacki Ekspert (227,510 p.)

Osobiście z racji tego, że działam na własnej DG to muszę ogarniać nie tylko front ale i trochę back-end. Czasami można co nie co podzlecać innym, ale powiem Ci szczerze, że bardzo często widzę u ludzi praktycznie zerową wiedzę z baz danych.

Dodatkowo dopowiem, że ogarniam podstawy baz danych (podstawy sql, relacje, normalizacja itp, takie podstawowe elementy)

Szczerze? Według mnie nie znasz dobrze baz. Gdybyś je znał, to napisałbyś, że umiesz zaprojektować bazę (strukturę) - co jest jednym z większych problemów, umiesz tworzyć i optymalizować zapytania SELECT (i nie jest Ci obca kwerenda EXPLAIN), wiesz co to procedury składowane (w tym parametryzowane), triggers, klucze obce (foreign key), znasz różnicę między silnikami konkretnej bazy, np. MySQL (innoDB, MyISAM, MEMORY, ARCHIVE), umiesz posługiwać się funkcjami bazodanowymi bezpośrednio w procedurach i zapytaniach SELECT, umiesz analizować wydajność i optymalizować indeksację baz, umiesz swobodnie poruszać się w typach danych itp.

 

Nie odbieraj tego proszę w żaden sposób jako krytykę czy jakieś podważenie Twojego wpisu! Chcę Ci tylko powiedzieć, że nawet jak rozmawiam czasami z programistami siedzącymi w większych CRM/ERP to oni również notorycznie powtarzają, że u wielu młodych programistów najbardziej kuleją bazy danych...

Jeśli więc zastanawiasz się nad back-endem to może warto również nieco poszerzyć wiedzę z zakresu właśnie baz? Pomyśl np. o jakimś własnym CRM, co według mnie pozwala bardzo ładnie nauczyć się zarówno bazy, jak i back-end (wiem, to się łączy ale specjalnie tutaj wyróżniam jako 2 zagadnienia) i frontu... Pamiętaj, że w wielu projektach zmienić front to nie problem, zmodyfikować PHP/node to powiedziałbym średnio-upierdliwe, ale robić znaczne zmiany na bazie to już wymaga na prawdę doświadczenia i sporej wiedzy... i co ważne... cierpliwości.

Pozdrawiam

komentarz 8 maja 2017 przez marcin99b Szeryf (81,480 p.)
Wiem, jestem świadomy tego, że z baz umiem jedynie małą część podstaw, chciałem jedynie pokazać że cokolwiek kojarzę, i byłbym w stanie stworzyć prostą bazę danych dla jakiegoś prostego programu (np podstawowy blog).
Planuję w przyszłości podszkolić się z baz danych, jednak aktualnie moim celem jest lepsze poznanie PHP.
komentarz 8 maja 2017 przez marcin99b Szeryf (81,480 p.)

Możesz spokojnie zacząć od Symfony.

Spróbuję zaraz po doprowadzeniu do końca aktualnej aktualizacji projektu (przebudowa na MVC + dodanie kilku aktywności)

Potrzebujesz chęci, czasu, angielskiego na poziomie dokumentacji i trochę cierpliwości

Z tym akurat nie mam problemów, programowanie traktuje (jeszcze, zobaczymy co będzie jak pójde do pracy)  jak zabawe, która w przyszłości może przynieść pieniądze.
Co do angielskiego - rozumiem dokumentacje, jednak nie umiem na tyle, żeby móc się z kimś dogadać w normalny sposób (problemy z tłumaczeniem z polskiego na angielski, w drugą stronę jest wystarczająco). Czy taki poziom będzie wystarczający na start?

komentarz 8 maja 2017 przez Tomek Sochacki Ekspert (227,510 p.)

Wiem, jestem świadomy tego, że z baz umiem jedynie małą część podstaw, chciałem jedynie pokazać że cokolwiek kojarzę, i byłbym w stanie stworzyć prostą bazę danych dla jakiegoś prostego programu (np podstawowy blog).
Planuję w przyszłości podszkolić się z baz danych, jednak aktualnie moim celem jest lepsze poznanie PHP.

Nie traktuj mojego posta jako jakąś uwagę czy przytyk do tego co napisałeś o swoich umiejętnościach. W żadnym wypadku nie taki miałem zamysł!

Widzę jedynie z doświadczenia władnego i znajomych z branży, że wiele osób zaczynających przygodę z językami "webowymi" bardzo mało czasu poświęca na bazy danych, a rynek potrzebuje takiej wiedzy. Pamiętaj, że HTML/CSS/JS/PHP/node itp. itd. to nie tylko stronki typu wizytówki, galerie, blogi, sklepy itp. lecz również pełnoprawne aplikacje CRM czy analityczne. Zaletą zastosowania takich technologii jest możliwość łatwego udostępnienia klientowi aplikacji na różne urządzenia - martwisz się nie o system operacyjny lecz o przeglądarkę co jest łatwiejsze w opanowaniu.

A tak na marginesie baza danych do dobrze zaplanowanego bloga to wcale nie taka oczywista sprawa :) Pamiętaj, że baza to też użytkownicy i ich uprawnienia itp. to również kwestia komentarzy pod wpisami itd.  Ale skoro o tym wspomniałeś, to może warto w ramach nauki spróbować coś takiego zrobić :)?

Pozdrawiam,

i życzę powodzenia i wytrwałości w nauce :)

komentarz 8 maja 2017 przez marcin99b Szeryf (81,480 p.)
Aktualnie projekt który robie to system blogowy, w którym każdy użytkownik może prowadzić swojego bloga, oraz jednego bloga może prowadzić kilku użytkowników mających do tego uprawnienia (będących w jednej grupie, gdzie każdy użytkownik może mieć inne uprawnienia dotyczące edycji postów, przykładowo jedna osoba może jedynie edytować posty, ale nie może ich dodawać ani usuwać).

Pomysł jest inspirowany Bloggerem od Google, z tym że w moim będą mocno ograniczone możliwości. W sumie poza samym zarządzaniem informacjami (nazwa bloga, dane użytkownika itd), postami i prawami użytkowników praktycznie nic nie da się zrobić.
To bardziej duże ćwiczenie które moge podpiąć pod CV żeby pracodawca mógł zobaczyć co umiem, a nie projekt skierowany w strone rynku.

Jakaś tam obsługa bazy danych i konieczność planowania są, jednak fakt - baza danych nie jest rozbudowana, więc nie wymusza nauki tej dziedziny (praktycznie wszystkie operacje są oparte o insert/select/update/delete, czasami pojawia sie jakaś relacja)

Po ukończeniu projektu na pewno zabiorę się za coś bardziej rozbudowanego, albo bardziej rozbuduję obecny system.
komentarz 8 maja 2017 przez Tomek Sochacki Ekspert (227,510 p.)

 insert/select/update/delete

zdarzały mi się przypadki, że wiedza ludzi ograniczała się tylko do znajomości "czegoś takiego jak select" więc jesteś na dobrej drodze :) Jedyne co to ostrożnie z "delete". Projektując bazę danych warto zawsze myśleć o ewentualnej archiwizacji. Na przykład nie usuwaj postów ale kliknięciem "usuń" zmieniaj w nich jakiś pole (np. active=1/0) i na tej podstawie odczytuj posty, które należy wczytać. Generalnie nie obawiaj się w tego typu projektach ilości rekordów w bazie. Takie problemy zaczynają się dopiero w na prawdę dużych projektach (stosuje się wtedy różne metody optymalizacyjne, np. partycjonowanie tabel itp.)

Tak na marginesie, jeśli zaciekawiły by Cię bazy danych i proces projektowania struktury bazy/aplikacji to polecam poczytać o "Case Method", np. dobra jest książka (stara... ale nadal aktualna): Barker Richard - Case Method. Oderwana w ogóle od konkretnego języka i uczy jak od podstaw myśleć o aplikacjach (czyli uczy tzw. myślenia tym co ma robić program, a nie jak ma to robić - to jest uwierz mi najmniejszy problem...).

komentarz 9 maja 2017 przez marcin99b Szeryf (81,480 p.)

nie usuwaj postów ale kliknięciem "usuń" zmieniaj w nich jakiś pole

 W sumie o tym nie pomyślałem, a na wielu stronach brakuje takiej archiwizacji (usuniesz coś raz, albo ktoś ci usunie i już tego nie ma).
Dobry pomysł, bo rzeczywiście w projektach które będę robić sam nie będzie ogromnych ilości danych (no chyba że beznadziejnie to zaprojektuje i mnóstwo danych będzie się powtarzało), a taka dodatkowa opcja może być pomocna dla ewentualnych użytkowników.

komentarz 9 maja 2017 przez Tomek Sochacki Ekspert (227,510 p.)

Powiem tak, ja zawsze 5 razy się zastanowię zanim zdecyduję się na usunięcie jakiegoś rekordu z bazy i decyduję się na sporadycznie (i najczęściej dotyczy to wyzerowania danych testowych przed uruchomieniem kodu produkcyjnego, choć i tutaj czasami robię pewnego rodzaju kopię wewnętrzną). Według mnie baza to wręcz idealnie narzędzie do archiwizacji. Co więcej, w niektórych wypadkach warto również archiwizować zmiany. Na przykład jeśli już jesteśmy przy blogach, to chociażby na wordpressie masz dostęp do archiwalnych wersji każdego wpisu.

Czy jest to potrzebne? Projektując bazę (strukturę i funkcjonalności) odpowiedz sobie zawsze na jedno proste pytanie - Czy dany rekord może mi się kiedykolwiek przydać? Jeśli się wahasz z odpowiedzią lub widzisz szansę, że się przyda to znaczy, że warto go archiwizować. Jak już pisałem, o wielkość bazy się nie martw. Nie wierz w niektóre opinie spotykane na forach, że baza MySQL czy inna nie nadaje się do dużych zbiorów. Tak najczęściej piszą osoby, które w ogóle nie pokusiły się o sprawdzenie wydajności zapytań i optymalizację struktury bazy i de facto nie pracowały z bazami na prawdę dużymi (kilka czy kilkadziesiąt tysięcy rekordów to wcale nie są duże bazy).

Wracając do problemu. Podałem Ci przykład z zastosowaniem dodatkowego pola w tabeli, określającego czy dany rekord jest "aktywny" czy nie. Wadą tego rozwiązania jest to, że musisz rozbudować select o dodatkową klauzulę weryfikującą pole "active". Czy da się inaczej?

Otóż da się, i sam z tej metody korzystam. Zrób sobie tzw. widok (CREATE VIEW view_name AS SELECT ... i tutaj zrób selecta po aktywnych wpisach). Następnie w aplikacji pobieraj dane z widoku jednym, prostym i szybkim selectem. Ponad to w widoku możesz połączyć dane z kilku tabel, co pozwala uprościć zapytania w aplikacji, nie musisz już np. stosować wielu inner join, left join, right join itp.). Taka mała rada, ja np. stosując widoki nadaję im nazwy zaczynające się od "v_" aby zawsze jednoznacznie wiedzieć, czy pracuję na widoku czy tabeli.

Widoki mogą się automatycznie aktualizować po zaktualizowaniu tabel podstawowych. Ponad widoki zapewniają większy poziom bezpieczeństwa, ale to bardziej zaawansowany temat i nie chcę Ci teraz mieszać w głowie.

Czy da się jeszcze inaczej? A może usuwane elementy przenosić do innej tabeli, gromadzącej tylko dane archiwalne. Tabela "bazowa" zawsze ma dane aktualne i jednocześnie nie tracisz historii zmian. Generalnie nie powinno się tworzyć wielu tabel przechowujących takie same dane, ale jest to jedna z metod pewnej optymalizacji właśnie większych baz, choć wiąże się z nią parę problemów.

Chciałem Ci tylko pokazać, że tworzenie struktury i funkcjonalności bazy to niełatwe zadanie. Dość często zdarza mi się widzieć, że wiele osób na siłę chce pobrać z bazy wszystko co się da ("select *..."), potem odpowiednio obrania te dane w kodzie. Co więcej, niestety wiele książek do PHP omawia właśnie takie zapytania... (albo ja gdy zaczynałem przygodę z PHP trafiałem na kiepskie książki...). A czy nie lepiej po prostu od razu pobrać tylko te dane, które faktycznie są potrzebne? Dodatkowo na bazie łatwiej jest na bieżąco analizować wyniki select'ów niż z poziomu kodu, np. PHP.

(no chyba że beznadziejnie to zaprojektuje i mnóstwo danych będzie się powtarzało)

To znaczy, że miałbyś źle zaprojektowaną strukturę bazy. Na przykład załóżmy, że masz tabelę z książkami. Dla każdej książki przypisujesz tytuł i autora. No dobrze.. ale jeden autor może mieć wiele książek prawda? Stwórz więc osobną tabele dla autorów i łącz dwie tabele poprzez tabelę pośrednią. Dodatkowo w tym momencie możesz założyć na obu tabelach tzw. klucze obce. Co to da? Na przykład możesz zabezpieczyć się, że nie zostanie przeprowadzona operacja usunięcia autora z bazy jeśli jest on przypisany do jakieś z książek. Poprzez usunięcie mam tu na myśli oczywiście "zarchiwizowanie" autora. Powiesz, że możesz to przecież zrobić w PHP. Zgadza się, ale wg mnie w bazie jest to dużo czytelniejsze i bezpieczniejsze, a po stronie aplikacji zabezpieczenie takie służy bardziej do odpowiedniego poinformowania użytkownika.

Pozdrawiam

komentarz 9 maja 2017 przez marcin99b Szeryf (81,480 p.)

Dość często zdarza mi się widzieć, że wiele osób na siłę chce pobrać z bazy wszystko co się da ("select *...")

Ja ucząc się, zauważyłem  że wiele osób używa * kiedy musi wyciągnąć większość danych, przykładowo muszą wyciągnąć 4 na 5, a nie chce im się pisać osobno wszystkiego, w sumie też tak czasami robię, ale nie zawsze.

Podczas grzebania przy skryptach logowania, wpadłem na pomysł zrobienia tego w następny sposób
-skrypt sprawdza czy nasz użytkownik istnieje, a następnie wyciąga jego hasło do zmiennej
-następnie skrypt sprawdza czy podane hasło jest zgodne z tym zaszyfrowanym w tabeli za pomocą password_verify()
-jeśli jest wynik pozytywny, użytkownik jest zalogowany

Coś czuję że to nie był prawidłowy przykład logowania (chociaż możliwe że był nie najgorszy, w sumie nie wiem bo nie siedzę za bardzo w kwestiach bezpieczeństwa), ale bardzo dobrze widać na nim, że czasami warto pobierać jedynie małą informacje, zamiast wszystkiego. Poco mamy znać pozostałe informacje, skoro nawet nie wiemy, czy logowanie pójdzie poprawnie.
kod wyglądał tak
 

        $login = $_POST['login'];
        $pass =  $_POST['password'];

        $loginConnect = $pdo->prepare( 'SELECT password FROM `users` WHERE login = :login' );
            $loginConnect->bindParam(':login', $login);
            $loginConnect->execute();

        $resultLogin = $loginConnect->fetch();
        $hash = $resultLogin['password'];

        if( password_verify( $pass , $hash ) == true )
        {

            $_SESSION['logged'] = true;
            $_SESSION['userLogin'] = $login;
        }

Co do kluczy obcych itp miałem o tym sporo w szkole (technik informatyk przedmiot bazy danych), więc mniej więcej wiem czym i poco są. Szkoda tylko że nie było za dużo z praktyki. Chodzi mi o to, że wiele osób z samego poczytania o tym że coś jest lepsze, nie będzie miało w pełni świadomości, że to rzeczywiście jest przydatne. Według mnie każda lekcja teoretyczna, powinna być połączona z praktyką, ponieważ dużo lepiej się uczymy widząc na własnych oczach różnice, wiele osób (na przykład ja) bardzo wolno się uczy, nie robiąc podanych przykładów w praktyce, a jedynie omawiając je w teorii. Ale już schodzę na inny temat, bo na wady szkolnictwa.

+1 głos
odpowiedź 7 maja 2017 przez rafal.budzis Szeryf (85,260 p.)
Wszystko zależy od firmy. Wysyłaj CVki, po rozmowach weryfikuj czego brakowało i zobaczysz ;) W mojej firmie gdy się zatrudniałem nie było podziału junior / senior w sumie dalej go nie ma. Doświadczenie miałem podobne do twojego :D też PHP i C# nie był mi obcy. Ale o systemach kontroli wersji nawet nie słyszałem. Po wypracowaniu kliku miesiecy wdrażałem nowe osoby w nasz system i było bardzo rożnie. Jedna z osób znała tylko CSS2 i HTML4 ale popracowała podszkoliła się i w niczym to nie przeszkadzało. Niektóre firmy bardziej patrzą na zachowania i charakter aby ocenić czy się nauczysz niz na to co teraz potrafisz. Dlatego też wymagania są bardzo rożne.
komentarz 7 maja 2017 przez marcin99b Szeryf (81,480 p.)
A jak wygląda sytuacja z wysyłaniem CV?
Czy firmy jakoś lepiej patrzą na osoby które dostarczają je ręcznie, czy nie ma to żadnego znaczenia?
1
komentarz 7 maja 2017 przez rafal.budzis Szeryf (85,260 p.)
Zależy od szefa. Jeden stwierdzi ze ci zależy a drugi się wkurzy ze zajmujesz mu akurat czas w najmniej odpowiednim momencie. Ja ani jednego nie dałem osobiście i wszystko jest okej ;)
komentarz 8 maja 2017 przez Tomek Sochacki Ekspert (227,510 p.)
Informatyka to dość nietypowa branża, gdyż CV czasami może być nawet w wersji online i również może zostać przejęte przez pracodawcę.

Tak dla ciekawości/anegdotki powiem o moim znajomym (a raczej mojego taty bo to bardziej ten wiek :) On w swojej firmie (zupełnie po za branżą IT) najbardziej ceni CV napisane odręcznie... tak odręcznie, a nie na kompie. Uważa, że CV na kompie to pójście na łatwiznę i że Ci nie zależy na pracy...

Nie będę tego komentował tu na forum gdyż nie tego dotyczy wątek... to tylko tak na marginesie co do różnych form CV :)
0 głosów

Podobne pytania

+4 głosów
1 odpowiedź 3,527 wizyt
pytanie zadane 25 października 2018 w Rozwój zawodowy, nauka, praca przez Krzysio4224 Obywatel (1,690 p.)
0 głosów
0 odpowiedzi 842 wizyt
0 głosów
3 odpowiedzi 10,380 wizyt

92,454 zapytań

141,262 odpowiedzi

319,089 komentarzy

61,854 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj.

Akademia Sekuraka

Akademia Sekuraka 2024 zapewnia dostęp do minimum 15 szkoleń online z bezpieczeństwa IT oraz dostęp także do materiałów z edycji Sekurak Academy z roku 2023!

Przy zakupie możecie skorzystać z kodu: pasja-akademia - użyjcie go w koszyku, a uzyskacie rabat -30% na bilety w wersji "Standard"! Więcej informacji na temat akademii 2024 znajdziecie tutaj. Dziękujemy ekipie Sekuraka za taką fajną zniżkę dla wszystkich Pasjonatów!

Akademia Sekuraka

Niedawno wystartował dodruk tej świetnej, rozchwytywanej książki (około 940 stron). Mamy dla Was kod: pasja (wpiszcie go w koszyku), dzięki któremu otrzymujemy 10% zniżki - dziękujemy zaprzyjaźnionej ekipie Sekuraka za taki bonus dla Pasjonatów! Książka to pierwszy tom z serii o ITsec, który łagodnie wprowadzi w świat bezpieczeństwa IT każdą osobę - warto, polecamy!

...