🚀 go-pugleaf

Dnia Fri, 14 Dec 2018 22:59:34 +0100, Marek S napisał(a):

> Uczę się Laravela. Zauważyłem, że ściągnięty framework zajmuje aż 32MB. 
> Nie chodzi mi o przestrzeń dyskową lecz o czas przesyłania pierdyliona 
> plików bardziej. Czy wszystkie one są potrzebne?

Ty tak serio pytasz? Mamy już prawie 2019 rok, 32MB to nie jest jakiś
problem. Spróbuj kiedyś zrobić `npm install` w większym projekcie w node,
to się przewrócisz z wrażenia. Ja mam taki "folderek" będący tylko źródłem
zależności i źródeł dla gulpa. 1.42GB.

Do tego każdy sensowny hosting powinien mieć ssh, gdzie sobie zrobisz
`composer install`, zamiast przerzucać katalog `vendor`.

A sam Laravel to zaledwie 3MB.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu 2018-12-16 o 12:29, Borys Pogoreło pisze:

> 
> Ty tak serio pytasz? Mamy już prawie 2019 rok, 32MB to nie jest jakiś
> problem. Spróbuj kiedyś zrobić `npm install` w większym projekcie w node,
> to się przewrócisz z wrażenia. Ja mam taki "folderek" będący tylko źródłem
> zależności i źródeł dla gulpa. 1.42GB.

Ściągnięcie z serwera w USA tych 32MB trwało całą noc. Mniej więcej 
jeden plik na sekundę pobierał się. Po godzinie oczekiwania poszedłem do 
domu bo wiedziałem, że nie ma sensu czekać.

> Do tego każdy sensowny hosting powinien mieć ssh, gdzie sobie zrobisz
> `composer install`, zamiast przerzucać katalog `vendor`.

SSH nie załatwi sprawy przy ściąganiu danych. Lokalnie też nie miałbym 
gwarancji, że zainstalowanie frameworka composerem da mi dokładnie te 
same pliki, co u klienta.


-- 
Pozdrawiam,
Marek

On 2018-12-16, Marek S <precz@spamowi.com> wrote:

[...]

>> to się przewrócisz z wrażenia. Ja mam taki "folderek" będący tylko źródłem
>> zależności i źródeł dla gulpa. 1.42GB.
>
> Ściągnięcie z serwera w USA tych 32MB trwało całą noc. 

Korzystasz z modemu? O.o

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

W dniu 2018-12-16 o 17:00, Wojciech Bancer pisze:

>> Ściągnięcie z serwera w USA tych 32MB trwało całą noc.
> 
> Korzystasz z modemu? O.o

Nie bierzesz jednego pod uwagę: w USA jest stara infrastruktura 
internetowa. Np. na Florydzie można przy domach na wynajem zobaczyć 
reklamę "szybki internet 10Mbps!" :-)

Wcale nie jest rzadkością, że nawet spore przedsiębiorstwa jadą na 
prehistorycznych prędkościach sieci. Nie wiem czy wiesz, ale np. sieć 
komórkowa działa na poziomie 3G u nich. LTE dostępny jest w centrach 
dużych miast jedynie.

-- 
Pozdrawiam,
Marek

On 2018-12-16, Marek S <precz@spamowi.com> wrote:

[...]

> Nie bierzesz jednego pod uwagę: w USA jest stara infrastruktura 
> internetowa. Np. na Florydzie można przy domach na wynajem zobaczyć 
> reklamę "szybki internet 10Mbps!" :-)

Masz bardzo błędne wyobrażenie.
Anyway - "u mnie działa", problem jest ewidentnie po Twojej stronie.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

W dniu 2018-12-16 o 17:11, Wojciech Bancer pisze:

> Masz bardzo błędne wyobrażenie.
> Anyway - "u mnie działa", problem jest ewidentnie po Twojej stronie.

Sorki, to nie są wyobrażenia lecz realizm. Chcesz powiedzieć, że bzdury 
gadam odnośnie prędkości 3G i internetu 10M traktowanego tam jako 
szybki? Bo nie bardzo łapię intencje.

-- 
Pozdrawiam,
Marek

Dnia Sun, 16 Dec 2018 16:40:57 +0100, Marek S napisał(a):

> Ściągnięcie z serwera w USA tych 32MB trwało całą noc. Mniej więcej 
> jeden plik na sekundę pobierał się. Po godzinie oczekiwania poszedłem do 
> domu bo wiedziałem, że nie ma sensu czekać.

To jest jakaś chora sytuacja, a nie norma.

> SSH nie załatwi sprawy przy ściąganiu danych. Lokalnie też nie miałbym 
> gwarancji, że zainstalowanie frameworka composerem da mi dokładnie te 
> same pliki, co u klienta.

Oczywiście, że da. O to w tym rozwiązaniu przecież chodzi. Sprawdź sobie
zawartość pliku `composer.lock`.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On 2018-12-16, Marek S <precz@spamowi.com> wrote:

[...]

>> Masz bardzo błędne wyobrażenie.
>> Anyway - "u mnie działa", problem jest ewidentnie po Twojej stronie.
>
> Sorki, to nie są wyobrażenia lecz realizm. Chcesz powiedzieć, że bzdury 
> gadam odnośnie prędkości 3G i internetu 10M traktowanego tam jako 
> szybki? Bo nie bardzo łapię intencje.

Bzdury gadasz insynuując, że kod frameworka ściąga się z serwera
o parametrach typu "łącze 3G i internet 10Mbit/sek".

Nie wątpię, że gdzieś tam w stanach są osoby które mają łącza o podobnych,
a nawet niższych parametrach. W Polsce również. Ale serwery do których się 
dobijają skrypty typu composer, czy npm na takich łączach nie stoją.

