On Wed, Apr 29, 2015 at 10:39 PM, Cameron Simpson <c...@zip.com.au> wrote: > On 29Apr2015 22:10, boB Stepp <robertvst...@gmail.com> wrote:
>> On the smart enterprise where we (now) do our clinical planning they >> are very strict: no installing any external software; no accessing the >> Internet; no email; etc. Not all centers adhere to this level of >> strictness, but ours does. [...] But I am reluctant to do >> anything that I am not allowed to replicate on smart enterprise. I am >> trying to keep it as close to identical to the actual clinical >> environment as I can. > > > And fair enough too. I frequently wish our developers' dev environments more > rigorously modelled the target environment. > >> Perhaps this is misguided on my part? > > > Not necessarily. > > But I would be inclined to distinguish your working tools from the target > environment. > > For example, I commend you making your dev environment as close to identical > to the actual clinical environment as you can. But I wouldn't deprive > yourself of tools that enhance your code management practices without > affecting that environment. > > For example, there is much to be said for tracking your changes with a tool > like git or hg. It encourages your to annotate your changes, and lets you > review history to see when and why some change occurred, especially if a new > bug has arisen. Distributed version control systems like git and hg also > make it easier to work on distinct changes to the same code as separate work > processes; of course the price for such a workflow is that you need to merge > the two things later and ensure that they do not interact badly. Totally, totally convinced of the correctness of this. Actively working to implement this. See below. > If you're serious about keeping the two environments very similar, you could > always do your _coding_ on a third platform (a laptop or whatever) using > your desired tools and _deploy_ the code to the dev (and later, prod) > environments from there, keeping the dev environment pristine. By "deploy", > that can be as simple as copying the code to the target. That is what I have implemented as of today. I installed Git on my Windows PC where I have been doing my actual coding anyway, created the needed repositories, including an extra one on our intranet in case my PC dies, etc. The current project is now in version control. After doing some editing and saving, I use the Git bash shell that came with Git and scp the file(s) to the dev environment, do my testing (Still manual; working on getting automated, but this will have more of a learning curve for me than using Git.), etc. When I get a meaningful chunk of something done, I add and commit in Git on the Windows PC. Less often I push to the intranet repo. Your comments suggest that I am on a reasonable track. The main danger as I see it is that if I am not careful, then the code on the dev environment could diverge from the state of code on my Windows PC, i.e., I forgot to do the scp part. But when I am actively working on a section of code I always insert a few print statements (Py 2.4!) to verify I am getting what I should when I test it out--even if I don't have an actual problem yet. And so far this has immediately revealed those few instances so far when I forgot to save to the dev machine (Usually when someone has interrupted my workflow, a near constant occurrence at work.). -- boB _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
