I really do not mean to be a troll, here, but it seems to me that the trend is to develop SWC/DC away from a coherently organized workshop centered around the idea of creating a pipeline that is run using scripts, invoked from a command line, and that is under version control. That is how I interpreted the original idea; perhaps incorrectly.
It seems as though most lessons are now R Studio based. Some Python lessons may be Spyder based. I'm pretty sure I seen much discussion about GUI front-ends to Git. If I were taking a workshop with Atom, gitk, and R Studio, I would really have to wonder why there was a shell component at all. I think that in the past, one learned shell to move around, nano to edit, then one used nano and the shell to create R or Python files, which were run from the command line, and all of the code was under Git control which was also run from the command line. That scheme has an internal coherence, it builds skill upon skill, and there is a recognizable goal. The lessons seem to be getting more and more independent and less and less like parts of something bigger -- at least that's how I would see it from a participants perspective and based on the anecdotes I have from people who've been to recent camps. There have been many discussions about individual lessons and far fewer about connections among lessons, or so is my impression. Is optimizing each lesson separately really going to lead to a globally optimized result? What is the result that is desired? I really don't want to start a firestorm, but I think it's good every once in a while to step back and look at how the pieces fit together. How does teaching someone the shell help them with Atom, or vice-versa? Would it be better to just drop the shell entirely and create a full lesson on Atom? The world does move on, and I'm just missing the point, in which case ignore me. I'm really just trying to give something to think about, as part of 'due diligence'. If you think Atom is the way to go, then you're definitely on the right track with trialing in a lesson and seeing how it plays. On Thu, Mar 30, 2017 at 8:19 AM, Tracy Teal <[email protected]> wrote: > Also +1 to Noam's suggestion > > On Thu, Mar 30, 2017 at 4:59 AM, Ethan White <[email protected]> wrote: >> >> I support this change in concept and agree with Noam that it should only >> be undertaken broadly following experimentation to make sure it works more >> effectively than the current approach and to iron out any unanticipated >> issues. >> >> Ethan >> On 03/30/2017 07:13 AM, Noam Ross wrote: >> >> I support this, but I think the appropriate approach is to gather >> evidence. Many (most?) changes to lessons and methods start as experiments >> by instructors, so I think a set of instructors should produce the following >> for an upcoming workshop, which other instructors can try out: >> >> - A fork of the workshop webpage with install instructions >> - A fork of the shell lesson >> - A fork of the git lesson >> >> Then, following some reports from instructors after a few workshops and a >> few inevitable tweaks, we can see if this merits widespread adoption. >> >> I agree with Tracy that command-line editor skills are potentially useful >> for many learners, but I think (without real evidence) that (a) learning a >> simple command line editor like nano is a low barrier *once one is familiar >> with the shell and the notion of a text editor already*, so people using >> remote machines will be much of the way there under this approach, and (b) >> the overall gain in improved workshop flow may be more important. A >> command-line editor may be one of the things one "demos" in a workshop where >> learners have a question or one anticipates that some have immediate remote >> computing needs. >> >> On Thu, Mar 30, 2017 at 5:58 AM Raniere Silva <[email protected]> wrote: >>> >>> Hi all, >>> >>> today at the workshop, >>> one of the our Windows learners asked me why after quit nano the >>> previous command weren't available when scroll the window up. >>> The learner was very annoyed to not be able to see the history. >>> >>> I would like to motion to change nano with Atom as the >>> recommended/default >>> text editor for our workshops. I don't want to start yet another flame >>> war, >>> we already had lots and lots of discussion about this, >>> so I will summarise the benefits and drawback of my proposal. >>> I will ask that before suggest another text editor instead of Atom, >>> stop and think that the text editor will benefit novice learners >>> instead of just make your life easy as instructor because you use X on >>> your daily work. (I don't use Atom!) >>> >>> # Benefits >>> >>> - Is open source. >>> - (Just) works in Windows, Mac and Linux. >>> - Easy to install in Windows, Mac and Linux. >>> - "All versions" are available to Windows, Mac and Linux. >>> >>> Some software, e.g. Skype, works in Windows, Mac and Linux but >>> different versions are available to different OS. >>> - Configure PATH to be accessible from Git Bash. >>> >>> No need for extra configuration or our script to fix PATH. >>> - Well mantained and supported. >>> - Syntax highlight out of the box (AFAIK). >>> - Lots of plugins for learners that decide to keep using Atom. >>> >>> AFAIK there is a plugin that allow learners to use Atom >>> to edit remote files, e.g. on clusters. >>> - Beautiful interface. >>> >>> # Drawback >>> >>> - Learners and instructions will need to switch windows. >>> >>> # (My own) conclusions >>> >>> Replace nano with Atom will avoid many of the our issues during the >>> workshop, such as "we will use nano but if you don't have nano you can >>> use X", and reduce the volunteer work that we need to maintain the >>> quality of our workshops. The price that we will need to pay is switch >>> windows during the workshop. >>> >>> Thanks, >>> Raniere >>> _______________________________________________ >>> Discuss mailing list >>> [email protected] >>> http://lists.software-carpentry.org/listinfo/discuss >> >> > > > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.software-carpentry.org/listinfo/discuss _______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