Już nie mówiąc o tym, że tego typu repozytoria oprogramowania mają
mirrory i są kierowane geograficznie, więc to nie jest tak że radośnie 
ściągasz sobie ze stanów wszystko. To naprawdę nie jest jakaś kosmiczna 
wiedza. :)

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

W dniu 2018-12-16 o 18:11, Wojciech Bancer pisze:

>> Sorki, to nie są wyobrażenia lecz realizm. Chcesz powiedzieć, że bzdury
>> gadam odnośnie prędkości 3G i internetu 10M traktowanego tam jako
>> szybki? Bo nie bardzo łapię intencje.
> 
> Bzdury gadasz insynuując, że kod frameworka ściąga się z serwera
> o parametrach typu "łącze 3G i internet 10Mbit/sek".

Rany, wiem przecież ile czasu ściągałem te dane od klienta. Nie chodzi o 
transfery lecz o ilość małych plików. Przypuszczam, że ściągnięcie 
jednego ZIPa o tej samej wielkości trwałoby o dwa rzędy krócej.

> Nie wątpię, że gdzieś tam w stanach są osoby które mają łącza o podobnych,
> a nawet niższych parametrach. W Polsce również. Ale serwery do których się
> dobijają skrypty typu composer, czy npm na takich łączach nie stoją.

Z pewnością na tamtych serwerach nie ma żadnych composerów itp.Są to 
zwykłe aplikacje klienckie rezydujące na paru (lub więcej) serwerach 
różnych firm. W dodatku są to lokalne serwery bo działają na plikach 
graficznych a przesyłanie np. set-megabajtowych PSDków super szybkim 
kablem jak na ichnie standardy: np. 10M, do jakiegoś dostawcy i z 
powrotem nie pozwalało firmom na pracę. Więc g..niane zewnętrzne łącza 
(pewnie jeszcze asymetryczne), to tam norma.

> Już nie mówiąc o tym, że tego typu repozytoria oprogramowania mają
> mirrory i są kierowane geograficznie, więc to nie jest tak że radośnie
> ściągasz sobie ze stanów wszystko. To naprawdę nie jest jakaś kosmiczna
> wiedza. :)

Szczerze mówiąc nie bardzo widzę związek z tym, co napisałem. Jakie 
repozytoria? Jakie mirrory? Ja ściągam/wypycham konkretnym VPNem z 
konkretnych serwerów, o konkretnym IP, konkretne dane! TO SĄ SIECI 
PRYWATNE FIRM!

-- 
Pozdrawiam,
Marek

W dniu 2018-12-16 o 17:37, Borys Pogoreło pisze:
> 
> To jest jakaś chora sytuacja, a nie norma.

U nich norma. I to w różnych stanach tak jest. Do tej pory 4 lokalizacje 
korporacyjne stamtąd ogarniałem i wszędzie się żalili na wolne łącza. A 
to 3G gdziebyś się nie ruszył, to tak tam jest. Nic na to nie poradzę.

>> SSH nie załatwi sprawy przy ściąganiu danych. Lokalnie też nie miałbym
>> gwarancji, że zainstalowanie frameworka composerem da mi dokładnie te
>> same pliki, co u klienta.
> 
> Oczywiście, że da. O to w tym rozwiązaniu przecież chodzi. Sprawdź sobie
> zawartość pliku `composer.lock`.

Szczerze mówiąc nie wiem czy nie pousuwali tych plików. Ale przyjrzę się 
bo może faktycznie będzie lepiej lokalnie framework pobierać. Liczę na 
to, że w kopiach klienckich nikt nie grzebał.

-- 
Pozdrawiam,
Marek

On 2018-12-16, Marek S <precz@spamowi.com> wrote:

[...]

>>> Sorki, to nie są wyobrażenia lecz realizm. Chcesz powiedzieć, że bzdury
>>> gadam odnośnie prędkości 3G i internetu 10M traktowanego tam jako
>>> szybki? Bo nie bardzo łapię intencje.
>> 
>> Bzdury gadasz insynuując, że kod frameworka ściąga się z serwera
>> o parametrach typu "łącze 3G i internet 10Mbit/sek".
>
> Rany, wiem przecież ile czasu ściągałem te dane od klienta. Nie chodzi o 
> transfery lecz o ilość małych plików. Przypuszczam, że ściągnięcie 
> jednego ZIPa o tej samej wielkości trwałoby o dwa rzędy krócej.

Z niecierpliwością czekam aż odkryjesz że istnieją wydajniejsze protokoły
niż FTP.

[...]

> Z pewnością na tamtych serwerach nie ma żadnych composerów itp.Są to 
> zwykłe aplikacje klienckie rezydujące na paru (lub więcej) serwerach 
> różnych firm. W dodatku są to lokalne serwery bo działają na plikach 
> graficznych a przesyłanie np. set-megabajtowych PSDków super szybkim 
> kablem jak na ichnie standardy: np. 10M, do jakiegoś dostawcy i z 
> powrotem nie pozwalało firmom na pracę. Więc g..niane zewnętrzne łącza 
> (pewnie jeszcze asymetryczne), to tam norma.

Ty się naprawdę z przeszłości urwałeś. Co robiłeś przez ostatnie 20 lat
z hakiem? :)

[...]

> Szczerze mówiąc nie bardzo widzę związek z tym, co napisałem. Jakie 
> repozytoria? Jakie mirrory? Ja ściągam/wypycham konkretnym VPNem z 
> konkretnych serwerów, o konkretnym IP, konkretne dane! TO SĄ SIECI 
> PRYWATNE FIRM!

No widzę, że nie widzisz.

