Forum PHP.pl

Jak masz za dużo czasu, to oczywiście możesz bawić się w utrzymywanie i rozwijanie swojego CMS-a.

Na starość lepiej jednak trzymać się jednego wybranego systemu, zawsze go zaktualizują, zawsze będą pluginy i templatki i
w razie braku czasu zawsze znajdziesz jakiegoś majstra, który Ci pomoże dokończyć zlecenie. ; )

Sądzę, że każdy ma podobne rozterki do Twoich.

Pisząc prywatne projekty zawsze biorę pod uwagę "czystość kodu" do "czasu pracy".

Każdy ma jakieś wyobrażenie o tym jaki powinien być kod, a także każdy ma swoje nawyki. Wydaje mi się, że większość z nas ma lepsze wyobrażenie o swojej pracy, niż ona w rzeczywistości wygląda - a widać to najlepiej przy prywatnych projektach. ; )

Uczymy się wzorców, mówimy sobie, że testy i czystość kodu (znana książka "Czysty Kod") są ważne, ale gdy zaczynamy pracę nad jakimś projektem, to nie zawsze trzymamy się idealnie swoich teorii.

Ja osobiście ciągle podejmuję decyzje typu: "zostawić tutaj drobny bałaganik do posprzątania na później czy posprzątać już teraz?".

Najważniejsze to najpierw nauczyć się pokory - pamiętam doskonale czas, kiedy uczyłem się bardzo dużo nt. programowania, wzorców, czystego kodu, testowania. Sam siebie uważałem za wybitnego programistę.
Jednak podczas pewnego projektu śpieszyłem się z dostarczeniem pewnego oprogramowania. Po dwóch miesiącach pisania kodu nagle zdałem sobie sprawę, że złamałem prawie wszystkie zasady, w jakie głęboko
wierzyłem - dostrzegłem wtedy jaką byłem żałosną istotą... ; )

Pomyślałem sobie - Damianie, Ty tępy ch#&$^, uważasz się za tak dobrego programatora, a tutaj tworzysz takie g$%#$, że smród rozchodzi się po całości.

Pamiętam także jedną aplikację, dość dużą. Pisałem ją przez jakiś rok (prywatny projekt). Po długiej przerwie bylem zmuszony do pewnych modyfikacji, zajrzałem więc do starego kodu i...
ni cholery nie mogłem się połapać w jednej części kodu. Po prostu stworzyłem tak cholernie skomplikowany kawałek kodu, że musiałem przez prawie dwie godziny go analizować, aby połapać się
o co w nim chodziło.

Jaka jest moja rada? Nie ma kodu doskonałego. Goni nasz wszystkich czas. Nawet jeśli masz dobre zamiary, to często robisz małe grzeszki. Małe grzeszki nie są złe, o ile się nie rozrastają.

Ze swojej strony powiem tylko tyle, że wszystko zależy od nastroju i nastawienia.

Pisałem prywatne projekty, w których naprawdę działałem według swoich zasad, tj. pełne skupienie na "czystości" i "otestowaniu".
Wielbię Wujka Boba, więc tworzyłem soft otestowany w 90-kilku procentach. Siedziałem nad nim długo, starałem się go ciągle refaktoryzować, nawet gdy
niektóre rozwiązania zabierały dużo czasu. Widziałem tego efekty. Widziałem, że warto mieć testy.

Ale... nawet teraz po latach doświadczenia potrafię się śpieszyć i tworzyć oprogramowanie "na szybko", bez testów, z "małymi grzeszkami".

Ważne, aby mieć jakieś standardy.

Gdy łamię zasady, wtedy coś za uchem mówi mi "grzeszysz". Popełniam grzeszki. Ale mam jednak pewne "standardy grzeszenia".
Mogę pisać kod, który nie jest otestowany. Mogę czasem wprowadzić jakąś mała zawiłość. Ale jesli widzę, że coś staje się zbyt
skomplikowane, albo zbyt nieczytelne, wtedy włącza się alarm i wprowadzam porawki.

W końcu większość z nas wie jakie problemy wiążą się z nieczystym kodem. Doświadczyliśmy tego.
Wiemy co robić, aby nie kopać pod sobą dołków. Czasem grzeszymy. To normalne.

Ważne, aby mieć jakieś normy.

