🚀 go-pugleaf

On Sun, 24 Mar 2019 21:49:47 +0100, Marek S wrote:

> Zrobiłem lokalny projekt i chciałem go umieścić na serwerze. No to daję 
> FTP po całości, wychodzę do knajpy coś zjeść, robię zakupy w Żabce, 
> wracam... postęp 50%. Gdybym miał coś takiego w pracy robić, to książkę 
> do poczytania trzeba by zabrać.
> 
> Czy jest sposób na przyspieszenie tej operacji? Pomyślałem, że może 
> obciąć coś z vendor'a bo to on stanowi główny problem.

Ja się nie znam, bo jestem amator, ale może Composer po stronie serwera?

-- 
pozdrawiam
Roman Tyczka

W dniu 2019-03-24 o 23:08, Roman Tyczka pisze:
> 
> Ja się nie znam, bo jestem amator, ale może Composer po stronie serwera?
> 

Świetnie, ale potem będę miał identyczny problem ze ściągnięciem tych 
plików :-D

Pomijam fakty:
1. Nie każdy serwer daje dostęp terminalowy.
2. Nie mogę instalować Laravela po obu stronach w ten sam sposób bo nie 
potrafię zagwarantować 100% zgodności, szczególnie gdy zmienił się 
sposób instalowania Laravela. Composer obecnie pobiera instalatora 
frameworka. Może ktoś wie jak zapewnić zgodność?

-- 
Pozdrawiam,
Marek

On Fri, 29 Mar 2019 21:24:38 +0100, Marek S wrote:
>> Ja się nie znam, bo jestem amator, ale może Composer po stronie serwera?
>> 
> 
> Świetnie, ale potem będę miał identyczny problem ze ściągnięciem tych 
> plików :-D

Konkretnie co masz na myśli?
 
> Pomijam fakty:
> 1. Nie każdy serwer daje dostęp terminalowy.

Jak taki argument niedawno wysunąłem to mi chłopaki napisali coś w stylu:
to zmień serwer, za grosze można mieć ofertę z dostępem do shella.

> 2. Nie mogę instalować Laravela po obu stronach w ten sam sposób bo nie 
> potrafię zagwarantować 100% zgodności, szczególnie gdy zmienił się 
> sposób instalowania Laravela. Composer obecnie pobiera instalatora 
> frameworka. Może ktoś wie jak zapewnić zgodność?

To może git?

-- 
pozdrawiam
Roman Tyczka

W dniu 2019-03-30 o 09:27, Roman Tyczka pisze:

>> Świetnie, ale potem będę miał identyczny problem ze ściągnięciem tych
>> plików :-D
> 
> Konkretnie co masz na myśli?

Jeśli udałoby mi się zainstalować Laravela na serwerze, to i tak projekt 
rozwijam na komputerze więc muszę mieć pliki u siebie. Aby mieć je u 
siebie - muszę je ściągnąć. Więc nic nie zyskuję.

>   
>> Pomijam fakty:
>> 1. Nie każdy serwer daje dostęp terminalowy.
> 
> Jak taki argument niedawno wysunąłem to mi chłopaki napisali coś w stylu:
> to zmień serwer, za grosze można mieć ofertę z dostępem do shella.

Mam klientowi powiedzieć: zmień serwer i wtedy przyjdź do mnie?

> To może git?

Ale jak miałoby to wyglądać? Instaluję Laravela na serwerze, u siebie 
instaluję GIT'a na pustym katalogu i co dalej?

Dlatego póki co widzę tylko jedno rozwiązanie:
1. Instaluję Laravela na PCcie
2. Pracuję na nim.
3. Inicjuję repozytorium GITowskie na PCcie po to by mój lokalny 
komputer dostarczył mi workflow.
4. FTPem przerzucam na serwer pracę.

Gdybym jakimś cudem umieścił oddzielnie pliki na serwerze i na 
komputerze lokalnym, to rozjechałyby się timestampy plików i PHPStorm 
zasypywałby mnie warningami.

