Why do people put their NPM modules in google drive?
It also doesn't help that there's no way to exclude a folder with wildcards so you can't blacklist all node_modules folders.
Same way that Dropbox works
So they are not manually choosing what to sync, they just put all of the work and other files they want to automatically sync inside of that folder. This ends up including things like node modules and things like that
As for corruption or overwriting files, I have rarely encountered issues, but Drive has file revision histories as well as a Trash can, so if you notice the problem and it's not spread over 5M files, you can roll back to last-known-good versions.
Implementation-wise under the hood is it really much different?
In my simplistic, probably overly naive idea it seems that a “network drive” built on top of Google Drive would still cache the files in memory, and improper shutdown or loss of network access could still leave your files in an inconsistent state. Probably they have a lot of advanced logic on top, that could roll back partial updates, or keep track of things so that the updates are not applied before sync is complete.
But anyways from this point of view sync vs network mounted drive feels like sync is a kind of network mounted drive that flushes to local disk in addition to working with the remote.
One of these days I want to build such things from scratch myself so that I can experience first-hand the horrors that lie underneath sync / network disk service setups modelled on my idea of Dropbox / Google Drive etc
I’m on a Mac and find that google drive’s Mac client is so unreliable as to be useless. It frequently crashes mysteriously, and even when running it doesn’t sync reliably. It feels like nobody is working on the software, and after all the layoffs that could well be true.
Say what you want about Dropbox, but I’ve never had a problem with it.
True.
I used Dropbox for many years without issue and moved because of the cost and the issue a few years back with not allowing it on certain Linux file systems.
Went to Google Drive and performance was shocking in comparison. At the time (don't know about now) it also felt like they had a deliberate policy to avoid showing cumulative file/folder sizes, meaning it was easier to pay for more storage than to find out what took the space and clean it up.
Since then I've spent a few years using PCloud, which was almost as fast as DropBox and more reliable at syncing than Google. Then I lost the ability to connect the client on a Mac for a couple of days, had a deeper look, and noticed a few files had had silent collisions between changes on Mac and Windows (not at the same time) leaving multiple versions (names suffixed with the machine they came from).
So I left there and went to OneDrive. To be honest I've found it okay other than one issue on a Mac where if I delete a file for some reason then when it vanishes to the recycle bin it reappears in the OneDrive root on the laptop. delete-immediately gets around that.
I'm now at the point where I use OneDrive for convenience/reliability but despite the cost have been considering a return to DropBox as cloud syncing seems to be impossible for anyone else to do properly. Is it still as reliable as it used to be?
But much better than google which just silently fails.
Now in your risk assessment the question of course is how likely it is that you lose the copy alone your dev system, CI system and productive version at the same time that npm loses it, but the first three happening isn't as unlikely as it seems: You work on a major refactoring and while deploying you run into a major problem and want to roll back, then artifacts from the old version might be gone. Of course there are ways to prevent that. But that's the risk assessment and prevention you have to make. A full backup including node_modules is one way of dealing with that.
I use both git and Dropbox, because I have multiple devices to sync: laptops, a desktop, and linux servers.
If you use a desktop and a laptop back and forth, git is quite inconvenient. You don't need to commit and push from the desktop to switch to the laptop with a folder level realtime sync solution.
Also, git only protects files that are staged, but Dropbox can restore any files to any point of file event (not periodic snapshot, but it keeps all file events). So combining both you are safe from any kinds of mistakes.
I use Dropbox because Google Drive sync wasn't stable enough for this kind of workflow but I am not sure if it has been improved lately.
Because git combined with Dropbox and the likes can be slow, lead to broken repositories, mad sync conflicts and so on? At least that is what I've witnessed with colleagues. This was years ago though, and I assume you dont have these issues or maybe a different workflow, so this is more like a word of warning for others: test this properly first before just diving into it.
Anyway, YMMV.
Are you sure those people were using their own personal dropbox folders? If they were sharing with each other that's a different thing entirely and requires a lot more care to avoid problems.
Yes, one single account.
while it's syncing and then start editing the same things on a different computer
IIRC this was one of the issues. Not necessarily because of shutting down, but just when using multiple computers one after the other and Dropbox not having synced in between. Not that niche depending on line of work, think lab-like setups where one thing gets deployed to multiple machines and deployment then gets tested. In one company the 'oh but you have to wait for dropbox to sync before doing that' and 'how?' responded by 'urm, yeah, check the timestamp on all files in that directory' was a rather common thing, often leading to stupid issues. Put git in the picture there and things won't get any better.
And even then it's just something like having disagreement about an index file. Easy to resolve.
Though outside of garbage collecting, git doesn't have many files that actually get changed. Mainly the ref pointers which are easy to resolve and the logs which aren't very important.
A git repo in Dropbox can appear to work okay with a single contributor where that contributor is only working on one computer at a time. But as soon as you add a second contributor, you very much should take Dropbox out of the process.
I’m not entirely happy with the idea of living in a world conquered by the lowest common denominator solutions.
“Hey, why can’t I get Dropbox to work on this laptop? I need it so can do emergency bug fixes from my personal laptop at home!” “Yeah, nah. Remember that security policy you signed as part of your employment contract? The one that says exfiltrating company or client data or code to non corporate systems is a fireable offence?”
I'm reminded that Lastpass got popped via an employee running a well out of date version of Plex with known RCE exploits and getting a keylogger installed:
“This was accomplished by targeting the DevOps engineer’s home computer and exploiting a vulnerable third-party media software package, which enabled remote code execution capability and allowed the threat actor to implant keylogger malware,” LastPass officials wrote. “The threat actor was able to capture the employee’s master password as it was entered, after the employee authenticated with MFA, and gain access to the DevOps engineer’s LastPass corporate vault.”
The hacked DevOps engineer was one of only four LastPass employees with access to the corporate vault.
I mean, I know exactly why. But why the fuck was the corporate Lasspass vault available to a staff member's home machine running Plex? Is the expense of a corporate vpn-locked laptop and a pair of Yubi keys too much for a fucking _Password Vault_ senior developer??? "Should we spend a couple of grand buying a work laptop for this guy who literally has the keys to our kingdom? Or do we save a few bucks and get him to work on the machine he already owns, the same one he runs outdated media server software and probably bittorrents all his porn with? What could possibly go wrong?"
Some of my projects aren't set up this way, and it can get annoying to have made a few small changes and be forced to commit them in order to pull them from upstairs.
I have modest storage needs in my role, but imagine a developer, Big Data user, or video editor used it. As long as they could tolerate the latencies, they might stash quite a bit in there.
https://support.tresorit.com/hc/en-us/articles/217103697-Exc...
With some C++ libraries or node_modules that can run up fast.
You can't do everything at once and git is counter-productive on day one, and the most important thing was they find programming remotely interesting at all.
The next most important thing is always working on a new copy.
How exactly you make those new copies barely matters at all compared to just having them at all.
Using something arcane and unforgiving and inscrutable and complex like git to accomplish those copies is way way down on the list.
The new student is barely interested in the actual coding to make a game if you're lucky. They would rather mow lawns than learn administriva like git.
It could even be argued as irresponsible to hand git to babies and expect everything to be fine. Just because we all have about 5 git commands we use 99.9% of the time, and have no problem 99% of the time because we learned how to "hold it right" and just always carefully do things in the right order, does not mean git can actually be made safe and simple. Those 5 or so commands aren't actually enough.
actually, a good way to think of it is releases. even with git, i keep a copy of each project release, that itself is not stored in git.
I haven’t used cli git since uni. GUI is better for basically everything except for a few rare and advanced commands.
Jeremy Howard (of Fastai fame) has a good analogy that we do not make people sit in a classroom for a semester to learn all of the theory of baseball. Instead, we give them a bat and a ball, and layer on the instructions of how the game works. You can get a good approximation of the game with just a couple minutes of instruction and refine the understanding from there.
i don't expect a fresh graduate to be a skilled git user but if the nature of development at work is substantially different from what the student learned at school, then they will have a much harder time adjusting.
they should at least be familiar with all the concepts that they will encounter in a junior job and not be faced with having to relearn a completely different development process.
The hard thing about source control is not the how — using the git CLI is only slightly more complicated than copying a folder. Git turns that into a very straightforward directed graph, and the CLI gives you a few commands to move around the graph, sprinkling some more edges and nodes wherever you like. It takes about an afternoon to figure out once you're onboard with the why.
The why of source control is the thing — and our industry is already full of people who don't understand it. That's how we get people who treat git as a "save" mechanism to be invoked whenever it's been a while since the last commit, or branches with one sloppy commit message after another [1], or entire repos that are just spaghettified carelessly-merged hairballs of commits.
Mastering the why of source control means learning when to cut a commit, what shape that commit should be, and why that is.
And I think that's more my objection to the teaching approach outlined here — without any other context, it reads to me like it's not quite focusing on the right things. At worst, it's inducting the student into the industry-standard cargo-cult approach to source control. [2] If the why isn't learned, then it doesn't really matter whether the specific motion is copying folders or typing in git CLI commands.
Ideally I think source-control techniques could be introduced right when they're going to be interesting or fun — when it's time to build something together with someone else. Then that set of lessons could start by copying folders and eventually building up to git — and each lesson could show how good, disciplined use of source control concretely improves the collaboration process.
[1]: https://tbaggery.com/2008/04/19/a-note-about-git-commit-mess...
happy path
What I want to do is take one step at a time, and build on what they already know.
Then when they can program, you can show them how to use Git and the superpowers that comes with it.
FWIW, my thoughts are basically that it's a question of sequencing the lessons and framing the overall purpose: https://news.ycombinator.com/item?id=35411405
The analogy was imagine if we taught music that way, where you spent years learning fundamentals and theory before ever being allowed to touch an instrument.
> "Eleven years of piano lessons taught me something about playing the piano
> but almost nothing about music," she has said. "I was skating on the
> surface. If a child is shown a written crotchet they have no physical
> understanding what’s behind that. Kodály musicianship puts petrol in the
> tank in that it gives them a profound experience of music-making, through
> the voice, building up a repertoire of songs and giving them the
> unconscious knowledge of pitch-matching, walking the pulse, rhythm,
> phrasing and improvising – before making it conscious."