Wyliczenie średniej to bardzo skomplikowany algorytm oparty o wiele zmiennych, które najpierw trzeba wprowadzić, mi.in:
- rodzaj umowy,
- doświadczenie programisty w latach,
- technologie w jakich się specjalizuje,
- miasto w którym pracuje,
- firma w jakiej jest zatrudniony (w jednej firmie nie dostaniesz więcej niż 6 koła, w innej od tylu zaczynają)

W internetach mówią, że średnia dla całego ogółu programistów to około 4.142 zł (na rękę) - czy to prawda? Tego nikt nie wie.

Wiem jedynie, że w polskich centrach IT taką sumę dostaniesz bez problemu w ciągu swoich pierwszych 2 lat kariery.

Wiem też, że w małych miejscowościach będziesz miał bardzo duży problem, aby do takiej wypłaty dojść (programiści tam pracujący cieszą się,
że w ogóle pracują w zawodzie, jest mało firm i płacą małe pensje, np. 2000 - 3000 zł).

Ze swojego doświadczenia powiem tylko tyle, że najgorzej jest na początku.

Na początku poszukaj dobrej programistycznej firmy z okolicy (najlepiej wyprowadź się do polskich centrów IT), napisz CV i podkreśl, że będziesz pracował u nich przez pierwszy rok za miskę ryżu.
Nawet za minimalną krajową - dla programisty na początku ważne jest zdobycie doświadczenia. Zaniżoną początkowo wypłatę później sobie odbijesz kilkukrotnie. ; )

A jak człek ma już ze 2 lata konkretnego doświadczenia, to już łapie się w pułap od 4-5k (netto na UoP, lub kwoty po odprowadzeniu podatków w B2B).

A jak już wejdziesz na doświadczenie typu 5+ lat, to już w ogóle horyzonty się otwierają i tak naprawdę kwota jaką możesz zarobić jest taka, o jaką prosisz i na ile się godzisz.
Jak będziesz szukał pracy, gdzie dadzą Ci 8k, to taką znajdziesz i tyle będziesz zarabiał.
Jak będziesz szukał pracy, gdzie dadzą Ci 15k, to taką znajdziesz i tyle będziesz zarabiał.

Wiem, że to brzmi dziwnie, ale zauważyłem już to jakiś czas temu - zarabiam tyle o ile proszę i na ile się nastawiam.

A gdy ktoś zna dobrze angielski i potrafi stworzyć swoją markę, wtedy na zachodzie czeka na niego naprawdę porządna kariera (nawet jako praca zdalna).
Zachodnie stawki dla specjalistów to kwoty rzędu od 100-300 dolarów za 1h. Najlepsi konsultanci cenią się na kwoty do 2000 dolarów za 1h.

Ale aby tyle zarabiać trzeba mieć swoją markę - wtedy zarabia się kupę kasy na stanowiskach kierowniczych / przy zarządzaniu projektem i technologiami.
Wiedza i doświadczenie naprawdę dużo kosztują.

Także kolego - sky is the limit.

Unikaj tylko stagnacji jako klepacz kodu, bo ugrzęźniesz w firmie, która będzie na Tobie zarabiać krocie, a Ciebie zadowoli "dobrą polską wypłatą".
W naszej branży jest duża kasa i nie należy się poddawać.

Ano, racja - albo zawozisz mechanikowi świecę i pytasz się na ile by wycenił remont silnika. ; )

Można też do serwisu komputerowego zanieść wentylator od procesora i zapytać się, jak naprawią komputer - bez jego pokazywania.

Nie da się.

Jeśli w swoim serwisie masz jakieś niezależne moduły (np. karta graniczna w PC jest niezależnym modułem, można ją przepinać itd, ma swoje API), to dałoby się nad tym pracować.
Ale jeśli cały system jest jednym zlepionym monolitem, to już sprawa się komplikuje, bo przecież aby połapać się jak co działa, to trzeba to zobaczyć i zrozumieć. Nie ma innej drogi.

Jedyne zabezpieczenie jakie widzę to przygotowanie umowy z wysoką karą umowną (np. 50.000 - 100.000 zł) za rozpowszechnianie lub wykorzystywanie działa do własnego użytku.
To może odstraszyć.

Klient to "TO BE OR NOT TO BE" dla każdej firmy.

Dziennie w Polsce powstaje 1200 firm. Tak - 1200, dobrze widzisz.

