02 Jul, 2012, halmud wrote in the 1st comment:
Votes: 0
Hello Mudbytes,

I was curious if any of you have suggestions.
I am currently using Putty to log into my shell (linux) and make code changes. Sometimes I will write my code in Notepad++ before, but other times I will do it directly in the shell. I wanted to know if anyone had suggestions on an SSH client that would have Syntax coloring enabled or available? I appreciate any input.

-Halenbane
02 Jul, 2012, Runter wrote in the 2nd comment:
Votes: 0
My suggestion would be to write your code locally, do your testing locally, then push your code to a repository using a revision system like git or mercurial. It's quite easy to use a service like github to do this. Then all you need to do is pull the code changes down from the repository on the production server and start it up. I can't stress enough the other benefits of using revision systems, but even if you used it for just deploying, it's worth it.
02 Jul, 2012, Idealiad wrote in the 3rd comment:
Votes: 0
+1 to Runter's suggestion, but also what are you using to edit in the shell? I'm pretty sure Putty supports at least xterm 256 colors.
02 Jul, 2012, halmud wrote in the 4th comment:
Votes: 0
It does support colors, but I didn't see anywhere to specify what syntax you wanted to what color. It only has the basic foreground/background/bold options. I can see where Git is very very useful, and I plan on taking advantage of that, I just wasn't sure if any of the ssh clients could act like an IDE with the colored syntax. IE - With most IDE's you can load a default language and it will color your defines etc.
02 Jul, 2012, Runter wrote in the 5th comment:
Votes: 0
halmud said:
It does support colors, but I didn't see anywhere to specify what syntax you wanted to what color. It only has the basic foreground/background/bold options. I can see where Git is very very useful, and I plan on taking advantage of that, I just wasn't sure if any of the ssh clients could act like an IDE with the colored syntax. IE - With most IDE's you can load a default language and it will color your defines etc.


The SSH client has nothing to do with the syntax coloring. The application running on the server (like vim) after connected via your ssh client (putty) would send back the correct syntax highlighted text. Whether or not it's set up to syntax highlight is something entirely different, and is going to be based on the specifics of the editor you use. That's distinct from the SSH client, or even the technology you use to remote in. If you were working locally on the machine you wouldn't be talking about SSH at all, and you'd have the same shell to work out of.

I really think you should only do deployment/environment specific tasks using ssh. Can't stress that enough. If you're actually developing remotely over SSH you're really just working yourself in the wrong direction. Do it the easy way. Work locally. Get a sane deployment strategy after you work locally.
02 Jul, 2012, halmud wrote in the 6th comment:
Votes: 0
I appreciate your responses. I will be using GIT in the near future. I did find that using VIM instead of PICO does give me colored syntax, which atleast makes things a bit easier to look at if I happen to be in the shell.
03 Jul, 2012, Lyanic wrote in the 7th comment:
Votes: 0
Runter said:
If you're actually developing remotely over SSH you're really just working yourself in the wrong direction. Do it the easy way. Work locally. Get a sane deployment strategy after you work locally.

That's a curious statement. You seem to be implying that remote development and revision systems/deployment strategies are mutually exclusive. That's a false dichotomy. One could very well SSH into a system for development, utilize a revision control system and use it to deploy to a production system. I know plenty of people who do that. I do that. I have no desire to configure my everyday use system with the tools, packages and libraries necessary for development. I prefer something dedicated to that, where I risk no corruption of either. I prefer the ability to develop within the same environment from any system I can download PuTTY onto. And aside from the overhead of the separate system, there is no inherent disadvantage to developing remotely over SSH.
03 Jul, 2012, Idealiad wrote in the 8th comment:
Votes: 0
I don't think it's as important to have dedicated systems with the package and environment tools available nowadays, but I also think you can have the best of both worlds – edit locally using an editor with a ssh connection to your server. It's nice to minimize the time between editing and seeing results in your mud.
03 Jul, 2012, Kline wrote in the 9th comment:
Votes: 0
For years all I bothered with was SSH, use a console text editor, and work. The NeatBeans C/C++ build has been the only IDE that met my needs, yet I still find myself often going back to my SSH session because even across my home LAN, NetBeans is still slow and slightly clunky. Collapsible sections, syntax highlighting, revision control integration, remote GDB…The list goes on! NetBeans truly offers an amazing array of features that you can get working using a remote build server via a SSH tunnel and/or UNC file paths for mapped network drives in Windows. I still usually find myself getting frustrated with the speed of it, or how it will occasionally decide to use either my SSH tunnel or my mapped network folder, or both at once, when accessing files. It causes interesting problems with the program stating newer file versions were found when saving changes. Some things are highly configurable, others are not…So if your project doesn't fit one of their prescribed build system molds, it's not too slick.

