IDE met goede (S)FTP Interface

[amphora]

Ik gebruik nu al jaren Coda 2 voor m'n PHP/CSS/JS/Laravel dev werk. Op m'n Macbook Pro / OSX dus. Ik kan er prima mee uit de voeten maar het is ook zeker niet bugvrij. Crashed af en toe, Publishen wat ineens niet meer werkt totdat ik opnieuw opstart etc.

Dus ben ik aan het rondkijken naar een nieuwe IDE. Kom je natuurlijk al snel uit op PHP Storm en Sublime Text en met name Sublime bevalt me goed qua snelheid maar in beide mist één belangrijk onderdeel. Een goede (S)FTP interface. Voor sublime is er wel een SFTP plugin maar je kan daar niet fijn mee bladeren op de remote server. En op mijn ontwikkel server ga ik alles nou eenmaal SFTP-en.

Het fijne van Coda is dat ik direct op een remote server een bestand kan openen en opslaan. De publishing functie (als die goed werkt) is top, sla lokaal op en upload gelijk naar remote (kan met die sublime text plugin ook maar mist gewoon een hoop functies)

Een extern FTP programma naast Sublime/PHPStorm vind ik ook geen optie. Moet ik voor iedere upload extra handelingen doen.

Een netwerk share zou misschien ook nog kunnen, dan sla je wel alles direct remote op maar dan mis ik m'n lokale versie (als backup).
Voor de live omgeving is het overigens geen issue. Daar FTP-ed niemand naartoe want alles gaat via git commits.

Iemand een suggestie voor een IDE of andere Workflow die ik over het hoofd heb gezien? Hoe doen jullie dat?

[Verwijderd]

Wat bedoel je precies met 'een goede SFTP interface'?

Ik gebruik PHPStorm, en daarnaast incidenteel WS_FTP als ik naar tijden en bestandsgroottes wil kijken, maar voor alledaags uploaden/synchroniseren werkt de interne interface prima.

[amphora]

Verwijderd schreef op vrijdag 29 september 2017 @ 12:00:
Wat bedoel je precies met 'een goede SFTP interface'?

Ik gebruik PHPStorm, en daarnaast incidenteel WS_FTP als ik naar tijden en bestandsgroottes wil kijken, maar voor alledaags uploaden/synchroniseren werkt de interne interface prima.

Er op dezelfde manier doorheen kunnen bladeren als lokaal zoals de Finder werkt. Snel ook een bestand kunnen wissen, hernoemen etc. Coda heeft een volledig geïntegreerde FTP client en eigenlijk de enige reden waarom ik (vooralsnog) Coda blijf gebruiken.

[Gomez12]

En als je het nu eens zo opzet dat je alles lokaal opslaat en edit en op de achtergrond een continue rsync hebt draaien met je ontwikkelomgeving?

Dan moet je het rsync proces aanknallen voordat je gaat werken en afsluiten als je klaar bent. En het kan qua verwachting nog wel eens fout gaan als je grotere bestanden gaat verwerken, maar zolang het bij kleine bestanden etc blijft dan is rsync waarschijnlijk sneller dan dat jij switched naar je browser.

[DJMaze]

Zelf doe ik alles lokaal en vervolgens via Git/Mercurial een commit en push.

amphora schreef op vrijdag 29 september 2017 @ 12:13:
Er op dezelfde manier doorheen kunnen bladeren als lokaal zoals de Finder werkt.

Het toverwoord is FUSE en daarna SSHFS.
Zoek maar eens op Google.

[ Voor 36% gewijzigd door DJMaze op 29-09-2017 13:20 ]

[amphora]

DJMaze schreef op vrijdag 29 september 2017 @ 13:17:
Zelf doe ik alles lokaal en vervolgens via Git/Mercurial een commit en push.

[...]

Het toverwoord is FUSE en daarna SSHFS.
Zoek maar eens op Google.