Większość to pełni nadziei ludzie, którzy marzą o wyrwaniu się z etatu i zarobieniu grubej kasy.

80% tych firm upada w ciągu pierwszych dwóch lat.

Tylko około 5-10% wszystkich firm dociera do 5-tego roku działania przedsiębiorstwa.
A do 10-lat działania dociera poniżej 0.5%.

Przez rok czasu prowadziłem swoją firmę (strony/sklepy/serwisy online) na polskim rynku i powiadam Ci, że
bez porządnych szkoleń z marketingu i bez nakładów na reklamę szybko zrezygnujecie.

Tak jak zauważyłeś większość portali zawalona jest gimnazjalistami, studentami i "murzynami", którzy
robią za miskę ryżu. Co najgorsze, większość z tych zaniżających ceny są partaczami - wiem o tym, bo
w późniejszej fazie samemu ich zatrudniałem do wykonywania pewnych zleceń, Ci najtańsi
nigdy nie doprowadzili żadnego zlecenia do końca. Nigdy.

Także zaniżają ceny, co sprawia, że Ty też zaniżasz ceny, przez co mało zarabiasz (dodaj do tego jeszcze podatki, ostatecznie będziesz dorabiać grosze).

Musisz zrozumieć, kolego, że wy wchodzicie w KRWAWĄ WALKĘ o klienta. Może się Tobie wydawać,
że wasza firma może spokojnie działać, bo przecież jesteście kompetentni - ale problem jest z brakiem klientów.

Bez klienta nie ma po prostu firmy. A walka o klienta to zaciekła i trudna walka. Jeśli nie macie nikogo od marketingu,
albo sami nie jesteście pasjonatami marketingu, wtedy zakładam, że nie pociągniecie dłużej niż kilka miesięcy. Tyle mniej
więcej wam wystarczy, aby zrozumieć, że bez klienta nie ma kasy, a jak nie ma kasy, to nie warto się męczyć.

Gdyby szukanie klientów było łatwe, wtedy większość firm działałoby bezproblemowo. A jak wiesz i słyszysz często upadają nawet
duże koncerny i korporacje - a dlaczego? Nie ma kto kupować produktów/usług. Nie ma klientów.

Na razie pewnie macie dużo energii, więc możecie spróbować. Ale pamiętaj - bez marketingu dupa blada.

PS Zamknąłem firmę, bo mimo że później już trafiały się coraz fajniejsze projekty i klienci, to ostatecznie siedziałem po 12-16h dziennie, 7 dni w tygodniu, a nie mogłem osiągnąć
stawki jaką normalnie otrzymasz gdy ktoś Cię zatrudni na etacie albo B2B (a pracujesz 5 dni w tygodniu po 8h). Prowadzenie małej firmy tworzącej strony/sklepy to mordęga.

Wydaje mi się, że poszedłeś o krok do przodu.

Masz rację, te funkcje automatycznie dodają sól - w tym temacie skupiamy się jednak na ogólnym sensie soli (nie tylko w kontekście PHP i funkcji password_hash).

Pewnie zauważyłeś, że autor tematu zapytał się o sens soli.

Sądzę, że jeśli odpowiemy mu, aby się tym nie interesował, a po prostu użył funkcji "password_hash", to za wiele mu to nie wyjaśni.

Jeśli ktoś dobiera się do bazy, to raczej sól też ma już w kieszeni.

Sól przeważnie zapisuje się w bazie danych i dla każdego użytkownika generowana jest unikatowa sól, aby atakujący nie mógł zrobić sobie tablicy tęczowej - z jedną "solą" jest to łatwe.

Jeśli ktoś ma słabe hasło składające się z kilku znaków (tak jak to pisał kolega powyżej), to atakujący je bardzo szybko złamie.

Proste porównanie:

Złamanie hasła złożonego z liter (małe i duże) oraz cyfr o długości 11 znaków zajmie około 17 dni.
Złamanie hasła złożonego z liter (małe i duże), cyfr i znaków specjalnych o długości 10 znaków zajmie około 23 lat.

Wiec hasło typu: "lubiekoty333" to pikuś, ale dodaj do tego kilka znaków specjalnych i dni przeradzają się w lata - a to dla atakujących już mocny cios.

Witajcie @gitbejbe oraz @adbacz,