Ręczne wypychanie plików, prawdopodobnie FTPem, bez repozytoriów 
oprogramowania. Lata 90-te pełną gębą, gdzieś Ty się uchował :)

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

On 2018-12-16, Marek S <precz@spamowi.com> wrote:

[...]

>> To jest jakaś chora sytuacja, a nie norma.
>
> U nich norma. I to w różnych stanach tak jest. Do tej pory 4 lokalizacje 
> korporacyjne stamtąd ogarniałem i wszędzie się żalili na wolne łącza. A 
> to 3G gdziebyś się nie ruszył, to tak tam jest. Nic na to nie poradzę.

Nie. To ni e jest norma.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

W dniu 2018-12-17 o 20:42, Wojciech Bancer pisze:
> 
> Z niecierpliwością czekam aż odkryjesz że istnieją wydajniejsze protokoły
> niż FTP.

W PHPStorm? Jak?


-- 
Pozdrawiam,
Marek

W dniu 2018-12-17 o 20:43, Wojciech Bancer pisze:
> 
> Nie. To ni e jest norma.
> 

Ok, więc pewnie miałeś lepszy telefon ściągający LTE nawet na pustyni.

Jak gadam z kolegami z USA, z różnych stanów, to oni sami twierdzą, że 
mają kiepskie łącza w firmach. Być może kłamią. Nie wykluczam. Niebawem 
wybieram się tam na 2 tygodnie więc zweryfikuję Twoją opinię.

-- 
Pozdrawiam,
Marek

On 2018-12-18, Marek S <precz@spamowi.com> wrote:

[...]

>> Z niecierpliwością czekam aż odkryjesz że istnieją wydajniejsze protokoły
>> niż FTP.
>
> W PHPStorm? Jak?

Przez gita chociażby.

I na serwer też buduje się to lokalnie, a nie lata niepotrzebnie
po FTP. Taki proces nazywa się "deployment".

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

On 2018-12-18, Marek S <precz@spamowi.com> wrote:

[...]

> Jak gadam z kolegami z USA, z różnych stanów, to oni sami twierdzą, że 
> mają kiepskie łącza w firmach. Być może kłamią. Nie wykluczam. Niebawem 
> wybieram się tam na 2 tygodnie więc zweryfikuję Twoją opinię.

Ja teraz mam połączenie z siecią w stanach i wyciągam ok. 30Mbit/sek
w obie strony (sam, bo oczywiście jest więcej osób w firmie). 
W zupełności wystarczające by 32MB pobierać niż noc, czyż nie?

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

W dniu 18.12.2018 o 22:14, Wojciech Bancer pisze:
> On 2018-12-18, Marek S <precz@spamowi.com> wrote:
> 
> [...]
> 
>> Jak gadam z kolegami z USA, z różnych stanów, to oni sami twierdzą, że
>> mają kiepskie łącza w firmach. Być może kłamią. Nie wykluczam. Niebawem
>> wybieram się tam na 2 tygodnie więc zweryfikuję Twoją opinię.
> 
> Ja teraz mam połączenie z siecią w stanach i wyciągam ok. 30Mbit/sek
> w obie strony (sam, bo oczywiście jest więcej osób w firmie).
> W zupełności wystarczające by 32MB pobierać niż noc, czyż nie?
> 

Typowa odpowiedź administratora: u mnie działa :)

On 2018-12-19, Tomek <skowtm@wp.xx.pl> wrote:

[...]

>> Ja teraz mam połączenie z siecią w stanach i wyciągam ok. 30Mbit/sek
>> w obie strony (sam, bo oczywiście jest więcej osób w firmie).
>> W zupełności wystarczające by 32MB pobierać niż noc, czyż nie?
>> 
>
> Typowa odpowiedź administratora: u mnie działa :)

No oczywiście. :) Przy czym ja wiem czemu jemu nie działa, aczkolwiek
nadal uważam, że jeśli nikt z tym nic nie robi, to mamy do czynienia
z kimś kto zaspał i nie zauważył że lata 90-te minęły i że FTP
jest nie tylko mało bezpieczny, ale również tragicznie wolny.

Już nie mówiąc o tym, że tego typu rozbudowane frameworki często
mają dodatkowe czynności do wykonania "na serwerze", np. wyczyszczenie
cache, uruchomienie migracji danych itp. i tego typu poleceń się
przez FTP nie wprowadzi.

Nie ma co zwalać "na łącze" i złą architekturę, kiedy mamy do czynienia 
z wadą protokołu (FTP daje ogromny narzut czasowy przy przesyłaniu 
każdego pliku i dużych opóźnieniach do serwera co właśnie szczególnie 
widać przy takich tysiącach malutkich pliczków i transmisji na odległość
do USA).

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

W dniu 2018-12-18 o 22:13, Wojciech Bancer pisze:

>>> Z niecierpliwością czekam aż odkryjesz że istnieją wydajniejsze protokoły
>>> niż FTP.
>>
>> W PHPStorm? Jak?
> 
> Przez gita chociażby.
> 
> I na serwer też buduje się to lokalnie, a nie lata niepotrzebnie
> po FTP. Taki proces nazywa się "deployment".

Zapewne długo byś czekał aż odkryję, że Git wykorzystuje coś innego niż 
FTP bo zapewne nigdy bym tego nie dochodził. Robię git push i mam w 
głębokim poważaniu, co dzieje się behind the scenes.

-- 
Pozdrawiam,
Marek

On 2018-12-22, Marek S <precz@spamowi.com> wrote:

[...]