Takie mam przemyślenia. Nie wiem jak z tego wybrnąć.

-- 
Pozdrawiam,
Marek

On 2019-03-30, Marek S <precz@spamowi.com> wrote:

[...]

>> Jak taki argument niedawno wysunąłem to mi chłopaki napisali coś w stylu:
>> to zmień serwer, za grosze można mieć ofertę z dostępem do shella.
>
> Mam klientowi powiedzieć: zmień serwer i wtedy przyjdź do mnie?

Nie musisz. Możesz tracić czas tak jak to robisz teraz.

>> To może git?
>
> Ale jak miałoby to wyglądać? Instaluję Laravela na serwerze, u siebie 
> instaluję GIT'a na pustym katalogu i co dalej?

Po skończonej pracy wypychasz zmiany do gita, a na serwerze je pobierasz.
Ale to też wymaga dostępu terminalowego, albo jakiegoś CI.

> Dlatego póki co widzę tylko jedno rozwiązanie:
> 1. Instaluję Laravela na PCcie
> 2. Pracuję na nim.
> 3. Inicjuję repozytorium GITowskie na PCcie po to by mój lokalny 
> komputer dostarczył mi workflow.
> 4. FTPem przerzucam na serwer pracę.
>
> Gdybym jakimś cudem umieścił oddzielnie pliki na serwerze i na 
> komputerze lokalnym, to rozjechałyby się timestampy plików i PHPStorm 
> zasypywałby mnie warningami.
>
> Takie mam przemyślenia. Nie wiem jak z tego wybrnąć.

Nijak. Uparłeś się na taki model pracy, ma on takie (konkretne) wady
i niewiele z tym zrobisz.

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

Sun, 24 Mar 2019 21:49:47 +0100      
Marek S <precz@spamowi.com>   napisał(a):

> Zrobiłem lokalny projekt i chciałem go umieścić na serwerze. No to daję 
> FTP po całości, wychodzę do knajpy coś zjeść, robię zakupy w Żabce, 
> wracam... postęp 50%. Gdybym miał coś takiego w pracy robić, to książkę 
> do poczytania trzeba by zabrać.

Po całości to za pierwszym razem,
ale potem tylko zmiany, ftp też można, np. lftp --only-newer ...


-- 
pozdrawiam, Peter

On Sat, 30 Mar 2019 16:29:14 +0100, Marek S wrote:

> Jeśli udałoby mi się zainstalować Laravela na serwerze, to i tak projekt 
> rozwijam na komputerze więc muszę mieć pliki u siebie. Aby mieć je u 
> siebie - muszę je ściągnąć. Więc nic nie zyskuję.

Ale przecież Laravela nie tykasz, nie modyfijkujesz, więc na zdalnym i
lokalnym masz Laravela + garść swoich plików na których pracujesz, zatem
synchronizacja dotyczy tylko tych plików.

-- 
pozdrawiam
Roman Tyczka

W dniu 2019-03-31 o 10:38, Wojciech Bancer pisze:

>> Mam klientowi powiedzieć: zmień serwer i wtedy przyjdź do mnie?
> 
> Nie musisz. Możesz tracić czas tak jak to robisz teraz.

Czyli przekładając to na tematykę zapytania - nie ma możliwości 
przesyłania tylko części plików? Wszystkie są potrzebne na serwerze?

> Po skończonej pracy wypychasz zmiany do gita, a na serwerze je pobierasz.
> Ale to też wymaga dostępu terminalowego, albo jakiegoś CI.

O, a to mnie zainteresowało. Czy istnieje wersja GIT w postaci 
skryptowej, którą mogę skopiować na serwer i tam używać? Nie mam za 
bardzo doświadczenia w GIT, do tej pory traktowałem go jako narzędzie 
lokalne. Do takiego deploymentu to Azure DevOps.

> 
> Nijak. Uparłeś się na taki model pracy, ma on takie (konkretne) wady
> i niewiele z tym zrobisz.
> 