Die optie noemde ik al (Een netwerk share) maar dan heb ik geen lokale backup. Overigens beheer ik heel veel sites (ook kleine sites van de bakker op de hoek zeg maar) waar ik vaak alleen maar FTP toegang tot heb en geen SSH. Dus is helaas geen perfecte oplossing maar voor grote projecten zou het kunnen werken. Maar dan nog blijf ik afhankelijk van Coda voor die kleine projectjes en daar wil ik eigenlijk vanaf. Of hoop op een grote Coda 3 update binnenkort maar heb daar weinig vertrouwen in.

En commit/push naar live doe ik ook voor veel projecten maar voor de ontwikkel omgeving is dat te traag. Ik wil opslaan, Alt-tab naar browser, refreshen en direct het resultaat zien.

[ Voor 10% gewijzigd door amphora op 29-09-2017 16:15 ]

[Stoelpoot]

Hele andere oplossing: Git Commit hooks die direct een commit op master naar de FTP server overzetten? Lokale backup, geïntegreerd met version control en geen directe FTP verbindingen (in de regel wordt direct FTP als iets slechts gezien, hoewel t in jouw geval inderdaad logisch is).

Anders misschien kijken naar Visual Studio Code met een FTP plugin? VSCode heeft veel plugins.

[amphora]

Stoelpoot schreef op vrijdag 29 september 2017 @ 16:20:
Hele andere oplossing: Git Commit hooks die direct een commit op master naar de FTP server overzetten? Lokale backup, geïntegreerd met version control en geen directe FTP verbindingen (in de regel wordt direct FTP als iets slechts gezien, hoewel t in jouw geval inderdaad logisch is).

Anders misschien kijken naar Visual Studio Code met een FTP plugin? VSCode heeft veel plugins.

Maar op de dev omgeving wil ik niet met commits werken. Wil binnen een seconde het resultaat van een css wijziging kunnen zien, en tweaken tot ik het juiste resultaat heb en dan pas committen. Heb ooit git-ftp gevonden, handig om te pushen naar live server maar niet voor dev.

FTP plugin voor visualcode is vergelijkbaar met die van sublime, het werkt maar mis een nette interface zoals een 'echt' ftp programma.

[ Voor 8% gewijzigd door amphora op 29-09-2017 16:39 ]

[DJMaze]

amphora schreef op vrijdag 29 september 2017 @ 16:14:
En commit/push naar live doe ik ook voor veel projecten maar voor de ontwikkel omgeving is dat te traag. Ik wil opslaan, Alt-tab naar browser, refreshen en direct het resultaat zien.

Dus je ontwikkel omgeving is niet je eigen computer?
Dan zou ik als ik jou was daar eerst maar eens wat aan doen.

amphora schreef op vrijdag 29 september 2017 @ 16:14:
Die optie noemde ik al (Een netwerk share) maar dan heb ik geen lokale backup.

SSHFS is niet echt een netwerk share noch is FTPFS dat. Een netwerk share is eigenlijk in de volksmond Samba, CIFS, NFS, etc.
Het auto-mounten van SSHFS en FTPFS maakt het leven een heel stuk makkelijker.

amphora schreef op vrijdag 29 september 2017 @ 16:14:
Overigens beheer ik heel veel sites (ook kleine sites van de bakker op de hoek zeg maar) waar ik vaak alleen maar FTP toegang tot heb en geen SSH.

Logisch en niks mis mee hoor. FTPFS werkt uitstekend daarvoor.

Ik werk zelf op GNU/Linux en daar kan ik in mijn "Finder" gewoon een protocol typen en hoppa, ik vanuit mijn "Finder" bestanden openen en opslaan.

[ Voor 6% gewijzigd door DJMaze op 29-09-2017 18:43 ]

[Ramon]

Oplossing voor dit probleem is om je workflow aan te passen. Als je een lokale ontwikkelomgeving inricht kan je saven en op de dev-website meteen je aanpassingen zien. Zijn die goed, dan commit je en deploy je. Dat deployen kan op tig verschillende manieren maar direct op een FTP-omgeving roeren is nooit goed. Je wil iets wat automatisch een één-op-één weergave van wat er in git staat op de server neerzet zodat je geen fouten kan maken.

[Edwin88]

amphora schreef op vrijdag 29 september 2017 @ 16:38:
[...]

