Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

running the 2nd problem from the menu generates many myaddon dirs #27

Open
ceejbot opened this issue Jul 4, 2014 · 4 comments
Open

Comments

@ceejbot
Copy link
Contributor

ceejbot commented Jul 4, 2014

If you re-run the instructions for the first "mission possible" problem statement instead of using "goingnative print", it will generate lots & lots of new myaddon folders. It will also generate myaddon dir nested inside a myaddon dir.

Recording this bug here because it was a source of confusion among workshoppers, who mostly didn't know about print.

@rvagg
Copy link
Contributor

rvagg commented Jul 5, 2014

This is a problem I've pondered and discussed before having used workshopper-boilerplate elsewhere. The alternative is to check for a file by that name and not recreate if it's there. The problem is: what if they already have a file by that name that's unrelated? What if they screw up the file we gave them and they need it again? Sure we can provide a mechanism to re-create it but my conclusion is that it's easier to just go overboard and make them cleanup afterwards than give them yet more instructions to read about what to do -- you've witnessed first-hand how bad people are at reading instructions, the more you give them the less they read.

I'm open to trying alternative things but we have to balance instructions against greasing the wheels of progress.

@mdda
Copy link
Contributor

mdda commented Jul 21, 2014

Just a quick comment, though : The lesson 2 (for me, maybe because I'm doing a 'goingnative print' to capture the output to an editor window) specifies that the directory to use is 'myaddon1'. And it's also generated myaddon1.cc, (and a bunch of other identical files). But lots of the tests, etc, depend on this being precisely named 'myaddon' and 'myaddon.cc', etc.

So the flexibility of some of the boilerplate functions will kill your users...

@rvagg
Copy link
Contributor

rvagg commented Jul 22, 2014

the directory name is inconsequential, nothing will fail if you call it "myrandomdirectory". The 4th exercise will give you a .cc file but you have to move it in to the right place anyway so tie onus is on you to fix that up regardless.

@mdda
Copy link
Contributor

mdda commented Jul 28, 2014

Could there be something that says that people should be flexible in the introductory text, then? It's particularly painful for newcomers since, on the one hand there's the imperative "Read the Instructions" and on the other "Modify the instructions to fix up what the lesson's code just did".

Even if one focusses all attention on myaddon1 (as I had to after initially doing goingnative && goingnative print > printedinstructions-for-editor-window.txt), the later modules still keep adding new directories, and either referring to them directly, or to myaddon/. Neither are accurate : But, since the inter-op requires some file-reference voodoo (at least until it becomes clear how it all fits together, which takes a few of the exercises), a few encouraging words could be in order.

Later on, when picking a myaddonN.cc (N in {1,2,3,4,5,6}), I boldly made the decision to remove all the extraneous stuff and work solely on myaddon/. Of course, everything then made sense.

I understand your sentiment that people should figure it out for themselves. OTOH, at a NodeSchool event, it's better to avoid having to ever announce that the instructions shouldn't be read verbatim...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants