5 ms·
I see no reason to develop on a server. If that's what you're doing, that's a very bad sign in most of the cases.
by Avalaxy 12y ago
I see no reason to develop on a server. If that's what you're doing, that's a very bad sign in most of the cases.
- SpaceInvader 12y agoWhy you think is that? Could you, please, elaborate?
- Avalaxy 12y agoSure. Couple of scenarios where I've seen people working on a server and why that's bad: 1) The developers in this company that work with ColdFusion develop their software on a dev server because they would otherwise require expensive licenses for each dev machine. This means that devs often find themselves editting the same file. It also means that one dev can break the software for all other devs. Last but not least, it makes version control a ton harder. 2) Another scenario is where you fix a bug on the production server to roll out a fix as soon as possible. Sometimes this is acceptable, but there's a big risk because you no longer have the ability to test the code first. This also makes version control harder, because the next time you deploy your code, the changes will get overwritten. 3) Working with a remote IDE or just having your own development server: doesn't really make any sense, most devices (laptops, PCs, tablets) can run some kind of IDE/editor locally and allow you to run the code locally. Using remote software only adds a huge dependency on having a working internet/network connection.
- SpaceInvader 12y agoWell, that is true if you're working on the production code directly and this is not always the case when working on remote server. But I understand your point of view. :)
- aidos 12y agoActually, I have a coldfusion app that I look after (small amounts of maintenance). These days it's easiest for me to simply make changes in the production machine and then commit/push when done. It's not a big deal if you're the sole developer and the changes are simple enough. Regarding the license issue, I believe Adobe have a developer edition that's free to install but is limited to a single ip accessing it. That may have changed now - I've used an open source alternative called Railo for years that away better in almost every way. My setup day to day is a local vagrant machine I ssh into and do everything from there (vim). Some of my work requires far more powerful machines so I also have machines running at AWS that I use in exactly the same way with exactly the same config. I just got sick to death of trying to install / configure stuff on OS X where nothing works quite as it should.
- snowwrestler 12y agoThis all seems related to web development. A friend of mine codes for genetic research and the data sets are far too big, and the processing too intensive, to run on any laptop. He works directly on the server because that is the only place his code can run.
- peterkelly 12y agoI often do this - although it's not a "server" in the sense of a machine hosting production services. The code I'm writing relies on a high bandwidth/low latency connection, which I don't have from my normal place form work (home). It's much faster to run tests on an EC2 instance than from my laptop.
- scott_s 12y agoThere is an enormous reason if you work on, or use, systems designed for massive parallelism.
- Avalaxy 12y agoI still don't see the necessity... Develop locally, test remotely.
- deleted 12y ago[deleted]
- ghgr 12y agoSome examples that just come to my mind: - You need software/dependendencies/licences you don't have in your local machine. - You need to edit a config file (/etc/hosts or whatever) in your server - You are in a Windows computer (that's not yours) and you need to make a quick change in your Ubuntu development server. - You need to edit some files when deploying (databases are no longer in localhost, /home/myname/ is /home/servername/, etc.) - You launched a large script in your server and need to (view or parse logs | edit the code and re-launch it | check why it didn't work) - etc.
- joshka 12y agosoftware deps - this is a possible fair point. I've always managed to solve this by bringing the deps local though as a general sanity rule. config - why not source control it? quick change - why would you do a quick change differently to a non-quick change? edit while deploying - why wouldn't you script / source control this for repeatability / maintainability? log parsing - it sounds like you've got an edit, verify loop going on. Why wouldn't you want to formalize this so that you can see which changes align with which results?
- scott_s 12y agoIt's not necessary, it's just extraordinarily convenient. I don't have to ever say, "Oh, wait, I'm on my laptop now, I can't run an application with 100 processes without causing my system to grind to a halt." Even the sequential performance of the remote systems is much higher than my laptop. The system in front of me is a means to interface with the real system, and has been for a long time. Granted, I have worked on parallel and distributed languages and runtimes for most of my professional life.
- nemoniac 12y agoI develop & test algorithms on a server. Saves on laptop battery life when I can't plug in.