Maar op de dev omgeving wil ik niet met commits werken. Wil binnen een seconde het resultaat van een css wijziging kunnen zien, en tweaken tot ik het juiste resultaat heb en dan pas committen. Heb ooit git-ftp gevonden, handig om te pushen naar live server maar niet voor dev.

FTP plugin voor visualcode is vergelijkbaar met die van sublime, het werkt maar mis een nette interface zoals een 'echt' ftp programma.

Voor CSS tweaken kan je in veel gevallen zelfs beter direct via de devtools tweaken, en uiteindelijk de resulataten naar je code halen. Hier zijn zelfs allerlei plugins voor.

[Bosmonster]

Ik gebruik nu zelf VSCode met de sftp plugin. Die is erg stabiel en retesnel.

Voornaamste reden dat ik hem voor sommige projecten nu prefereer boven PHPStorm, want daarin is de SFTP implementatie echt kansloos traag (naast wat andere irritaties, grotendeels performance gerelateerd).

Overigens de reden dat ik dit voor sommige projecten gebruik (gezien de haat in dit topic) is dat we een aantal projecten nog met Vagrant draaien en er dus gesynced moet worden naar de VM.

FTP plugin voor visualcode is vergelijkbaar met die van sublime, het werkt maar mis een nette interface zoals een 'echt' ftp programma.

Met een goede sftp/sync implementatie heb je die hele interface dus niet nodig. Al kun je altijd nog een bestand/folder handmatig uploaden als het echt nodig is. PHP/WebStorm heeft wel een remote view overigens, als je de traagheid geen probleem vindt.

Je stelt de juiste folders in en de rest gebeurt allemaal automatisch en hoef je niet meer bij na te denken.

[ Voor 71% gewijzigd door Bosmonster op 29-09-2017 23:46 ]

[Jorick]

Ben het met Ramon eens, zou toch eens kijken of je je workflow niet aan kunt of moet veranderen want handmatig je projecten heen-en-weer schuiven is repetitief werk en foutgevoelig. Ik werk zelf met PhpStorm maar gebruik de geïntegreerde FTP functionaliteit nooit omdat, zoals anderen al aanhalen, nogal traag is. Voor het syncen/deployen van projecten (merendeel in Drupal & Symfony) gebruik ik git en/of rsync via drush en gaat het deployen praktisch volledig geautomatiseerd.

Voor de kleinere projecten, zoals die van de bakker om de hoek, zou ik toch adviseren om ook dat soort projecten te verhuizen naar een hostingpartij met minimaal SSH ondersteuning omdat dit veel mogelijkheden geeft in het automatiseren van je deploys. Voor de kosten hoef je het niet te laten want voor €1,95 heb je al een hostingpakket inclusief SSH, SSL certificaat en meer dan genoeg opslagruimte en dataverkeer voor kleine en middelgrote sites. Kost eenmalig wat moeite maar maakt het beheer in de toekomst aanzienlijk makkelijker en bespaart tijd omdat je dan voor al je sites een bepaalde baseline hebt (SSH toegang, git, rsync, composer) waar je je workflow op in kan richten.

[amphora]

Het gaat niet om live pushen, dan doe ik inderdaad via git (voor de belangrijke projecten dan) maar om m'n dev server die ook online moet staan zodat klanten kunnen testen en ik niet m'n laptop aan hoef te laten staan. Een dev branch met git zou dat wellicht ook op kunnen lossen. Maar dan nog zijn er die tig kleine sites waar ik alleen met FTP bij kan. Die allemaal verhuizen is geen optie. Er is vrees ik geen ideale all in one oplossing. Coda voor die sites blijven gebruiken wellicht en sublime+git voor de 'serieuze' projecten dan en dan toch maar een FTP client er naast voor noodgevallen. PHP Storm heb ik ook geprobeerd en de traagheid inderdaad deed me afhaken.

[Gropah]

Je zou ook lokaal kunnen ontwikkelen, je staging branch op de devserver (dus ook voor klanten zichtbaar) zetten en production weer ergens anders draaien. Dan kun je lokaal gewoon werken met git, wanneer dat goed genoeg is automatisch/elke nacht laten deployen naar je testing server.