Napisałem, że każdego dnia poświęcam *minimum* 30 minut. Czyli nawet jeśli nic mi się nie chce, ani nie mam na nic ochoty, to siadam i poświęcam te 30 minut na pracą bądź naukę (np. czytanie książki).

Zazwyczaj siedzę dłużej, niż 30 minut, szczególnie gdy koduję.

Główny cel to wyrobienie w sobie nawyku systematycznej edukacji/pracy (formę trzeba trzymać).

Mój czas pracy monitoruję przy pomocy "pomodoro" (kanbanflow ma budzik, który co 25 minut przypomina o przerwie - nie da się go przeoczyć, bo dzwoni głośno). Kiedyś potrafiłem zatracić się w czasie i siedzieć przykładowo 3-4h, teraz tak nie ma. Skutecznie monitoruję czas swojej pracy i decyduję, czy dalej nad czymś pracować, czy przerwać, lub czy wziąć się za coś innego.



365 dni w roku * 30 minut = 182 i 1/2 godziny.

Bardzo ciekawy temat, ze swojej strony powiem tyle (jako żonat-pracujący programista):

I. W TYGODNIU:
1. Ustaliłem z żoną, że wieczorkiem, tak po godzinie 20.00 - 21.00 siadam do kompa i siedzę 30-60 minut dziennie.
Mój priorytet to NIE PRZEMĘCZAĆ SIĘ. Idę spać o 22.00 - 23.00, nasza praca wymaga skupienia i świeżego umysłu.
W przeszłości przepracowywałem się, najpierw pracowałem, później dorabiałem, często spałem po 4h, miałem z tego
jedynie zmęczenie i kłótnie z żoną typu "obchodzi Cie tylko komputer i praca".

II. W WEEKENDY
Ustaliłem, że w weekendy muszę poświęcić minimum 30-60 minut, jednak jeśli znajdę więcej czasu, to spędzam więcej czasu.
Dzisiaj przykładowo znalazłem 4h. Żonka czytała książkę, a ja robiłem swoje. ; )

Ważne, aby być wypoczętym i żyć w dobrych stosunkach z rodziną.

Przepracowanie prowadzi do wypalenia, a tego raczej nie chcemy osiągnąć, dlatego jeśli miałbym coś komuś proponować, to
ustalenie prostej zasady typu: "Codziennie znajdę co najmniej 30 minut" na naukę. A to jest naprawdę dużo (ok 182 godziny),
w tym czasie mógłbyś przeczytać około 18 porządnych książek (średnio miesięcznie przerabiam od 2 do 4).

Btw. Jeśli ktoś dojeżdża komunikacją miejską, wtedy może także czytać ebooki na smartfonie (też tak robiłem - dopóki nie
kupiłem domu poza miastem i nie zacząłem dojeżdżać do pracy autem).

Zapomniałem o najważniejszej rzeczy - na każdy tydzień planuję pracę na te 30-60 minut.
Używam kanbanflow.com (choć trello tez może być, ale kanbanflow ma "pomodoro", które mierzy czas), tworzę tabelkę dla każdego dnia,
następnie w każdy poniedziałek tworzę plan na tydzień, a następnie rozliczam się z listy tasków.

I codziennie co najmniej jeden "pomodoro" - tej techniki nauczyłem się od autora książki o tytule typu "Jak zostać lepszym programistą". Nie pamiętam
już tytułu, ani autora, ale mogę podesłać zainteresowanym (ksiażkę mam gdzieś na półce, czytałem ją kilka miesięcy temu, nie chce mi się jej teraz szukać).

Nie widzisz, bo go tam nie ma.

Musisz zainstalować osobno:
1. Apache
2. Interperter PHP
3. Bazę (MySQL/PostgreSQL) i coś do jej obsługi możesz (phpmyadmin/pgadmin3/cokolwiek)

Wpisz w google "how to install lamp on linux" i będziesz miał dokładne instrukcje - przykładowy poradnik: https://community.linuxmint.com/tutorial/view/486

Btw. Na początek jednak polecam Ubuntu. Mint też jest okay, ale jest mniej popularny. Dla Ubuntu masz setki tematów i poradników. O wiele więcej niż do innych dystrybucji - to jest ważne na początku.

To bardziej kwestia religii.

