Much of the article is about outsourcing software development to rural Ozarks. Hey, my town is rural and lots of programmers are moving here from the nearest city for better QoL. Why should we have to commmute to work everyday?
It works only if the rural area has high-speed Internet, or else the job doesn't require it. I wouldn't have been able to do any of my Nortel work here in Kenora (no DSL, cable or EVDO, and the satellite is too high latency for the VoIP and "interactive applications over VPN" that they required). I can't even get reliable cell coverage here; every call will drop out or die -- that simply would not have worked for Nortel.
Fortunately this job doesn't have high Internet access requirements (although running "cvs diff" takes FOREVER! (any encryption like ssh has a lot of back-and-forth traffic which sucks over satellite).
I think "ruralsourcing" only works if rural means "small town", not "outside of any town". "suburbansourcing", anyone?
Slightly off topic here, you might want to give Git (http://git-scm.com/) a try for revision control. You won't have network bottlenecks for diffs (or checkins) like you just described having with CVS.
I tried git, bzr, and hg, but none of them convinced me to make the switch. Their CVS conversions aren't very good—maybe I should just start fresh rather than trying to import. The emacs-devel mailing list contains many complaints that it takes hours to do the initial bzr pull if you don't have broadband, with no progress messages or any indication that it's actually getting anywhere. DVCS systems make me feel like a Homo erectus with his trusty dixie-cups-and-string, unable to understand what the big deal is with those incomprehensible rotary-dial phones.
It's been 2½ years since your last comment on my journal! We're moving more stuff to MySQL these days. It works great on a dedicated server! Although the reciprocal replication jams up occasionally...
Yes, you should definitely start fresh. Migrating from CVS just won't end well.
Git is probably your best bet. It's what's used for the Linux Kernel (in fact, Linux himself is the author of Git) and the Drupal project is in the middle of switching over to it.
I haven't done too much LJ over the last year+. I'm trying to get back into the swing of things. MySQL does work out well, even with replication. I use a replicated setup to power Anthrocon's on-site registration (http://code.google.com/p/anthrocon-reg/). :-)
I *really* don't like the idea of a "fresh start" with complete loss of history. I've been through that once before (at a previous job), and it really sucks when you have a team of 30 developers who need to know who made what change when.
With this job with pyesetz, it would be less important... as there is only one customer, there is only one deployed version, so everything is "in the now".
Until you came along, all the cvs commit messages were blank because there was no one to read them. So really there is very little history that actually needs to be kept from the old days.
The limitations of your laptop and its dual-hard-drives-filled-to-the-brim argue against DVCS, but your slow-handshake Internet connection argues for it.
Doesn't rsync use ssh? The manual says rsync uses remote-shell (must be ssh because rsh is disabled on the server) when you use a single colon after the hostname, which I always use. So you could rsync to your workspace on the server and then commit from there. Too bad that cvs is so stupid about diffs, though: uploading the entire file to the server to have the diff done there is not good.
True, but then I'd have a (huge!) repository on my machine instead... plus I'd have repository conflicts when two checkins are overlapping.
Maybe the simplest thing is to have a second workspace, where the files are kept up-to-date, but not modified locally. Keeping another checked-out copy, instead of a repository with full history, might be a good solution.
You would, and it'd be a lot faster, too. A local hard drive is about 2 orders of magnitude faster than doing stuff over a WAN.
Conflicts would be less of an issue, too. The problem with CVS (and SVN) is that they are version-oriented. Git, Mercurial, and more recent revision systems are just that, revision-oriented. It makes all the difference when branching and then merging those branches, for example. I say this as someone who was afraid to branch things in CVS, but does so all the time in Git, because it's easy.
Kenora (no DSL, cable or EVDO, and the satellite is too high latency for the VoIP and "interactive applications over VPN" that they required). I can't even get reliable cell coverage here...
Isn't this a demerit for your plan to settle in Northern Ontario for the medium term?
any encryption like ssh has a lot of back-and-forth traffic which sucks over satellite).
It is possible to set up a persistent ssh connection and then allow cvs to tunnel through it. Would this be faster, or is the cvs protocol just as bidirectional as the ssh setup protocol?
"suburbansourcing", anyone?
With the possible exception of the GTA, Canada doesn't seem to have "suburbs", as that word is used in the States. You're either a "city mouse" or a "country mouse" with no middle ground. My postal code has a nonzero second digit, so I am living in "the urban core of a country town", which is what passes for a suburb around here (but there's a horsefeed factory down the street and occasionally a local Amish family will clip-clop past my house).
Isn't this a demerit for your plan to settle in Northern Ontario for the medium term?
No; I don't need VoIP or VPN for my job, and cell coverage may be different (better, worse) wherever I settle. Besides, I can't afford a place in the city on my salary :-)
It is possible to set up a persistent ssh connection
I'll try it, but I don't have high hopes; besides, your cvs pserver port is disabled on the server. I've been playing around with a remote backup service lately; it's just as bad. sshfs+truecrypt and encfs are both painfully slow with their back-and-forth traffic. rsync works great, but isn't encrypted.
You're either a "city mouse" or a "country mouse"
Can't I be a "country coon" instead? I define suburbia as a town with many more residents than the local industry can support, i.e. a bedroom community for another city.
I can't afford a place in the city on my salary What salary? This ain't no sinecure, Mr. Coon!
your cvs pserver port is disabled on the server That could be changed, if it would help.
sshfs+truecrypt and encfs are both painfully slow with their back-and-forth traffic Yeah, it's the same half-duplex problem that Kermit and [XYZ]MDOEM were trying to solve decades ago, and the same that people have with USB today (USB is half-duplex, with a huge pause when sender and receiver swap roles).
I define suburbia as a town with many more residents than the local industry can support, i.e. a bedroom community for another city. That definition works well, but has a tendency to become obsolete. The children of the people who move to Suburbia as a bedroom community then open their own businesses locally; eventually the community can become independent of the neighbouring city (on its way to becoming a city in its own right), but it's still "suburban" in its zoning and flora and roadways and population density. San Jose is a city that still looks like the suburb of San Fransisco that it once was.
With the possible exception of the GTA, Canada doesn't seem to have "suburbs"
That's one thing I miss is having more space, or at least more vacancies. I understand the logic of keeping city services more affordable and having a working public transit. And my prior US city requiring new houses to have five acre lots is just bad planning. But from my semi-rural upbringing I always feel like neighbours are too close to me.
Then there are the comical people who have the shiny and unused F350 with duals and extended cab who hold everyone up trying to park in a lot where the lines are tighter than the ridiculous truck's dimensions.
no subject
Date: 2010-07-13 06:20 pm (UTC)no subject
Date: 2010-07-13 08:09 pm (UTC)Depends on where you are!
Date: 2010-07-13 11:37 pm (UTC)Fortunately this job doesn't have high Internet access requirements (although running "cvs diff" takes FOREVER! (any encryption like ssh has a lot of back-and-forth traffic which sucks over satellite).
I think "ruralsourcing" only works if rural means "small town", not "outside of any town". "suburbansourcing", anyone?
Re: Depends on where you are!
Date: 2010-07-14 02:15 pm (UTC)Re: Depends on where you are!
Date: 2010-07-14 07:01 pm (UTC)It's been 2½ years since your last comment on my journal! We're moving more stuff to MySQL these days. It works great on a dedicated server! Although the reciprocal replication jams up occasionally...
Re: Depends on where you are!
Date: 2010-07-14 07:10 pm (UTC)Git is probably your best bet. It's what's used for the Linux Kernel (in fact, Linux himself is the author of Git) and the Drupal project is in the middle of switching over to it.
I haven't done too much LJ over the last year+. I'm trying to get back into the swing of things. MySQL does work out well, even with replication. I use a replicated setup to power Anthrocon's on-site registration (http://code.google.com/p/anthrocon-reg/). :-)
Re: Depends on where you are!
Date: 2010-07-15 12:24 am (UTC)With this job with pyesetz, it would be less important... as there is only one customer, there is only one deployed version, so everything is "in the now".
Re: Depends on where you are!
Date: 2010-07-15 12:56 am (UTC)The limitations of your laptop and its dual-hard-drives-filled-to-the-brim argue against DVCS, but your slow-handshake Internet connection argues for it.
Doesn't rsync use ssh? The manual says rsync uses remote-shell (must be ssh because rsh is disabled on the server) when you use a single colon after the hostname, which I always use. So you could rsync to your workspace on the server and then commit from there. Too bad that cvs is so stupid about diffs, though: uploading the entire file to the server to have the diff done there is not good.
Re: Depends on where you are!
Date: 2010-07-15 01:07 am (UTC)Yes, rsync is using ssh. I don't mind the slow commits (they are rare), but slow diff's and updates ("what have I modified? why?") are annoying.
Re: Depends on where you are!
Date: 2010-07-15 12:20 am (UTC)Maybe the simplest thing is to have a second workspace, where the files are kept up-to-date, but not modified locally. Keeping another checked-out copy, instead of a repository with full history, might be a good solution.
Re: Depends on where you are!
Date: 2010-07-15 12:25 am (UTC)You would, and it'd be a lot faster, too. A local hard drive is about 2 orders of magnitude faster than doing stuff over a WAN.
Conflicts would be less of an issue, too. The problem with CVS (and SVN) is that they are version-oriented. Git, Mercurial, and more recent revision systems are just that, revision-oriented. It makes all the difference when branching and then merging those branches, for example. I say this as someone who was afraid to branch things in CVS, but does so all the time in Git, because it's easy.
Re: Depends on where you are!
Date: 2010-07-14 06:40 pm (UTC)Re: Depends on where you are!
Date: 2010-07-15 12:16 am (UTC)No; I don't need VoIP or VPN for my job, and cell coverage may be different (better, worse) wherever I settle. Besides, I can't afford a place in the city on my salary :-)
I'll try it, but I don't have high hopes; besides, your cvs pserver port is disabled on the server. I've been playing around with a remote backup service lately; it's just as bad. sshfs+truecrypt and encfs are both painfully slow with their back-and-forth traffic. rsync works great, but isn't encrypted.
Can't I be a "country coon" instead? I define suburbia as a town with many more residents than the local industry can support, i.e. a bedroom community for another city.
Re: Depends on where you are!
Date: 2010-07-15 01:04 am (UTC)What salary? This ain't no sinecure, Mr. Coon!
your cvs pserver port is disabled on the server
That could be changed, if it would help.
sshfs+truecrypt and encfs are both painfully slow with their back-and-forth traffic
Yeah, it's the same half-duplex problem that Kermit and [XYZ]MDOEM were trying to solve decades ago, and the same that people have with USB today (USB is half-duplex, with a huge pause when sender and receiver swap roles).
I define suburbia as a town with many more residents than the local industry can support, i.e. a bedroom community for another city.
That definition works well, but has a tendency to become obsolete. The children of the people who move to Suburbia as a bedroom community then open their own businesses locally; eventually the community can become independent of the neighbouring city (on its way to becoming a city in its own right), but it's still "suburban" in its zoning and flora and roadways and population density. San Jose is a city that still looks like the suburb of San Fransisco that it once was.
Re: Depends on where you are!
Date: 2010-07-15 06:08 pm (UTC)That's one thing I miss is having more space, or at least more vacancies. I understand the logic of keeping city services more affordable and having a working public transit. And my prior US city requiring new houses to have five acre lots is just bad planning. But from my semi-rural upbringing I always feel like neighbours are too close to me.
Then there are the comical people who have the shiny and unused F350 with duals and extended cab who hold everyone up trying to park in a lot where the lines are tighter than the ridiculous truck's dimensions.