Een beetje zoals https://github.com/rotati...d-stable-branch-in-Github

[johnkeates]

Ik gebruik eigenlijk al jaren geen (S)FTP meer. Ontwikkelen doe je niet 'remote', en alles wat wel remote is wordt door CI/CD en Git automatisch geregeld.

Wat lokaal goed werkt is Vagrant gebruiken. Je set een Vagrantfile op die je lokale projectmap in de VM mount, en dan zijn je wijzigingen direct in de VM live. Geen (S)FTP nodig, en toch op een "server" aan het werk die dus reverse mount.

Dit werkt overigens ook met remote servers, die kan je ook jouw lokale map laten mounten, desnoods via een SSH tunnel of ngrok proxy.

Stel dat je iets 'live' hebt voor derden, dan lijkt het me onhandig om daar rechtstreeks op te gaan zitten werken. Dan zou je nog steeds beter af zijn met een push van je lokale omgeving naar de remote omgeving. Git kan je ook gebruiken tussen twee peers he, hoeft niet altijd met een of andere 'server' te gaan, het is niet voor niet een DVCS. Een groot voordeel is dat jij na een wijziging die een klant wil zien direct door kan werken tot je terugkoppeling van de klant hebt gehad. Om dat die dan naar een specifieke commit kijkt weet je zeker dat er geen changes achteraan gegaan zijn die de klant dan onbedoeld ziet.

[ Voor 36% gewijzigd door johnkeates op 30-09-2017 02:33 ]

[Edwin88]

Je zou ook met een tool als gulp (ook al is het wat verouderd) een FTP build kunnen maken die voor jou de build automatisch naar de ftp server upload. Zo heb je in ieder geval geen handmatige FPT meer nodig en is deployen naar een dev omgeving een simpele `npm run deploy-dev`.

[DJMaze]

amphora schreef op zaterdag 30 september 2017 @ 01:59:
maar om m'n dev server die ook online moet staan zodat klanten kunnen testen en ik niet m'n laptop aan hoef te laten staan

Je mist de T en A in je OTAP. Nou is OTAP best overdreven voor je kleine projecten en als je alleen werkt, haal dan gewoon de T weg.

[Morax]

Ik snap het probleem met PHPStorm niet helemaal? Die heeft een geïntegreerde SFTP client die wat mij betreft erg goed is. Als ik CTRL+S druk, switch naar mijn browser en f5 druk dan staat mijn wijziging direct. Wijzigingen zijn nagenoeg instant. Hij houdt de verbinding ook open na je eerste save.

Plus hij kan ook externe wijzigingen uploaden (als je bijvoorbeeld van branch switcht). Ja, dan moet je wel even wachten tot hij weer bijgetrokken is, maar dat is maar van korte duur.

[Gomez12]

johnkeates schreef op zaterdag 30 september 2017 @ 02:30:
Ik gebruik eigenlijk al jaren geen (S)FTP meer. Ontwikkelen doe je niet 'remote', en alles wat wel remote is wordt door CI/CD en Git automatisch geregeld.

Wat lokaal goed werkt is Vagrant gebruiken. Je set een Vagrantfile op die je lokale projectmap in de VM mount, en dan zijn je wijzigingen direct in de VM live. Geen (S)FTP nodig, en toch op een "server" aan het werk die dus reverse mount.

Dit is leuk voor kleine toepassingen/aanpassingen etc. Maar wordt het groter dan moet je al snel of een bakbeest van een dev-machine neerzetten of je moet met zulke gelimiteerde data gaan werken dat het niet representatief meer is.

Ik ga er in ieder geval vanuit dat als ik live 4 servers heb staan voor performance (dus niet voor redundantie en backup) dat ik dan om een beetje te kunnen ontwikkelen ik 4 soortgelijke servers nodig heb voor dev. Op 1 machine met vagrant kan ik het nooit reproduceren dat er 2 servers vol server 1 staan te bevragen

[johnkeates]

Gomez12 schreef op maandag 2 oktober 2017 @ 11:17:
[...]

Dit is leuk voor kleine toepassingen/aanpassingen etc. Maar wordt het groter dan moet je al snel of een bakbeest van een dev-machine neerzetten of je moet met zulke gelimiteerde data gaan werken dat het niet representatief meer is.