>> Przez gita chociażby.
>> 
>> I na serwer też buduje się to lokalnie, a nie lata niepotrzebnie
>> po FTP. Taki proces nazywa się "deployment".
>
> Zapewne długo byś czekał aż odkryję, że Git wykorzystuje coś innego niż 
> FTP bo zapewne nigdy bym tego nie dochodził. Robię git push i mam w 
> głębokim poważaniu, co dzieje się behind the scenes.

Nie, nie używa. Nie wiem co robisz, ale skoro wysyłanie/odbieranie 32MB
trwa u Ciebie całą noc, to robisz to bardzo nieefektywnie i tyle.
I czepiam się tylko sformułowania że jest to norma "bo to Stany". 
Nie jest.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

On Tue, 18 Dec 2018 22:13:07 +0100, Wojciech Bancer wrote:

> [...]
> 
>>> Z niecierpliwością czekam aż odkryjesz że istnieją wydajniejsze protokoły
>>> niż FTP.
>>
>> W PHPStorm? Jak?
> 
> Przez gita chociażby.
> 
> I na serwer też buduje się to lokalnie, a nie lata niepotrzebnie
> po FTP. Taki proces nazywa się "deployment".

A możesz coś więcej o deplymencie napisać? Bo ja też obecnie jadę przez
FTPa i mnie trafia. Chociaż pewnie potrzebny jest do tego shell, a na
hostingu jaki obecnie mam niestety shella nie ma.
Niemniej ciekawi mnie czy deployment robisz gitem czy jak?
Tak czy owak napisz trzy słowa, thx.

-- 
pozdrawiam
Roman Tyczka

W dniu 2018-12-22 o 20:54, Wojciech Bancer pisze:

> Nie, nie używa. Nie wiem co robisz, ale skoro wysyłanie/odbieranie 32MB
> trwa u Ciebie całą noc, to robisz to bardzo nieefektywnie i tyle.
> I czepiam się tylko sformułowania że jest to norma "bo to Stany".
> Nie jest.

Być może nieefektywnie bo nie wiem jak inaczej można. Jest gdzieś jakiś 
serwer a na nim katalog z plikami. Zadanie: pobrać go na lokalny serwer. 
Więc co robię? Odpalam PHPStorm, wskazuję na interesujący mnie katalog i 
pobieram go. O ile transfery są ok, to ilość drobnych plików była 
porażająca.

Sugerowałeś jakiś czas temu by frameworka nie pobierać lecz composerem 
sprawę załatwić. Tylko ciekawe jak ustalić potrzebną wersję? Na zdalnym 
serwerze nie ma plików composera z zależnościami. Ściągnę więc nie tą 
wersję i potem będę miał jazdy.

-- 
Pozdrawiam,
Marek

W dniu 2018-12-23 o 13:30, Roman Tyczka pisze:
> A możesz coś więcej o deplymencie napisać? Bo ja też obecnie jadę przez
> FTPa i mnie trafia. Chociaż pewnie potrzebny jest do tego shell, a na
> hostingu jaki obecnie mam niestety shella nie ma.
> Niemniej ciekawi mnie czy deployment robisz gitem czy jak?
> Tak czy owak napisz trzy słowa, thx.

Przyłączam się do pytania

-- 
Pozdrawiam,
Marek

Sun, 23 Dec 2018 13:30:52 +0100      
Roman Tyczka <noemail@because.no>   napisał(a):

> On Tue, 18 Dec 2018 22:13:07 +0100, Wojciech Bancer wrote:
> 
> > [...]
> >   
> >>> Z niecierpliwością czekam aż odkryjesz że istnieją wydajniejsze protokoły
> >>> niż FTP.  
> >>
> >> W PHPStorm? Jak?  
> > 
> > Przez gita chociażby.
> > 
> > I na serwer też buduje się to lokalnie, a nie lata niepotrzebnie
> > po FTP. Taki proces nazywa się "deployment".  
> 
> A możesz coś więcej o deplymencie napisać? Bo ja też obecnie jadę przez
> FTPa i mnie trafia. Chociaż pewnie potrzebny jest do tego shell, a na
> hostingu jaki obecnie mam niestety shella nie ma.
> Niemniej ciekawi mnie czy deployment robisz gitem czy jak?
> Tak czy owak napisz trzy słowa, thx.

Naprawdę tak źle jest przez ftp? Protokół przecież nie jest jakoś nadzwyczajnie wolny,
pcha bity tyle, ile łącze pozwala i już. 
Buduję wszystko lokalnie, a potem jednym klikiem w skrypt z lftp różnicowo, to co chcę, 
idzie jak burza. (skrypt wpierw mi jeszcze np. gulpem skompresuje js i css, albo co tam jeszcze chcę, np. sitemap)

open ftp://${destLoginServerDir};
lcd ${localDir};
mirror --reverse --delete --only-newer --use-cache --verbose --allow-chown --no-umask --parallel=2 $exclude"




-- 
pozdrawiam, Peter

W dniu 2018-12-23 o 16:46, rePeter pisze:

> 
> Naprawdę tak źle jest przez ftp? 

1. Jeśli są lepsze metody to ja osobiście chętnie je poznam. Wojciech 
twierdzi, że FTP w webmasterstwie to urwanie się z przeszłości.

2. U mnie np. generując grafikę do większego projektu zawsze generuję 
komplet plików graficznych nawet jeśli tylko jeden fragment się zmienił. 
Więc jest to powiedzmy 50 małych plików o nowych sygnaturach czasowych. 
Zauważyłem, że w połączeniu z USA zwłoka czasowa pomiędzy każdym z tych 
plików wynosi ok 1s. Czyli mamy 50s na nic nie robieniu. Nie chodzi tu 
wcale o wielkość plików lecz o ilość. Gdybym przesłał jeden plik 
sumarycznej wielkości, to pewnie 49 sekund bym zaoszczędził. Gdy robisz 
takie korekty raz po raz, to trochę wkurza.

