Forum PHP.pl

Jeżeli zmienna nie będzie miała żadnych referencji to zostanie wywalona z pamięci. Tak samo jest w PHP, tylko natura PHP jest inna niż JS'a dlatego tego od razu nie zauważysz.

JS tak samo jak PHP to języki interpretowane uruchamiane w maszynie wirtualnej, która posiada swój odśmiecacz pamięci (garbage collector). To co chcesz zrobić to jest bardzo złe podejście, dlatego że garbage collector po prostu po czasie wyczyści ci wskaźniki do tych obiektów (wywali je z pamięci). W takim przypadku powinieneś używać jakiejś pamięci podręcznej, w stylu memcache, redis czy podobne, narzędzia stworzone do tego celu.

Jeżeli nie masz 2 kierunkowej komunikacji, na styl czata, to websockety tylko do wysyłania informacji do użytkownika, są najzwyklej overkillem. Między innymi loadbalancing jest problematyczny, ale i sama ilość połączeń jakie taki serwis pokroju FB musiałby utrzymywać jest astronomiczna. A przechodząc do mobilnych urządzeń, gdzie takie połączenie byłoby często ubijane oraz zrywane, jest zwyczajnie mega problematyczne.

Aktualnie większość tych rzeczy mógłbyś rozwiązać bezpośrednio w przeglądarce, cache jako session storage/local storage/indexedDb, a pobieranie danych w tle przy użyciu service workera, który mógłby aktualizować wiele otwartych kart/okien przy użyciu jednego requesta. Więc przerzucasz całą logikę na klienta (przeglądarkę) i odchodzi ci sporo pracy. I właśnie tego np używa gmail, fb, twitter. Będzie działać na mobilkach, będzie działać na dekstopie.

https://gitlab.com/hadwao/image-inliner/blo.../Dockerfile#L23



to kompletnie nie ma sensu. Wszystko co jest w Dockerfile z wyjątkiem komendy CMD/ENTRYPOINT jest wykonywane tylko podczas budowania, restartowanie serwisu kompletnie nie ma sensu. Zwłaszcza że obraz powinien wystawiać np proces który będzie kontrolowany za pomocą samego dockera (czy innego narzędzia), a nie jakiegoś dodatkowego systemu init (systemd, upstart, runit etc), to nie jest obraz maszyny wirtualnej, czy konfiguracja vagranta. Dlatego też apache działa tam jako foreground: https://github.com/docker-library/php/blob/...Dockerfile#L259

Co do samego tematu: jeżeli masz tylko jedną definicje Dockefile, nie używasz żadnych dodatkowych skryptów do inicializacji twojej aplikacji, to moim zdaniem najlepiej jakby był w root, zamiast ukrywania go gdzieś bezsensu.