Ik ga er in ieder geval vanuit dat als ik live 4 servers heb staan voor performance (dus niet voor redundantie en backup) dat ik dan om een beetje te kunnen ontwikkelen ik 4 soortgelijke servers nodig heb voor dev. Op 1 machine met vagrant kan ik het nooit reproduceren dat er 2 servers vol server 1 staan te bevragen

Dus jij mag van je CISO met PII data werken?

[BernardV]

Live werken lijkt mij ook niet de oplossing. Als je snel wilt testen kun je ook een VM pakken, bijvoorbeeld virtualbox.

Ik werk zelf zo:

In de DNS van "mijndomein.nl" heb ik een wildcard record aangemaakt op *.local.mijndomein.nl deze wijst naar 10.0.1.10.
In virtualbox heb ik een host-only netwerk aangemaakt met dit IP voor de VM.

Dan heb ik lokaal een folder met alle sites, de namen van deze folder zijn bijvoorbeeld tweakers.local.mijndomein.nl en dit wordt opgepakt door apache als vhost door alleen de folder aan te maken lokaal.

De lokale folder is weer met een share in virtualbox gekoppeld.

Apache config is dan zoiets:

code:

<Virtualhost *:80>
    ServerName development.local.mijndomein.nl
    ServerAlias *
    UseCanonicalName Off
    VirtualDocumentRoot "/media/sf_sites/%0/website/public"

    LogFormat "%V %h %l %u %t %r %s %b" vcommon
    ErrorLog "/var/log/apache2/vhosts-error_log"

        <Directory "/media/sf_sites/*">
            Options Indexes FollowSymLinks MultiViews
            AllowOverride All
        Require all granted
        </Directory>
</Virtualhost>

Enige is dat de module vhost_alias geladen moet worden in apache.

Zo kun je lokaal snel en makkelijk testen en zodra iets naar wens is committen of uploaden.

[Gomez12]

johnkeates schreef op maandag 2 oktober 2017 @ 11:19:
[...]


Dus jij mag van je CISO met PII data werken?

Ehm nee, hoe kom je daarbij? Data valt gewoon te anonymiseren hoor.

[amphora]

Voor lokale ontwikkeling heb ik al een mooie oplossing, Laravel Valet (Alleen OSX). wildcard *.dev domeinen. http://sitea.dev verwijst dan standaard naar ~/Documents/websites/sitea bijvoorbeeld. Ben het er mee eens dat lokale dev het beste is maar zoals ik al zei heb ik weinig zin om voor al die kleine sites die ik ooit gebouwd heb en nog moet onderhouden een lokale dev in te richten.
Nog even over PHP Storm: Ik vind het geen fijne applicatie. Voelt al een bloated java app. Sublime en Coda voelen veel sneller aan. Zelfs Dreamweaver vond ik fijner. Ook al heeft PHP Storm veel functies die andere apps niet hebben voelt het niet lekker en die functies mis ik blijkbaar ook niet.
[nietserieusnemen]VisualCode heb ik ook geprobeerd. Maar om iets van Microsoft op m'n Macbook te zetten voelt dan weer niet goed ;-)[/nietserieusnemen]

[BernardV]

Ik gebruik zelf ook PHPStorm en dat bevalt me goed.

Je kunt ook een remote project aanmaken en dan wordt alles gesynct wanneer nodig:

https://www.jetbrains.com...ct-add-remote-server.html

[Sikro]

Heb jaren lang met NetBeans gewerkt tijdens mijn informatica studie. Echter is het een log programma, maar wel met veel plugins en een duidelijke interface.

Sinds een aantal maanden ben ik echter enorm verslaafd aan het programmeren in Coda 2: https://panic.com/coda/ .
FTP integratie, versiebeheer en een clean look. Zeer handig voor het maken van websites, en het ondersteunt lokaal werken, mits je geen crashes hebt natuurlijk .

[ Voor 4% gewijzigd door Sikro op 02-10-2017 14:40 ]

[amphora]