I'd still recommend it to anyone working with a remote *nix build host and wanting to "sort of" develop locally and not strictly via a SSH console; but myself, I still keep ending up back in the console.
03 Jul, 2012, Runter wrote in the 10th comment:
Votes: 0
Lyanic said:
Runter said:
If you're actually developing remotely over SSH you're really just working yourself in the wrong direction. Do it the easy way. Work locally. Get a sane deployment strategy after you work locally.

That's a curious statement. You seem to be implying that remote development and revision systems/deployment strategies are mutually exclusive. That's a false dichotomy. One could very well SSH into a system for development, utilize a revision control system and use it to deploy to a production system. I know plenty of people who do that. I do that. I have no desire to configure my everyday use system with the tools, packages and libraries necessary for development. I prefer something dedicated to that, where I risk no corruption of either. I prefer the ability to develop within the same environment from any system I can download PuTTY onto. And aside from the overhead of the separate system, there is no inherent disadvantage to developing remotely over SSH.


Well, I'm not saying that to use revision systems you have to work locally. I'm saying it's better to work locally, and git lets you do it easily. So no false dichotomy here. The distributed nature of git uses a paradigm built for decentralizing the repository. Putting that aside, it's not true to say there's no disadvantage to developing on the system you're deploying on. You need internet connectivity. You cannot rely on tools that are generally nicer. It takes more resources. Advanced tests may be subject to limitations of the production resources. Costs go up, or you decide you can't afford to actually run those advanced tests. It's a singleton heavy system, so adding more developers to the work flow becomes onerous. And from a security perspective it's just generally bad to be doing the development this way. So in my view there's a lot of reasons, and I'm sure there's more than I mentioned here. I'm generally pragmatic so I say people should do whatever they're comfortable with, but we should also realize that there's pros and cons to consider with what we're comfortable with. Sometimes it's worth learning something a little different. In the processional development world this would never be considered. For all the reasons I just mentioned, but even more than that…it's just harder in the long run. If someone was having to learn the work flow from scratch anyways, I'd say it's just as much effort to learn how to develop via SSH and the configuration tricks and what not to get the shell setup properly as it is to work locally. Actually, I'd say it's less work since it's far more natural to do your work where you … do all your other computing.
03 Jul, 2012, Lyanic wrote in the 11th comment:
Votes: 0
Runter said:
Lyanic said:
Runter said:
If you're actually developing remotely over SSH you're really just working yourself in the wrong direction. Do it the easy way. Work locally. Get a sane deployment strategy after you work locally.

That's a curious statement. You seem to be implying that remote development and revision systems/deployment strategies are mutually exclusive. That's a false dichotomy. One could very well SSH into a system for development, utilize a revision control system and use it to deploy to a production system. I know plenty of people who do that. I do that. I have no desire to configure my everyday use system with the tools, packages and libraries necessary for development. I prefer something dedicated to that, where I risk no corruption of either. I prefer the ability to develop within the same environment from any system I can download PuTTY onto. And aside from the overhead of the separate system, there is no inherent disadvantage to developing remotely over SSH.


Well, I'm not saying that to use revision systems you have to work locally. I'm saying it's better to work locally, and git lets you do it easily. So no false dichotomy here. The distributed nature of git uses a paradigm built for decentralizing the repository. Putting that aside, it's not true to say there's no disadvantage to developing on the system you're deploying on. You need internet connectivity. You cannot rely on tools that are generally nicer. It takes more resources. Advanced tests may be subject to limitations of the production resources. Costs go up, or you decide you can't afford to actually run those advanced tests. It's a singleton heavy system, so adding more developers to the work flow becomes onerous. And from a security perspective it's just generally bad to be doing the development this way. So in my view there's a lot of reasons, and I'm sure there's more than I mentioned here. I'm generally pragmatic so I say people should do whatever they're comfortable with, but we should also realize that there's pros and cons to consider with what we're comfortable with. Sometimes it's worth learning something a little different. In the processional development world this would never be considered. For all the reasons I just mentioned, but even more than that…it's just harder in the long run. If someone was having to learn the work flow from scratch anyways, I'd say it's just as much effort to learn how to develop via SSH and the configuration tricks and what not to get the shell setup properly as it is to work locally. Actually, I'd say it's less work since it's far more natural to do your work where you … do all your other computing.