Python, PHP, Ruby - te języki są w jednym "segmencie". Te języki są jak Java i C#. Możesz znać dwa, albo możesz znać jeden trochę lepiej.

Pytanie brzmi tak naprawdę - co chcesz robić w życiu? I to pytanie każdy z nas zadaje sobie codziennie. Za każdym razem gdy myślimy o językach i programowaniu, to często nachodzi nas pytanie - czy dobrze wybrałem? Czy powinienem dalej pracować w języku X? A może przejść na coś innego?

Moim skromnym zdaniem warto poznawać nowe rejony, warto się uczyć - oczywiście najpierw jednak należy dobrze ogarnąć jeden język.

Co do nauki Pythona - możesz, choć skoro znasz już PHP i JS, to lepiej byłoby, gdybyś wziął się za Javę lub C# - one nauczyłyby Cię jak pracuje się z silnie typowanymi językami.

Witaj Kolego,

Kilka grosze ode mnie - dewelopera PHP/JS, który z Javą obcuje po godzinach pracy (głównie android, game dev).


Bez cudów, używa się SQLlite, albo innych wbudowanych baz danych (np. w postaci zwykłej biblioteki .jar). Zbadaj temat "embeded database" dla javy.


Hmm, masz dwie drogi. Jedna która jest podobna do HTML-a i oparta o stylowanie (javaFX), a druga oparta o gotowe komponenty w postaci klas (awt/swing). Ta pierwsza jest nowsza, ta druga to znane juz w Javie komponenty.
Podobno javaFX to przyszłość. Nie wiem, nie pisałem zbyt wielu apek desktopowych z wykorzystaniem tych komponentów - jedynie gry, do których wykorzystuję bibliotekę libGDX.


Najpopularniejsze to oczywiście IntelliJ IDEA, a później Eclipse i Netbeans.


Kolego, Java jest lubiana i wybierana z tego powodu, że posiada masę bibliotek i frameworków. Jest ich więcej niż w świecie PHP - wyboru kupę i nie wiadomo co wybrać.
Oczywiście są takie, które mają już swoją markę, np. Spring to coś w stylu Zenda, ale poza nimi jest masa, masa, masa innych.

W skrócie - do bazy Hibernate. To coś jak Doctrine 2. W sumie Doctrine jest oparte na Hibernate. ; )
Co do deweloperki apek desktopowych - jest masa frameworków i bibliotek, nie ośmielę się wybrać żadnej z tego powodu, że nie mam doświadczenia w tej materii.

Mam nadzieję, że te informacje wydały się choć trochę pomocne.

Swego czasu pracowałem dla jednego z większych polskich sklepów online. Było tam około 30 osób, z czego programistów było 3, a reszta to marketing itd.

Myślę, że jeden programista spędzający 100% czasu na rozwoju Ci w zupełności wystarczy. Co do obsługi zamówień i marketingu - to już jest inna bajka.

Masz rację z tym, że mniejsze aplikacje jest łatwiej dostosować.

Sądzę jednak, że małym graczom, którzy dopiero zaczynają biznes, nie zależy tak bardzo na użytkownikach z IE6, czy takich, którym JS nie działa. To jest mniejszość.

Jeśli masz duża firmę, na której stronie dziennie pojawia się 1 000 000 0000 użytkowników, to 1% jest poważną liczbą i mogą skupiać się na wsparciu dla osób z IE6, albo z nie działającym JS.

Ale jeśli pójdziesz do firmy, która na swojej stronie ma ruch rzędu kilkuset lub kilku tysięcy ludzi i powiesz im, że chcesz wprowadzić obsługę dla osób bez JS, wtedy biznes szybko zweryfikuje wartość takiej inwestycji.

Wydaje mi się, że o jakość tak naprawdę dbamy tylko my, programiści, a managerowie i biznes mają te rzeczy kompletnie w D***, bo dla nich liczą się tylko terminy i kasa.

Biorąc pod uwagę to, że większość projektów nad którymi pracowałem składało się z klienta AngularJS/React i API, to nie wyobrażam sobie co by powiedzieli managerowie i biznes, gdybyśmy przedstawili im pomysł wprowadzenia wsparcia dla IE6, albo dla osób u któruch JS nie działa. Musielibyśmy napisać drugą aplikację.