Sikro schreef op maandag 2 oktober 2017 @ 12:00:
Heb jaren lang met NetBeans gewerkt tijdens mijn informatica studie. Echter is het een log programma, maar wel met veel plugins en een duidelijke interface.

Sinds een aantal maanden ben ik echter enorm verslaafd aan het programmeren in Coda 2: https://panic.com/coda/ .
FTP integratie, versiebeheer en een clean look. Zeer handig voor het maken van websites, en het ondersteunt lokaal werken.

Werk dus ook al jaren met Coda maar laatste tijd veel problemen mee, publishing wat ineens niet meer werkt totdat ik de app opnieuw start. Opstarten wat some enkele minuten duurt. Maar die geïntegreerde FTP is de reden waarom ik het nog steeds gebruik maar toch op zoek ben naar een goed alternatief, vandaar dit topic ;-)
Heb afgelopen weekend een clean High Sierra install gedaan. Hopelijk helpt dit.

[ Voor 4% gewijzigd door amphora op 02-10-2017 12:04 ]

[MrMarcie]

Edwin88 schreef op zaterdag 30 september 2017 @ 09:50:
Je zou ook met een tool als gulp (ook al is het wat verouderd) een FTP build kunnen maken die voor jou de build automatisch naar de ftp server upload. Zo heb je in ieder geval geen handmatige FPT meer nodig en is deployen naar een dev omgeving een simpele `npm run deploy-dev`.

Hoezo is dat verouderd? Volgens mij wordt het steeds meer gebruikt. Ben er zelf wel enthousiast over.

[418O2]

MrMarcie schreef op maandag 15 januari 2018 @ 21:42:
[...]


Hoezo is dat verouderd? Volgens mij wordt het steeds meer gebruikt. Ben er zelf wel enthousiast over.

Men gebruikt vaak npm scripts, al dan niet met webpack

My 2 cents: dingen als FTP en version control moet je met apps doen die daar goed in zijn. Een ide moet je daar niet voor gebruiken

[MrMarcie]

418O2 schreef op maandag 15 januari 2018 @ 21:53:
[...]

Men gebruikt vaak npm scripts, al dan niet met webpack

My 2 cents: dingen als FTP en version control moet je met apps doen die daar goed in zijn. Een ide moet je daar niet voor gebruiken

Ah, zo bedoel je dat. Duidelijk. Ik combineer e.e.a.. FTP doe ik met VCS.

[418O2]

MrMarcie schreef op maandag 15 januari 2018 @ 21:58:
[...]


Ah, zo bedoel je dat. Duidelijk. Ik combineer e.e.a.. FTP doe ik met VCS.

Als je daar tevreden over bent, moet je dat vooral doen. Maar ik merk dat die extra features vaak niet optimaal werken.

Ik switch overigens steeds meer naar de cli. Dus gebruik de terminal van bijvoorbeeld vs code wel vaak

[Ramon]

418O2 schreef op maandag 15 januari 2018 @ 21:53:
[...]

Men gebruikt vaak npm scripts, al dan niet met webpack

My 2 cents: dingen als FTP en version control moet je met apps doen die daar goed in zijn. Een ide moet je daar niet voor gebruiken

Webpack is wel het meest kutte wat de webdev wereld de laatste jaren heeft voortgebracht. Tien keer liever gulp, of idd npm scripts.

[418O2]

Ramon schreef op maandag 15 januari 2018 @ 22:26:
[...]

Webpack is wel het meest kutte wat de webdev wereld de laatste jaren heeft voortgebracht. Tien keer liever gulp, of idd npm scripts.

Dat mag je vinden toch is het tegenwoordig het meest gebruikte.

[Hydra]

Bouw gewoon een fatsoenlijke CI/CD pipeline voor je productie deploys. Het is 2018. Is geen enkele reden om dat met de hand te doen.

Een gangbare werkwijze is om op feature branches te werken en als deze naar een dev branch gemerged worden automatisch deze dev versie op een testomgeving te zetten. Als je dev dan naar master merged wordt deze release, eventueel met een handmatige 'okay' stap, doorgezet naar productie. Met de hand vanuit je IDE spul naar productie uploaden doen alleen prutsers.