3. Przesiadam się na PHPStorma z Dreamweavera - tu też doświadczam 
kłopotu pewnego. FTP pod PHPStorm transferuje plik za plikiem. W DW 
równolegle to się odbywało. Na oko po 10 połączeń na raz. Wtedy FTP nie 
był aż tak dokuczliwy. Być może to kwestia ustawienia czegoś gdzieś.

-- 
Pozdrawiam,
Marek

Sun, 23 Dec 2018 19:10:27 +0100      
Marek S <precz@spamowi.com>   napisał(a):

> 3. Przesiadam się na PHPStorma z Dreamweavera - tu też doświadczam 
> kłopotu pewnego. FTP pod PHPStorm transferuje plik za plikiem. W DW 
> równolegle to się odbywało. Na oko po 10 połączeń na raz. Wtedy FTP nie 
> był aż tak dokuczliwy. Być może to kwestia ustawienia czegoś gdzieś.

Nie używam PHPStorma do przesyłania plików więc nie wiem,
w lftp (i zapewne w innych tego typu klientach) można przesyłać pliki równolegle.

Git chyba też specjalnych cudów nie dokona, jeśli używa http lub ssh do przesyłu.


-- 
pozdrawiam, Peter

On Mon, 24 Dec 2018 11:59:24 +0100, rePeter wrote:

>> 3. Przesiadam się na PHPStorma z Dreamweavera - tu też doświadczam 
>> kłopotu pewnego. FTP pod PHPStorm transferuje plik za plikiem. W DW 
>> równolegle to się odbywało. Na oko po 10 połączeń na raz. Wtedy FTP nie 
>> był aż tak dokuczliwy. Być może to kwestia ustawienia czegoś gdzieś.
> 
> Nie używam PHPStorma do przesyłania plików więc nie wiem,
> w lftp (i zapewne w innych tego typu klientach) można przesyłać pliki równolegle.
> 
> Git chyba też specjalnych cudów nie dokona, jeśli używa http lub ssh do przesyłu.

Tylko, że git wysyła różnice a nie całe pliki, to może dać kolosalnie mniej
danych do przesyłu.

-- 
pozdrawiam
Roman Tyczka

Mon, 24 Dec 2018 14:18:58 +0100      
Roman Tyczka <noemail@because.no>   napisał(a):


> > Git chyba też specjalnych cudów nie dokona, jeśli używa http lub ssh do przesyłu.  
> 
> Tylko, że git wysyła różnice a nie całe pliki, to może dać kolosalnie mniej
> danych do przesyłu.

OK, ale czy dla plików www ma to aż takie znaczenie?
jpga czy mpga nie wyśle zmienionego kawałka, natomiast skrypty php, js, css, to
właściwie małe pliczki, wydaje mi się, że bez znaczenia czy są przesyłane całe, czy ich
fragmenty. Dla mnie ważne aby szło hurtem i z automatu, różnice w sekundach nie robią
różnicy.
Ale muszę sobie przy okazji przeprowadzić jakiś test na żywym organizmie.

-- 
pozdrawiam, Peter

On Mon, 24 Dec 2018 14:46:24 +0100, rePeter wrote:

>>> Git chyba też specjalnych cudów nie dokona, jeśli używa http lub ssh do przesyłu.  
>> 
>> Tylko, że git wysyła różnice a nie całe pliki, to może dać kolosalnie mniej
>> danych do przesyłu.
> 
> OK, ale czy dla plików www ma to aż takie znaczenie?
> jpga czy mpga nie wyśle zmienionego kawałka, natomiast skrypty php, js, css, to
> właściwie małe pliczki, wydaje mi się, że bez znaczenia czy są przesyłane całe, czy ich
> fragmenty. Dla mnie ważne aby szło hurtem i z automatu, różnice w sekundach nie robią
> różnicy.
> Ale muszę sobie przy okazji przeprowadzić jakiś test na żywym organizmie.

Sam transfer FTP jest szybki, jak łącze, ale problemem jest sama obsługa
poleceń FTPowych, których przy setkach plików są setki, a dodatkowo każde
polecenie jest parsowane od nowa (protokół tekstowy). Także system plików
daje opóźnienie na otwieraniu, kasowaniu i pisaniu od nowa _każdego_ pliku,
to kosztowne sprawy. 
No i sprawa z boku tematu szybkości, choć czasem istotna. Gdy okaże się, że
coś jest nie tak i trzeba szybko przywrócić pooprzednią wersję to git zrobi
to w kilka sekund.

Wesołych Świąt wszystkim! :-)

-- 
pozdrawiam
Roman Tyczka

Mon, 24 Dec 2018 16:13:52 +0100      
Roman Tyczka <noemail@because.no>   napisał(a):

> On Mon, 24 Dec 2018 14:46:24 +0100, rePeter wrote:
> 
> >>> Git chyba też specjalnych cudów nie dokona, jeśli używa http lub ssh do
> >>> przesyłu.    
> >> 
> >> Tylko, że git wysyła różnice a nie całe pliki, to może dać kolosalnie mniej
> >> danych do przesyłu.  
> > 
> > OK, ale czy dla plików www ma to aż takie znaczenie?
> > jpga czy mpga nie wyśle zmienionego kawałka, natomiast skrypty php, js, css, to
> > właściwie małe pliczki, wydaje mi się, że bez znaczenia czy są przesyłane całe, czy
> > ich fragmenty. Dla mnie ważne aby szło hurtem i z automatu, różnice w sekundach nie
> > robią różnicy.
> > Ale muszę sobie przy okazji przeprowadzić jakiś test na żywym organizmie.  
> 
> Sam transfer FTP jest szybki, jak łącze, ale problemem jest sama obsługa
> poleceń FTPowych, których przy setkach plików są setki, a dodatkowo każde
> polecenie jest parsowane od nowa (protokół tekstowy). Także system plików
> daje opóźnienie na otwieraniu, kasowaniu i pisaniu od nowa _każdego_ pliku,
> to kosztowne sprawy. 