Sądzę, że w dzisiejszych czasach przeglądarki nie mogą sobie pozwolić na nie-obsługiwanie JS-a. A takimi tematami raczej zajmują się tylko ogromen korpo. Mniejsze firmy nie stać jest na zapewnienie takiego wsparcia. Nasze teorie i idee to jak maluszek, którego na przejeździe kolejowym rozjeżdża pociąg pod nazwą "biznes". Termin, termin, kasa, kasa.

Programista vs Biznes:
https://youtu.be/qIYutqFFxDM?t=36s

Zespół programistów vs Biznes
https://www.youtube.com/watch?v=qIYutqFFxDM...tu.be&t=58s

Heh, no powiem Ci, że tekst mocny, mocno się uśmiałem - ja bym dodał jeszcze, że wyłączyłem modem i przestało działać.

Wydaje mi się, że wspieranie strony "bez JS" to jak wspieranie stron dla IE6. Na takie coś pozwolić mogą sobie raczej tylko ogromne serwisy, które starają się dbać o każdego klienta (google?).

Panowie @Comandeer oraz @!*! - dzięki wam bardzo za rozjaśnienie sprawy! ; )

Sądzę, że ta teoria ma swoje dobre strony, przykładowo fronty byłyby bezpieczne, bo backend mógłby sobie na serwerze po cichu obrabiać ważną logikę (nie pokazując kodu tej logiki) - wiemy jak to wygląda na froncie, kod jest dostępny i można się próbować wbijać do apki.

Zastanawiam się jednak jak to odnosi się do zasad SOLID (głównie do literki S), a także do znanego stwierdzenia "Low Coupling i High Cohesion". Mam tutaj na myśli mieszanie frontów w backendzie. Automatycznie tworzymy monolita, w którym backend i front są od siebie zależne i pogłębiają tą zależność z każdą linia kodu.



Możesz wyjaśnić co masz dokładnie na myśli?

Wydaje mi się, w tym wypadku inwazyjność fontendu się pogłębi - zacznie podbijać backendy.
Nie wiem też dokładnie co masz na myśli poprzez "katowanie" urządzeń.

Ostatecznie generowanie frontów na backendzie nie różni się niczym od podrzuceniem linku do zwykłego pliku JS. Na backu można wygenerować tylko statyczne strony i pliki, później i tak to wszystko
musi wczytać przeglądarka i przerabiać. Wydaje mi się, że z katowaniem nic się nie zmieni.



O własnie, Ty tutaj jesteś Yodą od frontów, mam do Ciebie pytanie.

Zastanawiałem się jaki jest sens generowania frontów na backendzie. Gdy jakiś czas temu grzebałem się w jednej apce z Reactem i przeszukiwałem samouczki, to widziałem
w kilku miejscach przykładu kodu, w którym komponenty reacta były generowane z backnedu (Node je wypluwał).

Nie zastanawiałem się nad tym zbytnio, bo nie miałem czasu, ale urodziło się wtedy pytanie w mojej głowie.
Przejrzałem przelotnie tamten kod, to co było napisane w backendowym-react nie różniło się zbytnio niczym od frontendowego-reacta (były to po prostu najzwyczajniej w świecie napisane komponety, tak samo jak się je pisze dla "frontów").

Pytanie więc brzmi - jaki jest cel takiego działania? Podziel się proszę swoją mądrością. ; )

Ta opinia jest najbliższa moim obecnym odczuciom.

Gdy zaczynałem karierę programisty na zaszczytnym stanowisku "klepacza PHP", wtedy oprócz logiki sporo czasu spędzałem na HTML-ach i przygotowywaniu widoków (taka niestety rola PHP-owca była, chcąc nie chcąc zawsze trzeba gdzieś wypluć HTML-a i ruszyć go trochę choćby w mniejszym stopniu).
Przykładowo Wordpress wymagał (i dalej wymaga!), aby człowiek na backendzie obsłużył generowanie widoku. Lepiej było z frameworkami (np. CodeIgniter - ciągle mówię o starych czasach), tam warstwa logiki była już całkiem fajnie oddzielona od prezentacji, "klepacz PHP" powol przekształcił się w programistę (niestety, ale Wordpress wypaczył umysł wielu niczego nieświadomym ofiarom).

Dla mnie frontendowiec był za tamtych czasów osobą, która znała dobrze HTML, CSS, potrafiła obsłużyć Photoshopa, a także i sieknąć fajny slider w JavaScripcie (lub jQuery).

