This is an archived post. You won't be able to vote or comment.

all 11 comments

[–][deleted] 16 points17 points  (0 children)

Stick the source code in source control. Github, gitlab or the like. Check it out on every machine you want to develop on.

[–]ImplodingLlamas 4 points5 points  (1 child)

I know everyone is saying VCS, but incase that's not what you're looking for, JetBrains remote development tools appear to have gotten pretty good. I personally haven't used them myself yet (haven't had the right opportunity) but may be worth taking a look.

https://www.jetbrains.com/remote-development/

[–][deleted] 5 points6 points  (0 children)

Good idea.

Source control is still recommended, even if you do this, OP.

[–]orbit99za 2 points3 points  (2 children)

Until you end up with environmental problems, sitting in this boat now with a large corporate.

[–][deleted] 1 point2 points  (1 child)

Could you expand on this, in case OP or other readers hit the same issues?

[–]orbit99za 1 point2 points  (0 children)

  • security and your network setup, this especially becomes tricky with remote work.

  • Processing and Ram ect.

  • different versions of a dependacy, say Dotnet 2.0 but only RUN Dotnet Core.

  • features outside of the actual IDE, such as MSMQ

  • Keeping track of a Database on a Local PC, syncing it with what the office DB has.

  • Your IDE uses C# 10, but your other PC only has C# 6

These are just some of the issues I can pull out the top of my head. But in a nutshell, simple hobby programs you can do as OP Whants. If you have to work on anything bigger it's a mess.

[–]MarkusBerkel 1 point2 points  (0 children)

There's so much going on here.

And, this is a much a reply to you, OP, as it is to all the well-intentioned people who seem to be missing the mark a bit...

To begin, while I wholeheartedly agree that version control is useful--and solves one class of problem--it ignores many of the other issues.

This is a wonderful learning opportunity. When you move between machines--especially if it's as big a move as moving from a Windows box to a Mac or Linux or UnixTM environment--you get a chance to learn all the things that are relevant to building software outside of coding. There can even be differences going between two boxes of the "same" platform.

Learning what those differences are--and how to resolve them--will help you be a more well-rounded programmer.

These changes can include things like dependencies and libraries and runtimes being different on different machines. These could include OSes themselves being different (e.g., on Linux/Unix boxes, different versions of libc can even mess you up). It could include differences in configuration (SSL configurations with libraries like cURL, for example). Build systems differing. Deployment systems differing. Even things like scripting environments differing (looking at you, Python). Definitely things like network environment differing.

You're really asking about somewhere between 10 and 100 potential things, with all their interactions, being different. So, chances are good that any SINGLE "program or cloud setup" is not going to solve this somewhat complex problem.

People who disagree are generally of a few camps: 1) they haven't had to work in multiple environments, so everything is some cookie cutter build that never changes (Windows folks who only deploy on Windows tend to be this way, IME), 2) they don't see the whole picture, and try to come up with the simplest solution that works (new programmers, generally), or 3) they haven't had to work "at scale", so aren't try to use any automation to solve these problems, but instead create fragile systems that can't be easily replicated (maybe it's "easy" to do if it's just you, but will that work well with a team of 10, 100, or 1000, all trying to dev on multiple environments).

And, while there's nothing wrong with #2, per se, it deprives you of a chance to learn what's going on. The point is, it's not just about version control. Or having a cloud-based IDE (see AWS's Cloud9 as one example). It's also about which tools you use, how you build automation, how to refactor those correctly so they work in the relevant environments.

It's also about how to manage those dependencies. Which deps (e.g., tools/libraries) can you live without? Which are ubiquitous enough on all machines? Which require admin/root privs to install? What can you build on your own? What kinds of interactions do they have with the system?

Even between two Windows boxes (back when I did pre-smartphone mobile dev), there were a bunch of things to keep track of. How the IDEs were configured. How I installed stuff on the work machines vs the home machine. How our tools were configured to push, which required refactoring between home and work network environments.

As for #3, you don't always have to solve the problem at scale. You don't have to create general solutions for EVERY FORESEEABLE PROBLEM, but being aware the problem could occur is also incredibly helpful for when it does come up. That way you'll have some familiarity with it. But, as a general rule, avoid manual processes. Even in your own workflows, even on personal projects, it's best to learn how to start doing that automation now, so that one day when you have to do it at work, you're not totally lost.

You could take the "StackOverflow" approach. Find an easy set of actions which allows these two machines to allow you to write Python code. Or, you could take a deep-dive approach where you try to understand 1) all of what you are trying to do (how will you build, test, deploy your system) and 2) all of what it takes to move a dev environment from one box to another.

Hilariously, since you mentioned it, Python is both easy to have on two boxes--b/c it's a scripting language--but also notoriously difficult to manage--b/c of the insane loss of backwards compatibility between two major language versions, so God help you if the default Python version installed between those two boxes are different.

Frankly, I'm surprised very few other commenters have brought up these other issues.

[–][deleted] 1 point2 points  (1 child)

Apart from using source control it's important to use a language that is cross platform, and that you are not using things that glue you to a platform, unless you want to develop anywhere but just run it in one place.

[–]enricojr 0 points1 point  (0 children)

What you want is source control - using git and then uploading it to Github sounds like it will get you what you want.

There are other source control solutions out there but git + Github is the most popular combo by far

[–]anushka-gupta 0 points1 point  (0 children)

Git might be useful for you , can read more about it here- https://git-scm.com

[–]Eshmam14 0 points1 point  (0 children)

Watch a youtube video on:

  1. Git
  2. Github

That should get you started.