"Jakiś" sesn ma, tylko jest zbędne. Jeżeli funkcja zwraca promise (a asynchroniczne funkcje zwracają promise, nawet jeżeli w środku nie ma promise https://i.imgur.com/1onQWVl.png), to używanie await w połączeniu z return nie ma sensu.

Przykładowo:



zwróci zarówno pointless jak i correct (https://i.imgur.com/WZt8ZAe.png), tylko w przypadku funkcji pointless masz to dodatkowo złapane w dodatkowe rzeczy, które tylko utrudniają czytanie kodu.

Jest jeszcze gogs: https://github.com/gogs/gogs | https://gogs.io/

Już wcześniej wydawało mi się że będziesz miał szerszy zakres. Widzisz, problem tutaj polega na tym że próbujesz wyłapać rzeczy które mogą wystąpić w różnej kolejności, dlatego łapie więcej niż powinien.

Nie da się tego jakoś idealnie ugrać jednym uniwersalnym regexem, najlepiej jakbyś zrobił kilka wyrażeń, gdzie każde będzie łapać specyficzne "formaty", bo zapewne te formaty mają jakiś schemat i każdy taki schemat musisz sobie wypisać i użyć LUB żeby użyć wielu takich wyrażeń. Wówczas łatwiej ci będzie wyłuskiwać tylko to co chcesz.



tak, to jest uproszczony odpowiednik [^0-9], możesz zrobić coś takiego: [\w\/-] tylko wówczas może to być zbyt bardzo zachłanne. Tutaj poprawione dla przykładów które podesłałeś: https://regex101.com/r/lnoaih/2

nie mniej, próbuj to ugrać poprzez wyrażenie per format, wówczas łatwiej ci będzie połączyć kilka takich wyrażeń w jedno, lub skrócić wyrażenie, bo będziesz miał "szerszy obraz".

https://regex101.com/r/IzEGsc/2

@aras785 you're welcome.



Istnieje coś takiego jak nativescript, nie powiem ci za wiele o tym projekcie, ale obsługuje zarówno angulara jak i vue.js: https://www.nativescript.org
Może powiem ci dlaczego mówię ci o tym vue.js; głównie dlatego że angular ma pewne "wymagania", musisz się nauczyć typescriptu, oraz samej filozofii tego frameworka. Nie jest to zadanie trywialne i o ile nie chcesz całkowicie iść w tym kierunku, to po prostu tracisz czas. To jest jak różnica między SF a LV, w LV wejdziesz szybko i szybko zaczniesz robić rzeczy, do SF potrzebujesz trochę czasu. Nie ma tutaj lepszej/gorszej technologii, tutaj porównuje jedynie krzywą nauczania się.



Też to lubię i w pełni rozumiem.



Ja będę miał 31 w tym roku, jestem najstarszy z swojego zespołu i gdzieś dość wysoko w całej firmie. Zacząłem również niedawno, etatowo pracuje prawie 5 lat. Wcześniej to było tylko hobby, tak jak u ciebie. W sumie to nawet był przypadek że zacząłem programować. Więc w większej mierze cię rozumiem. Za pół roku będziesz miał zapewne już 39, za pół roku może coś wypaść i będziesz musiał przesunąć termin. Serio, idź i próbuj, odpowiedzi i tak nie dostaniesz zapewne z dnia na dzień, w niektórych firmach HR się tak opiernicza, że możesz tygodniami ciągnąć rekrutację. Nie widzę powodu dla którego miałbyś z tym tematem zwlekać, zwłaszcza że te tematy o których piszesz, możesz ciągnąć równolegle, przynajmniej przez jakiś czas. Jak masz swoją działaność, to nawet łatwiej będzie cię przyjąć, bo sporo firm woli B2B.

Moim zdaniem nie ma sensu czekać. Próbuj już teraz. Przechodziłem tą drogę, tj nie mam technicznego wykształcenia, mam tylko zawodowe (kucharz), przed rozpoczęciem jakiejkolwiek pracy najpierw dałem sobie kilka miesięcy (pół roku w sumie wyszło) zrobiłem w tym czasie kilka zleceń, siedziałem po nocach i czytałem dokumentacje, lub przeglądałem przykłady i analizowałem kod. Mimo obaw że jestem za słaby itp itd okazało że się nadawałem, w między czasie dalej się "uczyłem" (głównie poprzez rozwiązywanie problemów które mają inni), rozwiązywałem też problemy w firmie w której pracowałem i poszło to zdecydowanie do przodu.

Możesz chcieć jakichś super wyzwań, każdego dnia coś nowego itp itd ale realia są inne i się nie nastawiaj na pisanie oprogramowania do sterowania rakiet, bo się zawiedziesz. Popracuj w jednej firmie, zobacz jak się pracuje w grupie, naucz się jakichś nowych rzeczy, dopiero potem decyduj czy chcesz iść dalej, czy ci odpowiada jak jest. Raczej nie trafisz od razu na tą jedną firmę, a może nawet w miedzy czasie spodoba ci się inny kierunek rozwoju i będziesz chciał używać innych technologii. Jednocześnie nie nastawiaj się też żeby zostać w jednej firmie, bo stagnacja nie jest dla wszystkich oraz nie zawsze jest dobra.

Idź i próbuj, jak nie pójdziesz to się nie dowiesz; odkładanie tego w czasie w zasadzie niczego ci nie daje. A nawet jakbyś miał popracować pół roku w jakiejś firmie, to już będziesz miał jakieś referencje, już będziesz miał jakieś doświadczenie.

Koniec końców każdy z nas jest w większej lub mniejszej mierze samoukiem. To jak wyewoluował webdevelopment, jest zupełnie różne od tego czego mógłbyś się nauczyć w szkole/uczelni, nawet dzisiaj. Nawet książki wydane dzisiaj, mogą być przestarzałe, zwłaszcza w frontendzie, gdzie wszystko tak szybko ewoluuje, że nadążenie za tymi zmianami jest niemożliwe przez wydawców lub szkoły/uczelnie.


PS mała rada, zostaw angulara, zacznij od czegoś prostszego, w stylu vue.js; będziesz w stanie robić swoje single page applications po jednym weekendzie.

Szyfruje serwer, nie ty. Serwer HTTP, czyli apache/nginx, nie ty. Taki serwer musi mieć dostęp do certyfikatu i klucza prywatnego użytego do podpisania certyfikatu. Taki serwer się konfiguruje żeby używał certyfikatu i klucza do szyfrowania ruchu.

Certyfikat nie musi znajdować się tam gdzie znajdują się twoje serwery, bo "przed" serwerem może być loadbalancer/proxy który ten ruch będzie rozkładać pomiędzy serwerami i taki loadbalancer/proxy będzie szyfrować ruch.

https://www.youtube.com/watch?v=I7aGWO6K3Ho

BTW phpstorm/webstorm zawsze będą odpalać nowe kontenery, nigdy nie będą podłączać się pod istniejące, dlatego też @mrc napisał o tym że kontener który startuje musi mieć podaną sieć, a docker-compose odpalony za pierwszym razem tworzy taką sieć która nazwya się zazwyczaj od nazwy katalogu w którym trzymasz swój projekt.

czyli nie masz programu "python" który mógłby wykonać polecenie które wpisałeś w konsoli/terminalu. Wyobraź sobie to tak: chcesz uruchomić skrypt za pomocą programu, którego nie masz.

Ten obraz wymaga pewnych "kroków" instalacyjnych, co jest opisane: https://hub.docker.com/_/php/



więc całkowicie źle do tego się zabierałeś, jednocześnie masz brak dostępnych "pakietów" dlatego że lista pakietów nie została zaktualizowana, zawsze się na początku aktualizuje listę pakietów via:



Druga sprawa że nie zainstalowałbyś w taki sposób tego pakietu, dlatego że ten obraz jest minimalny i do instalacji tego pakietu potrzebujesz dodatkowe rzeczy, między innymi g++ żeby pakiet skompilować.

40k to nie jest specjalnie dużo, wszystko zależy od tego jakiego rodzaju są to zapytania, na jakiej maszynie etc. nie mniej, wciąż nie jest to specjalnie dużo.

Nie da się zmienić mapingów, można do nich tylko coś dodać, ale nie można odjąć lub zmienić już istniejącą wartość.

Generalnie docker umożliwia ci dodanie volumenu, zbindowanie portu bez kasowania rzeczy, problem jest taki że nie umożliwia tego CLI. Docker wystawia serwer restowy (/var/run/docker.sock) z którego korzysta CLI i to samo CLI jest ograniczone nie umożliwiając tego.

Bardzo ci ułatwi zobaczenie na docker-compose, poszukanie jakichś gotowych kontenerów, a wierz lub nie, jest ich na pęczki. W samym 2016 było dostępnych przeszło 400k obrazów, aktualnie obstawiam że jest ich conajmniej 2x tyle.



na początek użyj czegoś gotowego, jak już będziesz miał wiedzę i wprawę to zrobisz coś swojego, lub dalej będziesz korzystać z gotowca jeżeli będzie cię satysfakcjonować.



Najlepiej testować przed wrzuceniem na produkcje Generalnie możesz sobie zbudować obraz lokalnie, uruchomić go i przetestować. Jak już będzie wszystko OK, to wrzucasz na registry ten swój obraz (prywatne, lub publiczne) i na swoim serwerze robisz docker run które ten zbudowany przetestowany obraz sobie pobierze.

Vagratn z racji że jest to pełna wirtualizacja nie współdzieli tych samych użytkowników/grup co host, a same chmody, grupy musisz dodawać przy samym odpaleniu vagranta via vagrantfile i jest to przypisane do całego katalogu który współdzielisz.

Docker z drugiej strony, niczego nie wirtualizuje, tylko wrzuca twój program i jego pliki do czegoś w rodzaju sanboxa (cgroups + namespaces), a sam kernel jest współdzielony. Więc jeżeli w dockerze chcesz mieć użytkownika lub grupę to musisz mieć ją utworzoną na hoście, a same współdzielone "foldery" są raczej czymś w rodzaju dowiązania, niż jakiegoś zasobu typu nfs jak to ma miejsce w vagrancie. Różnica w wydajności kosmiczna.

Trochę źle podchodzisz do tego. Dlaczego ZF1 ma jakiegoś liba do uploadu do np s3, a ZF2+ tego nie ma? Kiedyś szło się w kierunku pakowania wszystkiego i robienia kobyły, od dłuższego czasu się odchodzi od takiego podejścia, bo po co wydawać nową wersję FW, skoro zaktualizował się tylko jeden lib który nie ma żadnego wpływu na FW samego w sobie? Teraz wszelkiej maści rzeczy które nie są kluczowe do działania samego FW, rozbija się na moduły/bundle/pakiety/liby/jakkolwiek inaczej to nazywają. Więc jeżeli szukasz czegoś, to szukasz jako dodatku, przykładowo ZF2: https://github.com/aws/aws-sdk-php-zf2 a tutaj np dla SF: https://github.com/aws/aws-sdk-php-symfony albo tutaj dla laravela: https://github.com/aws/aws-sdk-php-laravel albo może po proprostu zwykły php: https://github.com/aws/aws-sdk-php

Jak widzisz, nie pochodzą te liby/sdk od twórców tych frameworków, to jest kolejna rzecz dlaczego te rzeczy nie są przyspawane do frameworków. Takie serwisy rozwijają swoje liby/sdk w swoim cyklu wydawniczym, a frameworki rozwijają się w swoim cyklu wydawniczym. Nic niczego nie blokuje, nic od niczego nie zależy.

FW nie ma znaczenia podczas uploadu plików. Twórz w tym czym ci wygodniej (odradzam generalnie ZF w jakiejkolwiek wersji - wciąż mam koszmary po ZF1), w czym szybciej stworzysz swój serwis.

@ dvdx95 - aby móc nasłuchiwać szyfrowanych połączeń, musisz użyć odpowiedniego liba, w tym przypadku zamiast http, musisz użyć https i podać mu ścieżki do certyfikatów: https://nodejs.org/api/https.html#https_htt...requestlistener

Działa to identycznie jak w każdym jednym serwerze http, jak potrzebujesz w nginxie https'a to musisz podłączyć certyfikaty i połączenie na danym porcie oznaczyć jako ssl; identycznie w przypadku apache czy jakiegokolwiek innego serwera/proxy/reverse proxy.

Nie można podłączyć pod domenę certyfikatu, domena to jest tylko informacja o którą przeglądarka odpytuje serwer dns, który dopiero zwraca właściwy adres serwera. Dla przykładu dla domeny google:



Powinno zwrócić ci coś takiego:



Wówczas przeglądarka wie że ma wysyłać żądania do serwera pod tym adresem IP.

Certyfikaty podłącza się pod serwery http, które szyfrują przesyłane informacje za pomocą tego certyfikatu.

SSH - Secure Shell. Nic dziwnego że nie widzisz GUI bo się podłączasz pod konsole/terminal. To co potrzebujesz, to klient do zdalnego pulpitu, w przypadku ubuntu np remmina: https://www.remmina.org/wp/

Pierwszy VPS, pierwszy linuks. Może lepiej jak odpalisz sobie lokalnie? Np poprzez virtualboxa?

Tak na przyszłość: na serwerach się praktycznie nie używa pulpitów, głównie terminal. Więc nie próbuj ogarnąć pulpitu, tylko ogarnij terminal.

Nie do końca chodziło mi o sam fakt działania aplikacji z systemu A na systemie B, bardziej mi chodziło i braki jakie inne systemy mają w stosunku do linuksa. Największym brakiem w tym przypadku jest przyspawanie systemu do pewnych rozwiązań i zamknięcie się na wszystko to co dzieje się dookoła. Windows jest tutaj pięknym przykładem takiego lock-in, nie da się tam użyć jakiegoś zaawansowanego systemu plików pokroju btrfs, nie da się użyć niczego poza NTFS/FAT*, chyba że jest to partycja nie systemowa to wtedy można skorzystać z ReFS o ile masz licencje na "lepszego" windowsa.

Nie mniej, znalezisko godne uwagi, nie widziałem tego, ale na szybko przetestowałem przed chwilą - zaskakujące rezultaty. Wcześniej jak odpalałem testy, to szły na maku jak krew z nosa (kiło kilku minut), gdzie na AWS'ie na instancji t2.micro (1CPU+1GB ram - vps za ~35zł miesięcznie) takie testy przechodziły poniżej 30 sekund. Teraz po dodaniu cached (pliki) i delegated (baza danych) testy przechodzą w podobnym czasie co na maszynie z linuxem. Zajebiscie.

Użyj oficjalnych obrazów i posklejaj to sobie w docker-compose. Jest to trochę dodatkowej wiedzy, ale dzięki temu będziesz wiedział jak działa całe twoje środowisko, a nie musiał się zastanawiać, dlaczego coś gdzieś ci muli. Polecam korzystać z obrazów gdzie bazą jest alpine (często w tagach jest np nginx:alpine), głównie ze względu na ich minimalizm oraz wydajność.

Tak, ale wciąż są dwa różne systemy plików, z dwiema różnymi cechami (uprawnienia, przestrzenie, symlinki, ioevents etc), takie połączenie między dwoma systemami musi zapewne lecieć po jakiejś wewnętrznej sieci (SMB), problemem nie są tyle co duże pliki, co dużo małych plików. Dlatego czasy odczytów są fatalne. I zawsze będą.



Odpal sobie a następnie sprawdź ile masz volumenów, oraz w jaki sposób one są podmontowane. Dla przykładu, w katalogu projektu będziesz miał najczęściej: katalog ".git" który może być spory, katalog ".idea" jeżeli korzystasz z phpstorma i zapewne temu podobne. Wszystkie te katalogi są ci w ogóle niepotrzebne w samym kontenerze, a ciągłe aktualizacje w tych katalogach po prostu nadużywa i tak już wolnego "połączenia" pomiędzy wirtualką z dockerem a samym windowsem/makiem. A z tego co widzę po tych plikach, to tam nawet baza danych jest zmontowana lokalnie, co daje kolejny ogromny narzut. Użyj jakiegoś innego rozwiązania, gdzie będziesz miał rzeczy które są ci potrzebne i porównaj czy wciąż będzie to chodzić tak gównianie.



To jest wina windowsa, jak i osx'a. Gdyby te systemy w jakiś łatwiejszy sposób umożliwiały czy to wirtualizowanie czy konteneryzowanie innych systemów, o obsłudze innych niż "słuszne" NTFS systemów plików nie wspominając (oczywiście w przypadku windowsa), to by się to wszystko lepiej integrowało. A tak z racji sporych różnic pomiędzy systemami, powstała proteza, żeby użytkownicy windowsa czy osx'a nie byli gorsi i mieli swojego "natywnego" dockera, bo wiadomo, teraz kontenery są hiper popularne. Na codzień pracuje na osx'ie, wcześniej pracowałem głównie na ubuntu i przejście było najbardziej bolesne, kiedy się okazało jakim kastratem jest osx pod względem narzędzi developerskich na których dotychczas pracowałem. Nie zrozumcie mnie źle, windows, mak czy linuks to są dobre systemy i każde z nich ma swoje zalety i wady. Jako że dla mnie istotny jest development, to z automatu na samym końcu ląduje windows. Maka mocno ratuje społeczność i uniksowa kompatybilność. Gdyby stworzyli coś zupełnie swojego, zapewne byłoby tak samo jak z windowsem..


Aby podsumować ten wywód, na windowsie czy maku istotne jest to co montujecie. Jak twój projekt jest w katalogu `~/projects/my-project` a w katalogu projektu istotne są tylko katalogi `~/projects/my-project/vendor` i `~/projects/my-project/src`; to montujcie tylko te dwa katalogi, zamiast całego katalogu z projektem. Nie montujcie plików z bazy danych - użyjcie named volumes (nie przepadną wam dane, ale nie będziecie tego montować lokalnie). Jak pracujecie na wersjach developerskich aplikacji, mimo wszystko włączajcie cache i inne. Jeżeli w projekcie macie pliki które mają różną wielkość znaków, pilnujcie żeby odwołania do tych plików były prawidłowe, z racji tego że windows czy mak ignorują wielkość znaków (na maku można to wyłączyć) to będzie wam szukało plików w kilku wariantach, co będzie minimalnie wolniejsze.

Jeżeli mimo tego aplikacja działa wolno, a dockera używacie bo to jest "fajne", to zastanówcie się nad po prostu instalacją projektu lokalnie. U mnie używam kontenerów w developmencie, stagingu oraz produkcji. Nie mniej, debugowanie kodu lokalnie, w kontenerach do których nie ma się łatwego dostępu (w przypadku maków ułomna jest też sieć, nie istnieje interfejs docker0 dzięki któremu można dostać się do kontenera po jego IP, trzeba wszystko bindować lokalnie i dostawać się po localhost..), staram się aby tylko bazy danych działały w kontenerach, a samą aplikacje odpalam lokalnie i łącze się do tych baz danych. Nie ma innego wyjścia, trzeba sobie jakoś radzić..

Natywnie to działa to tylko na linuxie. Na Windowsie to leci po SMB, z prędkością rzędu 20MB/s i bóg wie jakimi opóźnieniami. Podobnie jest na makach, leci to po jakimś "osxfs" co działa na podobnej zasadzie jak NFS czy SMB, czyli lecą poliki po sieci. Już sam czas dostępu przy języku interpretowany, gdzie każdy jeden plik, z setek istniejących, musi zostać pobrany i zinterpretowany, wystarczy żeby aplikacja muliła jak cholera.


Nie działa to natywnie, wciąż działa to w wirtualnych maszynach, z różnymi systemami plików, których system hosta w ogóle nie rozumie. Natywnie na windowsie może działać kiedy odpalasz kontenery zrobione pod windowsa. Kiedy odpalasz linuxowe kontenery na windowsie, odpala się wirtualka i zaczynają się problemy.

Osobiście staram się jak najmniej rzeczy montować jako wolumen, np zamiast całego katalogu projektu, rezultaty są całkiem zadowalające, aczkolwiek bardzo im daleko do tego jak to działa natywnie na linuksie..

Docker na maku czy windowsie działa w wirtualce, więc masz NFS pomiędzy wirtualką a twoim dyskiem, kto kiedyś w vagrancie robił volumeny to wie że jest to bardzo wolne. Dodatkowo zależy co masz namyśli "lokalna maszyna". Jeżeli mówisz o laptopie, to nie, dedyk będzie znacznie lepszy niż niskonapięciowe CPU.

Nie mniej, bardzo często w takiej konfiguracji mysql czy inne bazy po prostu muszą swoje cache rozruszać. Na start nigdy tam nie ma cache, ono zawsze się tworzy pasywnie. Więc wystarczy że poużywasz i powinno się rozruszać. Nie mniej, nie polecam takich kobył używać produkcyjnie, bo to jest drobny żart taki zlepek.