To moje uparcie na jakimś modelu wyraziłem gdzieś? Nie kojarzę?

-- 
Pozdrawiam,
Marek

W dniu 2019-03-31 o 13:08, Roman Tyczka pisze:
> 
> Ale przecież Laravela nie tykasz, nie modyfijkujesz, więc na zdalnym i
> lokalnym masz Laravela + garść swoich plików na których pracujesz, zatem
> synchronizacja dotyczy tylko tych plików.
> 

Tak, prawda, ale chodzi o to, że raz na jakiś czas muszę zablokować 
komputer na pół dnia do transferu danych. A to mi nie odpowiada.

-- 
Pozdrawiam,
Marek

> Po całości to za pierwszym razem,
> ale potem tylko zmiany, ftp też można, np. lftp --only-newer ...

Sęk w tym, że te pierwsze razy zdarzają się regularnie. W miesiącu 
uciekają mi ze 2 dni pracy. To sporo.

-- 
Pozdrawiam,
Marek

On 2019-03-31, Marek S <precz@spamowi.com> wrote:

[...]

>>> Mam klientowi powiedzieć: zmień serwer i wtedy przyjdź do mnie?
>> Nie musisz. Możesz tracić czas tak jak to robisz teraz.
> Czyli przekładając to na tematykę zapytania - nie ma możliwości 
> przesyłania tylko części plików? Wszystkie są potrzebne na serwerze?

No z niektórych pewnie można zrezygnować w konkretnych przypadkach (np. "ja nie używam
postgresa, to część plików dot. postgresa będzie mi niepotrzebna), ale to są zbyt zautomatyzowane 
procesy by ktoś to "ręcznie" ogarnął.

>> Po skończonej pracy wypychasz zmiany do gita, a na serwerze je pobierasz.
>> Ale to też wymaga dostępu terminalowego, albo jakiegoś CI.
>
> O, a to mnie zainteresowało. Czy istnieje wersja GIT w postaci 
> skryptowej, którą mogę skopiować na serwer i tam używać? Nie mam za 
> bardzo doświadczenia w GIT, do tej pory traktowałem go jako narzędzie 
> lokalne. Do takiego deploymentu to Azure DevOps.

Przecież Azure DevOps pod spodem ma gita.

>> Nijak. Uparłeś się na taki model pracy, ma on takie (konkretne) wady
>> i niewiele z tym zrobisz.
>
> To moje uparcie na jakimś modelu wyraziłem gdzieś? Nie kojarzę?

O tu:
"Mam klientowi powiedzieć: zmień serwer i wtedy przyjdź do mnie?"

Skoro nie jesteś w stanie być asertywny i upierasz się na wersji
w której klient ma zawsze rację (mimo że się na tym nie zna),
to cierp. :)

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

W dniu 2019-03-31 o 17:14, Wojciech Bancer pisze:
> 
> No z niektórych pewnie można zrezygnować w konkretnych przypadkach (np. "ja nie używam
> postgresa, to część plików dot. postgresa będzie mi niepotrzebna), ale to są zbyt zautomatyzowane
> procesy by ktoś to "ręcznie" ogarnął.

Hehe ... z tym Postgresem, to ja prawie wyłącznie z niego korzystam :-)
Ale do rzeczy. Liczyłem na to, że jakiś większy zbiór danych będzie 
niepotrzebny. Ale skoro tak nie jest, trudno. Nie będę więc szedł tą drogą.

>> O, a to mnie zainteresowało. Czy istnieje wersja GIT w postaci
>> skryptowej, którą mogę skopiować na serwer i tam używać? Nie mam za
>> bardzo doświadczenia w GIT, do tej pory traktowałem go jako narzędzie
>> lokalne. Do takiego deploymentu to Azure DevOps.
> 
> Przecież Azure DevOps pod spodem ma gita.

No wiem. Ale nie o Azure chcę dyskutować, bo licencję mam nie na siebie. 
W swoich projektach muszę radzić sobie inaczej.

