This application looks fine to me.
Clearly labeled sections.
Local on one side, remote on the other
Transfer window on bottom.
No space for anything besides function, is the joke going over my head?
this post was submitted on 22 Jun 2024
729 points (98.7% liked)
Programmer Humor
19453 readers
69 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
I'm sure there's nothing wrong with the program at all =)
Modern webapp deployment approach is typically to have an automated continuous build and deployment pipeline triggered from source control, which deploys into a staging environment for testing, and then promotes the same precise tested artifacts to production. Probably all in the cloud too.
Compared to that, manually FTPing the files up to the server seems ridiculously antiquated, to the extent that newbies in the biz can't even believe we ever did it that way. But it's genuinely what we were all doing not so long ago.
manually FTPing the files up to the server seems ridiculously antiquated
But ... but I do that, and I'm only 18 :(
Old soul :)
That's probably okay! =) There's some level of pragmatism, depending on the sort of project you're working on.
If it's a big app with lots of users, you should use automation because it helps reliability.
If there are lots of developers, you should use automation because it helps keep everyone organised and avoids human mistakes.
But if it's a small thing with a few devs, or especially a personal project, it might be easier to do without :)
It's perfectly fine for some private page etc. but when you make business software for customers that require 99,9% uptime with severe contractual penalties it's probably too wonky.
load more comments
(8 replies)
Promotes/deploys are just different ways of saying file transfer, which is what we see here.
Nothing was stopping people from doing cicd in the old days.
Sure, but having a hands-off pipeline for it which runs automatically is where the value is at.
Means that there's predictability and control in what is being done, and once the pipeline is built it's as easy as a single button press to release.
How many times when doing it manually have you been like "Oh shit, I just FTPd the WRONG STUFF up to production!" - I know I have. Or even worse you do that and don't notice you did it.
Automation takes a lot of the risk out.
load more comments
(3 replies)
load more comments
(8 replies)
This application looks fine to me.
Clearly labeled sections.
Local on one side, remote on the other
Transfer window on bottom
Thats how you know its old. Its not caked full of ads, insanely locked down, and trying yo sell you a subscription service.
Except that FileZilla does come with bundled adware from their sponsors and they do want you to pay for the pro version. It probably is the shittiest GPL-licensed piece of software I can think of.
https://en.wikipedia.org/wiki/FileZilla#Bundled_adware_issues
load more comments
(2 replies)
load more comments
(1 replies)
The joke isn't the program itself, it's the process of deploying a website to servers.
The large .war (Web ARchive) being uploaded monolithicly is the archaic deployment of a web app. Modern tools can be much better.
load more comments
(2 replies)
Some of us still do 🙃
If it ain’t broke, don’t fix it.
One could argue the requirements have changed because the security and compliance part of the world finally caught up to modern software delivery concepts. Even the most dinosaur apps at compliant orgs are being dragged kicking and screaming into new CI/CD tools where applying governance and custody chains and permissions and approvals are all self documented automated hooks.
load more comments
(1 replies)
I remember joining the industry and switching our company over to full Continuous Integration and Deployment. Instead of uploading DLL's directly to prod via FTP, we could verify each build, deploy to each environment, run some service tests to see if pages were loading, all the way up to prod - with rollback. I showed my manager, and he shrugged. He didn't see the benefit of this happening when, in his eyes, all he needed to do was drag and drop, and load the page to make sure all is fine.
Unsurprisingly, I found out that this is how he builds websites to this day...
People don't use FileZilla for server management anymore? I feel like I've missed that memo.
I suppose in the days of 'Cloud Hosting' a lot of people (hopefully) don't just randomly upload new files (manually) on a server anymore.
Even if you still just use normal servers that behave like this, a better practice would be to have a build server that creates builds, like whenever you check code into the Main branch, it'll create a deploy for the server, and you deploy it from there - instead of compiling locally, opening filezilla and doing an upload.
If you're using 'Cloud Hosting' - for example AWS - If you use VMs or bare metal - you'd maybe create Elastic Beanstalk images and upload a new Application or Machine Image as a new version, and deploy that in a more managed way. Or if you're using Docker, you just upload a new Docker image into a Docker registry and deploy those.
load more comments
(4 replies)
load more comments
(3 replies)
FileZilla isn't even that old school, cuteftp was the OG one afaik.
No way, WS_FTP was more OG.
Oh god, I know all of these.
Also fuck Tim Kosse. Bundled Filezilla with malware and fucked up my machine in 2014. Had to reinstall Windows. I'll never use it again.
I use WinSCP on Windows and Forklift on MacOS.
Yeah you're totally right, I forgot about that.
There was flashfxp too but I think that was a fair bit later. Revolutionized being a warez courier.
load more comments
(5 replies)
load more comments
(1 replies)
Yeah, I used to use filezilla and I'm not that old... Right? ...Right?
load more comments
(1 replies)
I mean, a lot of docker files out there with COPY . .
True, but building the image is not the same as deploying to production.
load more comments
(1 replies)
Somehow I miss those days. Now you need weeks of training to understand the black magic behind all the build/deployment stuff in whatever cloud provider your company decided to use…
load more comments
(5 replies)
I remember this. I also remember using scp instead. And ftp, if I go back far enough. rsync is still my friend though zfs has mostly replaced it now.
How has zfs replaced rsync for you? One is a filesystem, and the other is a filesyncing tool. Does zfs do something im not aware of lol?
load more comments
(2 replies)
A lot are still doing that and haven't moved up
(Please at least use SFTP!)
FTP and rsync my beloved
I never liked FileZilla. I used Cyberduck
There's just so few decent FTP clients out there, and all of them are very ugly lol
load more comments
(4 replies)
load more comments
(2 replies)
okay, but why did you use a password when the ssh/sftp key is right next to the files
I used CuteFTP, but I am a gentleman
"Felt cute, might transfer files later, idk"
This is from before my times, but... Deploying an app by uploading a pre built bundle? If it's a fully self-contained package, that seems good to me, perhaps better than many websites today...
load more comments
(1 replies)
There's still a few sites I deploy changes to using ssh+rsync. ...which is made considerably easier by the fact that it's just a static website generated with Jekyll.
Did it for the first time two years ago. It was for my parent's business website. I see nothing wrong with this method.
You will pry ftp from my cold dead hands.
This is how I deployed an app less than 5 years ago (healthcare).
It's sad
load more comments
(2 replies)
Oh please, you didn’t even have to turn the cassette or floppy disc over. You and your luxuries.
view more: next ›