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 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
The large .war (Web ARchive) being uploaded monolithicly is the archaic deployment of a web app. Modern tools can be much better.
Of course, it’s going to be difficult to find a modern application where each individually deployed component isn’t at least 7MB of compiled source (and 50-200MB of container), compared to this single 7MB war that contained everything.
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.
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.
manually FTPing the files up to the server seems ridiculously antiquated
But … but I do that, and I’m only 18 :(
Like anything else, it’s good to know how to do it in many different ways, it may help you down the line.
In production in an oddball environment, I have a python script to ftp transfer to a black box with only ftp exposed as an option.
Another system rebuilds nightly only if code changes, publishing to a QC location. QC gives it a quick review (we are talking website here, QC is “text looks good and nothing looks weird”), clicks a button to approve, and it gets published the following night.
I’ve had hardware (again, black box system) where I was able to leverage git because it was the only command exposed. Aka, the command they forgot to lock down and are using to update their device. Their intent was to sneakernet a thumb drive over to it for updates, I believe in sneaker longevity and wanted to work around that.
So you should know how to navigate your way around in FTP, it’s a good thing! But I’d also recommend learning about all the other ways as well, it can help in the future.
(This comment brought to you by “I now feel older for having written it”, and “I swear I’m only in my fourties,”)
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 :)
But it’s genuinely what we were all doing not so long ago
Jokes on you, my first job was editing files directly in production. It was for a webapp written in Classic ASP. To add a new feature, you made a copy of the current version of the page (eg index2_new.asp became index2_new_v2.asp) and developed your feature there by hitting the live page with your web browser.
When you were ready to deploy, you modified all the other pages to link to your new page
Good times!
Shitty companies did it like that back then - and shitty companies still don’t properly utilize what easy tools they have available for controlled deployment nowayads. So nothing really changed, just that the amount of people (and with that, amount of morons) skyrocketed.
I had automated builds out of CVS with deployment to staging, and option to deploy to production after tests over 15 years ago.
Cries in REST API
Oh please, you didn’t even have to turn the cassette or floppy disc over. You and your luxuries.
You will pry ftp from my cold dead hands.
I mean, a lot of docker files out there with COPY . .