To co się stało później to już dość spora rewolucja. Zgadzam się, że aktualnie aplikacje napisane w JS przypominają złożonością aplikacje desktopowe. Przyznam, że byłem w dwóch projektach, w których złożoność apki SPA napisanej w Angularze i Backbonie była bardziej skomplikowana, niż przeciętna apka desktopowa z jaką człowiek na co dzień się boryka. Te apki to już poważne monstra, które trzymają swój stan i borykają się z tematami wycieków pamięci (i tutaj czas docenić prostotę PHP, tj. działanie tylko na czas żądania HTTP).

Co prawda sporo rzeczy dzieje się ciągle na backendzie, jednak front obsługuje znaczą część logiki biznesowej (zdałem sobie z tego sprawę gdy zauważyłem, że zespoły frontendowe pracowaly nad zadaniami, którey zawierały w sobie logikę biznesową). Oczywiście nie wszystko może dziać się na froncie, bo kod JS jest dostępny publicznie, jednak naprawdę wiele, wiele, bardzo wiele dzieje się na froncie. To już nie te stare czasy, kiedy wypluwało się templatkę strony i ewentualnoe dodawało kilka smaczków przez jQuery (poprawka: niektórzy tak jeszcze robią).

Ale, ale - to bardzo dobre dla backendu. Backend ma jasne i dobrze określone zadania, które opierają się głównie na przetwarzaniu danych i obsłudze bazy danych. Mnie osobiście aktualny stan rzeczy odpowiada. Jest jasny podział pomiędzy frontem i backendem. Lubię to. Jedyne co łączy frontend i backend to kanał I/O. Tak powinno być. Człowiek może zmienić cały backend, przepisać apkę z języka A na język B nie tykając nawet jednego bitu w aplikacji frontendowej. I to samo działa w drugą stronę.

BTW. Aktualnie jest straszny brak frontendowców na rynku, słyszałem to od managerów ze swojej firmy, a także kolegów pracujących w innych firmach (także na stanowiskach managerskich).



Obywatelu, ostatnie 5 lat to chyba w jakiejś jaskini przesiedzieliście. ; )

Zgodzić mogę się z tym, że zamiast instalować jakąś apkę, można przygotować jej wersje online (responsywną) z HTML5, JS i Socketami dużo da się zrobić.

Jest jednak jeden rejon, gdzie aplikacje online nie dadzą sobie rady - chodzi o gry.
Przy tworzeniu gier online trzeba za każdym razem ładować zasoby (grafiki, modele, muzykę), wydajność jest też mniejsza niż aplikacji natywnych.
Przy prostej grze jeszcze da radę to przeżyć, ale przy bardziej skomplikowanych apkach natywne rozwiązania biją na głowę apki mobilne.

Ale to jest jedynie historia powstania - został napisany na kolanie w 1995 roku, teraz jest 21 lat później. Gdyby dalej był pisany na kolanie, to dzisiaj developerzy wprowdzaliby najprostsze poprawki tygodniami. Wiem o czym pisze, bo byłem w projekcie, który także powstał laaaata temu, a w kodzie czają się tylko potwory z bagien - wielkie kolosy, gdzie jedna metoda ma kilkaset linii kodu, high coupling itd. Jeden z programistów (doświadczony i sprytny) przez 2 tygodnie próbował się połapać co zrobić, aby wykonać jego task (z opisu prosty).
Także czy jakość kodu jest ważna? Oczywiście, że tak. Jest bardzo ważna, bo liczy się to co będzie później. Gdy ktoś zakłada firmę i prowadzi projekt, który ma coś zarabiać, to dlaczego niby miałby go zamknąć po roku czy dwóch latach? Jaki jest cel w zamykaniu dochodowego projektu?


Tak, dokładnie, samemu też mam kilka fajnych pomysłów, tylko problem jest właśnie z wykonaniem. Jak nie ma czasu i środków, to można mieć super pomysły i nici z tego.


Piszesz, że ma działać i nie mieć błedów, a to właśnie w słabej jakości kodzie, bez testów i pisanych z finezją czają się setki bugów. W małym projekcie, albo w początkowej fazie projektu tego nie widać. Ale gdy zajrzysz do projektu, który przez kilka lat był pisany bez większej troski, wtedy dopiero człek zaczyna rozumieć jaką wartość ma dbanie o jakość.