To chyba załatwia opcja parallel

> No i sprawa z boku tematu szybkości, choć czasem istotna. Gdy okaże się, że
> coś jest nie tak i trzeba szybko przywrócić pooprzednią wersję to git zrobi
> to w kilka sekund.

Ale mówimy o developowaniu lokalnie i wypuszczaniu gotowców na serwer.

> Wesołych Świąt wszystkim! :-)

Wesołych  👍





-- 
pozdrawiam, Peter

Dnia Sun, 23 Dec 2018 14:56:14 +0100, Marek S napisał(a):

> Sugerowałeś jakiś czas temu by frameworka nie pobierać lecz composerem 
> sprawę załatwić. Tylko ciekawe jak ustalić potrzebną wersję? Na zdalnym 
> serwerze nie ma plików composera z zależnościami. Ściągnę więc nie tą 
> wersję i potem będę miał jazdy.

To go wgraj i zacznij pilnować wersjonowania za jego pomocą.

Sprzątanie bałaganu nigdy nie jest łatwe.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

Dnia Sun, 23 Dec 2018 19:10:27 +0100, Marek S napisał(a):

> 3. Przesiadam się na PHPStorma z Dreamweavera - tu też doświadczam 
> kłopotu pewnego. FTP pod PHPStorm transferuje plik za plikiem. W DW 
> równolegle to się odbywało. Na oko po 10 połączeń na raz. Wtedy FTP nie 
> był aż tak dokuczliwy. Być może to kwestia ustawienia czegoś gdzieś.

Connection > Advanced > Concurrent connections limit

Czasem warto poklikać, zamiast się męczyć.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu 2018-12-26 o 17:56, Borys Pogoreło pisze:
> Dnia Sun, 23 Dec 2018 19:10:27 +0100, Marek S napisał(a):
> 
>> 3. Przesiadam się na PHPStorma z Dreamweavera - tu też doświadczam
>> kłopotu pewnego. FTP pod PHPStorm transferuje plik za plikiem. W DW
>> równolegle to się odbywało. Na oko po 10 połączeń na raz. Wtedy FTP nie
>> był aż tak dokuczliwy. Być może to kwestia ustawienia czegoś gdzieś.
> 
> Connection > Advanced > Concurrent connections limit
> 
> Czasem warto poklikać, zamiast się męczyć.


Ale... opis tej opcji jest dokładnie odwrotny:

Select this checkbox to have PhpStorm restrict the number of connections 
to be supported simultaneously and specify the maximum number of allowed 
connections in the field.

Teraz nie mam jak przetestować jak opcja działa ale z opisu wynika, że 
mogę w ten sposób narzucić ograniczenie na ilość jednoczesnych połączeń 
a nie zmusić PHPStorm do ich tworzenia.

Póki co udało mi się utworzyć dwa równoległe połączenia poprzez 
zaznaczenie folderu do uploadu i rozpoczęcie transmisji, a potem to samo 
z innym folderem gdy poprzednia transmisja trwa. Ale gdy zaznaczę oba na 
raz lub folder nadrzędny do nich, to pliki będą leciały gęsiego. Tak 
zaobserwowałem.

-- 
Pozdrawiam,
Marek

Dnia Wed, 26 Dec 2018 21:41:02 +0100, Marek S napisał(a):

> Select this checkbox to have PhpStorm restrict the number of connections 
> to be supported simultaneously and specify the maximum number of allowed 
> connections in the field.

Spróbuj tam wpisać np. 5 i zobacz co się stanie.

Akurat tej opcji nie testowałem, bo wrzucanie plików przez FTP to jest męka
i jeśli już muszę, to robię to z serwera na serwer.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

Wed, 26 Dec 2018 23:47:32 +0100      
Borys Pogoreło <borys@pl.edu.leszno>   napisał(a):

> Dnia Wed, 26 Dec 2018 21:41:02 +0100, Marek S napisał(a):
> 
> > Select this checkbox to have PhpStorm restrict the number of connections 
> > to be supported simultaneously and specify the maximum number of allowed 
> > connections in the field.  
> 
> Spróbuj tam wpisać np. 5 i zobacz co się stanie.
> 
> Akurat tej opcji nie testowałem, bo wrzucanie plików przez FTP to jest męka
> i jeśli już muszę, to robię to z serwera na serwer.

Porównujesz dwa różne pojęcia.
FTP to tylko protokół.
Z serwera na serwer też musisz to jakimś protokołem przesłać.


-- 
pozdrawiam, Peter

On 2018-12-23, Roman Tyczka <noemail@because.no> wrote:

[...]

>> I na serwer też buduje się to lokalnie, a nie lata niepotrzebnie
>> po FTP. Taki proces nazywa się "deployment".
>
> A możesz coś więcej o deplymencie napisać? Bo ja też obecnie jadę przez
> FTPa i mnie trafia. Chociaż pewnie potrzebny jest do tego shell, a na
> hostingu jaki obecnie mam niestety shella nie ma.
> Niemniej ciekawi mnie czy deployment robisz gitem czy jak?
> Tak czy owak napisz trzy słowa, thx.

Naprostsza wersja to:
https://deployer.org/
Oferuje np. rollbackm ale tak, wymaga SSH.