Chciałbym wykorzystać GIT'a w ten sposób, w jaki powiedziałeś, że można. 
Czyli na serwerze zrobić pull z mastera. Chyba tylko to mi wystarczyłoby.

> 
>>> Nijak. Uparłeś się na taki model pracy, ma on takie (konkretne) wady
>>> i niewiele z tym zrobisz.
>>
>> To moje uparcie na jakimś modelu wyraziłem gdzieś? Nie kojarzę?
> 
> O tu:
> "Mam klientowi powiedzieć: zmień serwer i wtedy przyjdź do mnie?"

To klient przecież się uparł w Twojej nomenklaturze (w mojej: nie miał 
pojęcia co wybiera bo się nie znał gdy zamawiał usługę). Ja nie miałem z 
tym nic wspólnego.

> Skoro nie jesteś w stanie być asertywny i upierasz się na wersji
> w której klient ma zawsze rację (mimo że się na tym nie zna),
> to cierp. :)

Asertywność ma słabe zastosowanie w tym przypadku.

-- 
Pozdrawiam,
Marek

On 2019-03-31, Marek S <precz@spamowi.com> wrote:

[...]

>> No z niektórych pewnie można zrezygnować w konkretnych przypadkach (np. "ja nie używam
>> postgresa, to część plików dot. postgresa będzie mi niepotrzebna), ale to są zbyt zautomatyzowane
>> procesy by ktoś to "ręcznie" ogarnął.
>
> Hehe ... z tym Postgresem, to ja prawie wyłącznie z niego korzystam :-)
> Ale do rzeczy. Liczyłem na to, że jakiś większy zbiór danych będzie 
> niepotrzebny. Ale skoro tak nie jest, trudno. Nie będę więc szedł tą drogą.

To jest przykład. Chodzi o to, że w dobie autoloaderów i rozbijania kodu
na małe kawałki śledzenie które fragmenty kodu są naprawde wykorzystywane
jest bardzo trudne dla człowieka.

O ile w node.js było to na tyle istotne, że powstały packery które to po części
potrafią (np. rollup, czy webpack) o tyle nie kojarzę takich narzędzi dla PHP.
A i sens jest ograniczony, bo (w przeciwieństwie do javascriptu) serwer nie musi
"pchać" wszystkiego do klienta.

>>> lokalne. Do takiego deploymentu to Azure DevOps.
>> 
>> Przecież Azure DevOps pod spodem ma gita.
>
> No wiem. Ale nie o Azure chcę dyskutować, bo licencję mam nie na siebie. 
> W swoich projektach muszę radzić sobie inaczej.

Azure DevOps jest chyba darmowy do 5 userów, czy coś?
Zawsze sobie możesz swój założyć.

> Chciałbym wykorzystać GIT'a w ten sposób, w jaki powiedziałeś, że można. 
> Czyli na serwerze zrobić pull z mastera. Chyba tylko to mi wystarczyłoby.

Tak, no ale tak czy siak potrzebujesz do tego CI (np. jenkins) albo dostęp
terminalowy. Przez SSH tego nie zrobisz.

>>>> Nijak. Uparłeś się na taki model pracy, ma on takie (konkretne) wady
>>>> i niewiele z tym zrobisz.
>>>
>>> To moje uparcie na jakimś modelu wyraziłem gdzieś? Nie kojarzę?
>> 
>> O tu:
>> "Mam klientowi powiedzieć: zmień serwer i wtedy przyjdź do mnie?"
>
> To klient przecież się uparł w Twojej nomenklaturze (w mojej: nie miał 
> pojęcia co wybiera bo się nie znał gdy zamawiał usługę). Ja nie miałem z 
> tym nic wspólnego.

To się grzecznie mówi jakie są wymagania (dostęp terminalowy) i już.
Przecież laravel ma zestaw komend cli, które czasem są potrzebne do wykonania
(chociażby do migracji).

A jeśli bezpośredni dostęp nie jest opcją, to chociażby jakieś CI z ustawionymi
taskami dla różnych operacji (zrobienie paczki archiwum z kodem,
deployment zmian przez git, migracje bazy, backup/restore itp).

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

Dnia Sat, 30 Mar 2019 16:29:14 +0100, Marek S napisał(a):

> Takie mam przemyślenia. Nie wiem jak z tego wybrnąć.

Od tego masz plik `composer.lock`, by się nie martwić wersjami plików w
katalogu `vendor`, tylko odpalić `composer install` i poczekać chwilę.

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

On Mon, 1 Apr 2019 10:28:49 +0200, Wojciech Bancer wrote:

>> Chciałbym wykorzystać GIT'a w ten sposób, w jaki powiedziałeś, że można. 
>> Czyli na serwerze zrobić pull z mastera. Chyba tylko to mi wystarczyłoby.
> 
> Tak, no ale tak czy siak potrzebujesz do tego CI (np. jenkins) albo dostęp
> terminalowy. Przez SSH tego nie zrobisz.

A tu mnie zaintrygowałeś. Czy SSH to nie jest właśnie dostęp do terminala? 


-- 
pozdrawiam
Roman Tyczka

On Sun, 31 Mar 2019 17:03:48 +0200, Marek S wrote:

>> Ale przecież Laravela nie tykasz, nie modyfijkujesz, więc na zdalnym i
>> lokalnym masz Laravela + garść swoich plików na których pracujesz, zatem
>> synchronizacja dotyczy tylko tych plików.
> 
> Tak, prawda, ale chodzi o to, że raz na jakiś czas muszę zablokować 
> komputer na pół dnia do transferu danych. A to mi nie odpowiada.

Gdybyś miał dostęp do shella to byś te pół dnia zaoszczędził. Może warto
klienta przenieść na inny serwer? Skoro nie kuma o co chodzi to jak mu
powiesz, że trzeba bo xyjuyftbuygfv oraz ytfvutfuytfvu, a także z powodu
iuygbiuygivgiuyv to się zgodzi bez mrugnięcia :-)

-- 
pozdrawiam
Roman Tyczka

On 2019-04-02, Roman Tyczka <noemail@because.no> wrote:
> On Mon, 1 Apr 2019 10:28:49 +0200, Wojciech Bancer wrote:
>
>>> Chciałbym wykorzystać GIT'a w ten sposób, w jaki powiedziałeś, że można. 
>>> Czyli na serwerze zrobić pull z mastera. Chyba tylko to mi wystarczyłoby.
>> 
>> Tak, no ale tak czy siak potrzebujesz do tego CI (np. jenkins) albo dostęp
>> terminalowy. Przez SSH tego nie zrobisz.
>
> A tu mnie zaintrygowałeś. Czy SSH to nie jest właśnie dostęp do terminala? 

Sorry, miałem tu na myśli FTP, nie wiem czemu napisałem SSH. :)

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

W dniu 2019-04-01 o 10:28, Wojciech Bancer pisze:

> Tak, no ale tak czy siak potrzebujesz do tego CI (np. jenkins) albo dostęp
> terminalowy. Przez SSH tego nie zrobisz.

Tak, jak napisałem: zazwyczaj mam taki dostęp terminalowy, choć nie 
zawsze. Załóżmy, że teraz skupiamy się na przypadku kiedy będę go miał. 
Nie bardzo zajarzyłem, o co chodzi z tym SSH, bo nigdy inaczej nie 
dostawałem się do command line.

Co dalej? Jak posadzić pull gitowski mając dostęp tylko do konta WWW (PHP)?

-- 
Pozdrawiam,
Marek

W dniu 2019-04-02 o 08:47, Roman Tyczka pisze:

> Gdybyś miał dostęp do shella to byś te pół dnia zaoszczędził. Może warto
> klienta przenieść na inny serwer? Skoro nie kuma o co chodzi to jak mu
> powiesz, że trzeba bo xyjuyftbuygfv oraz ytfvutfuytfvu, a także z powodu
> iuygbiuygivgiuyv to się zgodzi bez mrugnięcia :-)