Znam kilka firm (z opowieści a także z doświadczenia), które z powodu słabej jakości kodu upadły - developerzy nie dawali rady dostarczyć produktu ani nowych wersji na czas, ani ogarnąć setek bugów, przez co klienci rezygnowali, a firmy nie miały środków na działanie.

Weź też pod uwagę fakt, że programiści to rozpieszczone istoty. Gdybyś na rozmowie kwalifikacyjnej usłyszał, że masz pracować z "legacy code", który był napisany 10 lat temu, wtedy chciałbyś się w to bawić? Każdy chce się uczyć, iść do przodu, zdobywać doświadczenie z aktualnych technologii, które są "cool" - symfony, laravel, zend, angular - to jest to, czego chcemy. Nikt nie chce grzebać w gównie.

Sam pomysł jest wart tyle, co ogromna kupa słonia. To tyczy się wszystkich dziedzin. Nie liczy się pomysł, tylko jego implementacja. Pomysł to dopiero początek drogi.



Spoko, możesz wykorzystywać jakieś funkcjonalności frameworka, ale w jego rydzach i nie mieszkać tego z logiką biznesową Twojej aplikacji.

Może to zabrzmi okrutnie, ale technologia i framework nie mają nic do rzecz jeśli chodzi o sukces projektu. Możesz to zrobić w PHP, Node, a nawet i dałbyś radę w Cobalu. Fakt jest taki, że jak Ci to będą Juniorzy rozwijać, to wszystko spier...lą i ostatecznie będziesz miał spaghetti (code) i setki robali (bugów). ; )

Framework to detal - po latach tak naprawdę zrozumiałem, że framework to tylko kanał wejścia/wyjścia. Parsuje jedynie request, daje Ci routing, przy okazji dostajesz ORM-a i to tyle. Cała aplikację powinieneś napisać w Plain Objects, beż żadnego couplingu z frameworkiem, czy bazą danych. Clean Architecture się kłania.

Jedyne co widziałem przez ostatnie lata to pisanie, a później narzekanie, że kod stary, że framework stary, że przepisać by się przydało - takie stałe programistyczne pitolenie. Coupling to śmierć. Frameworki to zwykłe kanały I/O wypchane setkami niepotrzebnych pierdół, które tworzą niepotrzebny coupling Twojej logiki biznesowej z farmeworkiem.

Framework powinien być pluginem, niczym więcej - ale nie zrozumie tego ten, kto całe życie frameworki uważa za "szkielety". Tak, to szkielet - porażki.

Tyle z mojej strony, szerokości.

Wejdż sobie na portale typu "pracuj.pl" i zobacz ile ofert jest dla każdego miasta - i jakie są warunki/stawki.

Weź też pod uwagę, że zarobek zależny jest od:
1. Firmy do jakiej idziesz (nawet w Wawie są małe firmy poszukujące studentów i płacące grosze).
2. Twojego doświadczenia.
3. Twojej wyceny (tak naprawdę to zawsze najpierw pytają się Ciebie ile chcesz zarabiać - tak, to Ty mówiesz ile chcesz zarabiać).
4. Twoich zdolności negocjacyjnych (gdy się wycenisz, wtedy nadchodzi czas na obronę tej stawki).
5. Rodzaju umowy (wiadomo, najmniej zarobisz na UoP, a najwięcej na B2B)

Znam kilku naprawdę dobrych developerów, którzy zarabiają mniej niż powinni - tak się po prostu wycenili, a HR to wykorzystał. Na widok jednego mi się serce "kraje", uczciwy, dobry i skromny chłopak z małej miejscowości, cieszy się tym co ma, a mógłby mieć o wiele więcej, ale jest skromny i uczciwy, chce dobrze dla firmy, a jak wiadomo takich się najłatwiej wykorzystuje.

Jakby Ci to wytłumaczyć - to co w jednym miejscu jest sufitem, w innym jest podłogą.

Mówiąc delikatnie - to jedno z Centrów IT, tam zarobki są dobre, nie powinieneś martwic się cenami mieszkań. ; )

Choć rozumiem, że aktualnie ceny mogą Cię martwić, jednak jeśli tam pojedziesz, to przestaną - uwierz mi.