A przy bardziej zaawansowanych projektach mam postawionego CI, który
reaguje na commity gita z brancha do develop i do mastera, buduje
paczkę z wersją i instaluje na serwerze, robi migrację bazy (o ile
trzeba) itp.

A argument z hostingiem? Hostingi które dają SSH kosztują mniej niż
200 zł rocznie. Koszt czasu programisty wrzucającego dzielnie pliki 
ręcznie przewyższa tą kwotę już po jednej takiej akcji.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

On 2018-12-24, rePeter <no@spam.no> wrote:

[...]

>> równolegle to się odbywało. Na oko po 10 połączeń na raz. Wtedy FTP nie 
>> był aż tak dokuczliwy. Być może to kwestia ustawienia czegoś gdzieś.
>
> Nie używam PHPStorma do przesyłania plików więc nie wiem,
> w lftp (i zapewne w innych tego typu klientach) można przesyłać pliki równolegle.
>
> Git chyba też specjalnych cudów nie dokona, jeśli używa http lub ssh do przesyłu.

Gita można przede wszystkim użyć na maszynie docelowej, ma kompresję
i przesyła delty. Jakby nie skręcać, to równoległe przesyłanie plików
przez FTP jest i wolniejsze, i bardziej zawodne i niespecjalnie łatwo
jest zrobić rollback, sprawdzanie poprawności plików, wykonanie komend
na serwerze itp.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

Dnia Thu, 27 Dec 2018 01:19:49 +0100, rePeter napisał(a):

>> Akurat tej opcji nie testowałem, bo wrzucanie plików przez FTP to jest męka
>> i jeśli już muszę, to robię to z serwera na serwer.
> 
> Porównujesz dwa różne pojęcia.
> FTP to tylko protokół.
> Z serwera na serwer też musisz to jakimś protokołem przesłać.

I piszę o FTP. Między dwoma serwerami z solidną "rurą" nawet dużo
niewielkich plików przesyła się bardzo szybko w ten sposób.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

Dnia Thu, 27 Dec 2018 13:18:05 +0100, Wojciech Bancer napisał(a):

> Naprostsza wersja to:
> https://deployer.org/
> Oferuje np. rollbackm ale tak, wymaga SSH.

O, ciekawe, dzięki. W praktyce jest wygodniejsze, niż skrypty shella
(pominąwszy czytelniejszy i spójny format komunikatów)?

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On 2018-12-27, Borys Pogoreło <borys@pl.edu.leszno> wrote:

[...]

>> Naprostsza wersja to:
>> https://deployer.org/
>> Oferuje np. rollbackm ale tak, wymaga SSH.
>
> O, ciekawe, dzięki. W praktyce jest wygodniejsze, niż skrypty shella
> (pominąwszy czytelniejszy i spójny format komunikatów)?

No dla mnie jest, ale wiadomo że każdy ma swoje przyzwyczajenia.
Ja mam starsze projekty w symfony z tym skonfigurowane.

Tu masz oficjalnie wspierane recipe:
https://github.com/deployphp/deployer/tree/master/recipe
m.in. cake, laravel, symfony 2/3/4 (każdy ma inną strukturę).
A są jeszcze te 3rd party. No i bardzo łatwo to rozbudować poprzez
wstrzykiwanie się w eventy.

Typowo dla tego typu narzędzi - tworzy nowy katalog z wersją (iteracyjną), 
robi wszystko co ma robić i dopiero jak wszystko skończy poprawnie, to podmienia 
symlinka "current". Wstrzyknąć można np. migrację bazy danych (z symfony wspierany 
jest doctrine migration), potrafi też zadbać o prawa do zapisu wskazanych katalogów,
czyści cache itp.

Dość łatwo da się rozbudować o równoległy deploy na kilka serwerów.
Osobiście zacząłem używać po tym jak capifony umarł:
https://github.com/everzet/capifony
capistrano/symfony mi nie podpadł, a trzymanie ruby tylko dla tego
jednego frameworka było overkillem :)

Alternatywą (którą mi się zdarzało stosować w projektach JS) jest
też shipit + shipit-deploy. Pozwala np. budować sobie "gdzieś na boku"
taką aplikację javascript, a na serwer posłać tylko niezbędne 
pliki.

https://github.com/shipitjs/shipit/tree/master/packages/shipit-deploy

Ale w kategorii "mało kodzenia dużo efektu" deployer jest najlepszy :)

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

Dnia Thu, 27 Dec 2018 16:10:35 +0100, Wojciech Bancer napisał(a):

> Typowo dla tego typu narzędzi - tworzy nowy katalog z wersją (iteracyjną), 
> robi wszystko co ma robić i dopiero jak wszystko skończy poprawnie, to podmienia 
> symlinka "current". Wstrzyknąć można np. migrację bazy danych (z symfony wspierany 
> jest doctrine migration), potrafi też zadbać o prawa do zapisu wskazanych katalogów,
> czyści cache itp.

A tak z ciekawości - da się zrealizować scenariusze w rodzaju "deploy się
sypnął na dalszym etapie, więc wycofaj migracje w bazie, ale tylko te przed
chwilą wykonane"? Albo np. w jakiś sposób przekazać argumenty tylko do
jednego etapu procesu (przykładowo czasem chcę uruchomić tylko jeden Seeder
przy aktualizacji aplikacji Laravel)?

> Alternatywą (którą mi się zdarzało stosować w projektach JS) jest
> też shipit + shipit-deploy. Pozwala np. budować sobie "gdzieś na boku"
> taką aplikację javascript, a na serwer posłać tylko niezbędne 
> pliki.

Też sobie zapiszę. Na szczęście w JS nie mam takich projektów, by sięgać po
tak rozbudowane narzędzia.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On 2018-12-27, Borys Pogoreło <borys@pl.edu.leszno> wrote:

[...]

>> Typowo dla tego typu narzędzi - tworzy nowy katalog z wersją (iteracyjną), 
>> robi wszystko co ma robić i dopiero jak wszystko skończy poprawnie, to podmienia 
>> symlinka "current". Wstrzyknąć można np. migrację bazy danych (z symfony wspierany 
>> jest doctrine migration), potrafi też zadbać o prawa do zapisu wskazanych katalogów,
>> czyści cache itp.
>
> A tak z ciekawości - da się zrealizować scenariusze w rodzaju "deploy się
> sypnął na dalszym etapie, więc wycofaj migracje w bazie, ale tylko te przed
> chwilą wykonane"? Albo np. w jakiś sposób przekazać argumenty tylko do
> jednego etapu procesu (przykładowo czasem chcę uruchomić tylko jeden Seeder
> przy aktualizacji aplikacji Laravel)?

Możesz ustalać role poszczególnych serwerów (np. app/db) i przypisać odpowiednie
komendy do ról. Możesz wywołać poszczególne komendy, np:

dep database:migrate --roles=db
(w laravelu pewnie będzie dep artisan:migrate)

Tu masz więcej o możliwych podziałach tasków:
https://deployer.org/docs/tasks
w sekcji filtering.

Przy czym ja osobiście mam wpisane migracje do bazy tuż przed samym
linkowaniem do current, więc jak migracja bazy zawiedzie, to po prostu
nic się nie wykona (migrację pisze jako transakcyjne, więc jak coś pójdzie
nie tak, to z automatu pójdzie rollback na bazie).

Jeśli któraś faza nie wyjdzie, to "domyślnie" nic się nie zmieniło,
nie podmienił się link do wersji bieżącej, więc można cały proces 
ponowić od początku.

Wycofanie konkretnego etapu z bazy danych (już po tym jak deployment poszedł
i wszystko było ok) jeśli muszę, to już wykonuję na serwerze i przy założeniu,
że jest poprawnie wypełniona sekcja down() w migracjach. Ale szczerze mówiąc,
to wolę tak projektować system, by tego unikać, bo tego typu cofanie bazy to
proszenie się o kłopoty.

>> Alternatywą (którą mi się zdarzało stosować w projektach JS) jest
>> też shipit + shipit-deploy. Pozwala np. budować sobie "gdzieś na boku"
>> taką aplikację javascript, a na serwer posłać tylko niezbędne 
>> pliki.
>
> Też sobie zapiszę. Na szczęście w JS nie mam takich projektów, by sięgać po
> tak rozbudowane narzędzia.

Ja ostatnio jestem zakochany w serverless, więc siłą rzeczy więcej w node 
siedze. :-)

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

Dnia Thu, 27 Dec 2018 22:08:30 +0100, Wojciech Bancer napisał(a):

> Tu masz więcej o możliwych podziałach tasków:
> https://deployer.org/docs/tasks
> w sekcji filtering.

Ok, widzę, że seedery mógłbym rozwiązać przez input options.

> Przy czym ja osobiście mam wpisane migracje do bazy tuż przed samym
> linkowaniem do current, więc jak migracja bazy zawiedzie, to po prostu
> nic się nie wykona (migrację pisze jako transakcyjne, więc jak coś pójdzie
> nie tak, to z automatu pójdzie rollback na bazie).

A wtedy wchodzi MySQL, cały na biało, z implicit commit na ALTER TABLE...

> Wycofanie konkretnego etapu z bazy danych (już po tym jak deployment poszedł
> i wszystko było ok) jeśli muszę, to już wykonuję na serwerze i przy założeniu,
> że jest poprawnie wypełniona sekcja down() w migracjach. Ale szczerze mówiąc,
> to wolę tak projektować system, by tego unikać, bo tego typu cofanie bazy to
> proszenie się o kłopoty.

No niestety, na szczęście takie historie to rzadkość.

> Ja ostatnio jestem zakochany w serverless, więc siłą rzeczy więcej w node 
> siedze. :-)

E tam, jakieś nowoczesne fiu-bździu, kiedyś panie to były serwery ;)

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On 2018-12-27, Borys Pogoreło <borys@pl.edu.leszno> wrote:

[...]

>> Przy czym ja osobiście mam wpisane migracje do bazy tuż przed samym
>> linkowaniem do current, więc jak migracja bazy zawiedzie, to po prostu
>> nic się nie wykona (migrację pisze jako transakcyjne, więc jak coś pójdzie
>> nie tak, to z automatu pójdzie rollback na bazie).
>
> A wtedy wchodzi MySQL, cały na biało, z implicit commit na ALTER TABLE...

Ja bardziej postgresowy :)
Ale w takim razie pozostaje pisanie sensownych down();

>> Wycofanie konkretnego etapu z bazy danych (już po tym jak deployment poszedł
>> i wszystko było ok) jeśli muszę, to już wykonuję na serwerze i przy założeniu,
>> że jest poprawnie wypełniona sekcja down() w migracjach. Ale szczerze mówiąc,
>> to wolę tak projektować system, by tego unikać, bo tego typu cofanie bazy to
>> proszenie się o kłopoty.
>
> No niestety, na szczęście takie historie to rzadkość.

I tak lepiej to zautomatyzować niż ręcznie odpalać SQLki (a strona albo wali
500, albo ma maintenance mode na kilka godzin :)

>> Ja ostatnio jestem zakochany w serverless, więc siłą rzeczy więcej w node 
>> siedze. :-)
>
> E tam, jakieś nowoczesne fiu-bździu, kiedyś panie to były serwery ;)

Teraz serwery to się stawia przez infrastructure as a code i terraform :)

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com