Generalnie mniej więcej tak postępuję, ale czasem jest beznadziejnie 
ciężko. Np. zdarzyło się w jakiejś korporacji, że muszą mieć stronę w X 
bo niemiecki właściciel tak nakazał i basta. Zmiana DNSów w domenie 
zajęła mi 3 miesiące! :-D

-- 
Pozdrawiam,
Marek

W dniu 2019-04-01 o 21:55, Borys Pogoreło pisze:
> Dnia Sat, 30 Mar 2019 16:29:14 +0100, Marek S napisał(a):
> 
>> Takie mam przemyślenia. Nie wiem jak z tego wybrnąć.
> 
> Od tego masz plik `composer.lock`, by się nie martwić wersjami plików w
> katalogu `vendor`, tylko odpalić `composer install` i poczekać chwilę.

Oki, zainteresuję się composerem. Tak przy okazji: chciałbym zacząć 
używać go również czynnie: do własnych realizacji. Czy możesz podsunąć 
sprawny tutorial dotyczący samego composera oraz workflow w zakresie 
konfigurowania go do własnych przedsięwzięć (budowanie zależności itp)?

-- 
Pozdrawiam,
Marek

Dnia Tue, 2 Apr 2019 21:36:08 +0200, Marek S napisał(a):

> Oki, zainteresuję się composerem. Tak przy okazji: chciałbym zacząć 
> używać go również czynnie: do własnych realizacji. Czy możesz podsunąć 
> sprawny tutorial dotyczący samego composera oraz workflow w zakresie 
> konfigurowania go do własnych przedsięwzięć (budowanie zależności itp)?

Najlepiej przebrnąć przez ich dokumentację. Nauka Composera to niestety
pamięciówka, sam sposób numeracji wersji to materiał na osobny artykuł.

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

On 2019-04-02, Marek S <precz@spamowi.com> wrote:

[...]

> Tak, jak napisałem: zazwyczaj mam taki dostęp terminalowy, choć nie 
> zawsze. Załóżmy, że teraz skupiamy się na przypadku kiedy będę go miał. 
> Nie bardzo zajarzyłem, o co chodzi z tym SSH, bo nigdy inaczej nie 
> dostawałem się do command line.
>
> Co dalej? Jak posadzić pull gitowski mając dostęp tylko do konta WWW (PHP)?

Jeśli masz dostępnego gita, to po prostu pobierasz. Możesz w tym celu np.
wygenerować sobie klucz read-only (read access key), a dalej to już zależnie
od tego co potrzebujesz w projekcie. Jeśli na docelowym serwerze nie ma gita, 
można zawsze poprosić o jego instalację.

Jeśli admin odmówi, to pozostaje np. rsync, a jak i to nie działa, to można
rozważyć budowanie paczek z aplikacją np. tar i gz (to już chyba jest 
wszędzie).

Najwygodniej byłoby używać czegoś takiego:
https://deployer.org/

Narzędzie loguje się na zdalny serwer, przy pomocy gita ściąga aktualną wersję kodu
tworzy do niej katalog z nową wersją i wykonuje zdefiniowane kroki.

Tu masz przykład z laravelem:
https://deployer.org/docs/how-to-deploy-laravel.html
Narzędzie wymusza pewną strukturę katalogów, ale w zamian daje możliwość
"rollbacku" do poprzedniej wersji gdyby coś poszło nie tak.

A całość procesu deploymentu zajmuje poniżej minuty.

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

W dniu 2019-04-03 o 10:59, Wojciech Bancer pisze:
> 
> A całość procesu deploymentu zajmuje poniżej minuty.

Dzięki! O coś takiego mi chodzi. Potrzebuję trochę czasu na zapoznanie 
się z narzędziem.

-- 
Pozdrawiam,
Marek