You're making a lot of assumptions and continuing to setup that false dichotomy. Did I ever say I was connecting to the production system to develop? You're also assuming that multiple developers are logging into the production system to develop (perhaps even with shared logins). I'd wager you're basing these assumptions on moronic things that MUD developers have commonly done in the past. You have this my/professional way vs. their way mentality, but you're assuming "their way" (the horrendously bad way you've seen/been exposed to in the past) is the only other way. That's the false dichotomy.

As for your other points….
Decentralized Git repository: Your point is invalid, since you made an incorrect assumption
Internet connectivity required: Always-on internet…not something I even think about anymore
Nicer tools: This is subjective. I dislike IDEs, or most anything with a GUI
Takes more resources: Marginally so, yes
Advanced tests limitations: You made that incorrect assumption again
Security issues: Once again…
Harder in the long run: This seems ambiguous, but I'd say it's a subjective statement

The only real con is the increased resources. One of the pros, as I mentioned before, is that I can connect to the same development environment from any system I can download PuTTY on. Some people just like a console. I am one of them.
03 Jul, 2012, Tyche wrote in the 12th comment:
Votes: 0
Runter said:
My suggestion would be to write your code locally, do your testing locally, then push your code to a repository using a revision system like git or mercurial. It's quite easy to use a service like github to do this. Then all you need to do is pull the code changes down from the repository on the production server and start it up. I can't stress enough the other benefits of using revision systems, but even if you used it for just deploying, it's worth it.


Why would one push their mud code, content or whatever to github.com and then login to their server to pull it from github.com?
If he's using SSH, he can easily just push it from his desktop right to his server. And unless one signs up for paid plan, github.com
repositories are public to the world, which might be a problem if one uses git for game content.
04 Jul, 2012, Jimorie wrote in the 13th comment:
Votes: 0
halmud said:
I did find that using VIM instead of PICO does give me colored syntax, which atleast makes things a bit easier to look at if I happen to be in the shell.


If you are familiar with Pico, you could try using Nano instead. Nano is a clone of Pico, with a (mostly) extended feature set, which includes syntax high-lighting.

If you work a lot in an SSH terminal, you should also find Screen to be very useful. Just a tip.
05 Jul, 2012, Runter wrote in the 14th comment:
Votes: 0
Tyche said:
Runter said:
My suggestion would be to write your code locally, do your testing locally, then push your code to a repository using a revision system like git or mercurial. It's quite easy to use a service like github to do this. Then all you need to do is pull the code changes down from the repository on the production server and start it up. I can't stress enough the other benefits of using revision systems, but even if you used it for just deploying, it's worth it.


Why would one push their mud code, content or whatever to github.com and then login to their server to pull it from github.com?
If he's using SSH, he can easily just push it from his desktop right to his server. And unless one signs up for paid plan, github.com
repositories are public to the world, which might be a problem if one uses git for game content.


Sure, he can just push it straight form his desktop to his server. In my opinion, it's slightly more work getting it setup, though. I'm all about doing less work. When I've worked with other people I've preferred having them push to github (as you pointed out, a paid account) where I'd merge in and pull down to a production server. So mostly just talking about what I've found to be a very easy work flow.
05 Jul, 2012, Runter wrote in the 15th comment:
Votes: 0
Lyanic said:
Runter said:
Lyanic said:
Runter said:

You're making a lot of assumptions and continuing to setup that false dichotomy.

Don't really have time or inclination to go through all your points, but the fact of the matter is we're on a thread where a newbie is talking about doing his editing "into my shell." So we're not even really talking about your specific case. Or I wasn't. I'm talking about generalizations of how people, like the person I'm giving advice to in this thread, are doing things. Probably without revision control systems. Probably on the same system they're deploying on. Probably under root. Since assumptions are all I have to go on with his work flow (and yours for that matter) I will continue to say that my points stand as great reasons to work/test on an isolated machine you have access to on your local area network that isn't your production environment. Which your normal desktop computer should work great as.
Random Picks
0.0/15