-
Notifications
You must be signed in to change notification settings - Fork 123
Cowsay coursework #189
Cowsay coursework #189
Conversation
will discuss this further as it might be two courseworks, perhaps? Progression is: 1. "decline the verb" cowsay - by installing and running it in several different ways 2. investigate a downloaded package 3. write an MVP cowsay 4. iterate on that Presume this will need some revision to be more CYF-like as I am not yet familiar with the house style!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really like the stripping-back-the-layers approach - producing something fun and useful, and then trying to implement more of the pieces themselves! Really nicely put together!
|
||
We did it! But let's explore some more. How would you install cowsay as a dependency? Make a new folder called /cowsaying and initialise a new package. | ||
``` | ||
mkdir /cowsaying |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing this highlights is that I don't think we have a consistent way we get our trainees to organise code on their laptops, which occasionally causes problems. Maybe we could introduce something like "All of your projects/git repos should be in ~/code" or similar early in the course, to help with this?
We definitely see problems with people accidentally running npm init
in their homedir and it breaking stuff - having clear guidance here would help to ensure people don't get tripped up...
For now in this exercise, though, maybe ~/cowsaying would be handier than /cowsaying - I suspect the latter may have some permissions issues for some trainees :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we added some instructions to navigate to the trainee's CYF work folder, would mkdir cowsaying
work? I feel like adding to ~
would not be helping with the folder mess.
* Make an ASCII cow. | ||
* Write a function that puts the string into the cow's speech bubble. | ||
|
||
Write your solution in a file called solution.js and test it by running your program in the command line. How will you handle a null argument? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there are two layers being discussed here - the sentence is about the command line (where you can't pass null), and the "null argument" question seems to be more about the function... It could be a little clearer to say something like "no argument being passed" so that both sentences are talking about the same layer of abstraction?
|
||
We could make our program more accessible by adding a command line interface that prompts us to write in the cow's words. What tools can we use? I think we could use: | ||
|
||
* A command line interface. I'll start you off by letting you know that there is a built in CLI called [readline](https://nodejs.dev/learn/accept-input-from-the-command-line-in-nodejs). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think writing async callback functions is sadly a bit advanced to just link to for JS1/JS2 and expect the trainees to be able to follow - if we're going to use readline
, we'll probably need a bit more scaffolding or a step-by-step to follow... Could be really interesting though, but should probably be marked pretty clearly as a very optional extension
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed - I think with some scaffolding around how to accept command line argument it could be a really nice exercise
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I agree with this. What about splitting cowsay into two: Part one is just investigating installations and running things in terminal and then return to it in JS3 where we write our own cowsay and iterate on that. Returning to cowsay and being able to write your own by JS3 would create a satisfying experience of progress and mastery.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...That's with some more scaffolding around the MVP cowsay script and then this time using it to layer up on features - could maybe do readline, commander, and then a library of cows/ducks/unicorns?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of splitting up the project, however I would point out that we don't actually touch NPM at all until React in the current syllabus. I'm actually not quite sure at what point we introduce the terminal now? My feeling is that we should really focus on the basics of JS before introducing packages.
I was actually going to suggest that the first section of the project might be useful as a lesson/coursework in JS3 as an fun introduction to packages.
The second half would be useful as a challenge, especially if we gave some more step-by-step instructions or provided some scaffolding.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, pushing the whole thing into JS3 sounds great!
@SallyMcGrath Sorry I only just got around to look at this. Fantastic work here! I really love the leveled nature of it and as Daniel said the "stripping away the layers". As mentioned, I think it might be a little two advanced for JS1/JS2 (not at all your fault!) but I think we can definetly have search for a nice place for it. Currently "JavaScript Core 3 - Week 3" is quite light on coursework (apart from a Project they're also working on) so I think that could be a nice fit since it's preparing them nicely for the React world of more imports and dependencies. Here's the repo for that week What do you think? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @SallyMcGrath! This is really nice work 👍
I've left some comments, and I agree with the points from @illicitonion and @ChrisOwen101 above. My suggestion is that we use the package exploration bits in JS3 as an introduction to packages/NPM and adapt the solutions for usage in JS1/2 as exercises with the CLI bits provided as scaffolding.
|
||
We did it! But let's explore some more. How would you install cowsay as a dependency? Make a new folder called /cowsaying and initialise a new package. | ||
``` | ||
mkdir /cowsaying |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we added some instructions to navigate to the trainee's CYF work folder, would mkdir cowsaying
work? I feel like adding to ~
would not be helping with the folder mess.
npm init | ||
``` | ||
Press return through all the options and then do. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I was about to suggest that we remove this, to avoid the interactive prompt. However I had forgotten that npm install X
without a prior npm init
will a) output a bunch of scary looking warnings and b) not create a package.json
.
So instead, maybe we could switch this to npm init -y
? This runs the same init command but answers yes to all the questions (which is fine since we don't expect to publish this).
``` | ||
const cowsay = require("cowsay"); | ||
``` | ||
And log a cow to the console that says "I require a package". Add some more arguments if you can. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps it might be useful to link to the cowsay documentation here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually... having poked around with it a bit, I think the docs are pretty confusing (and maybe plain wrong?). So I'm having second thoughts about it.
e : "oO", | ||
T : "U " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found these options a bit confusing when I first saw them.
The docs seem to imply that it accepts eyes
and tongue
as options, but having looked in the source I don't think that's actually the case :/ Perhaps we could introduce them as a separate step with an explanation of what they mean?
``` | ||
const cowsay = require("cowsay"); | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor nitpick, you get nicer syntax highlighting if you mark the code block as Javascript by putting js
just after the initial three backticks (I'd give an example but it's painful to add markdown examples in markdown)
|
||
We could make our program more accessible by adding a command line interface that prompts us to write in the cow's words. What tools can we use? I think we could use: | ||
|
||
* A command line interface. I'll start you off by letting you know that there is a built in CLI called [readline](https://nodejs.dev/learn/accept-input-from-the-command-line-in-nodejs). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of splitting up the project, however I would point out that we don't actually touch NPM at all until React in the current syllabus. I'm actually not quite sure at what point we introduce the terminal now? My feeling is that we should really focus on the basics of JS before introducing packages.
I was actually going to suggest that the first section of the project might be useful as a lesson/coursework in JS3 as an fun introduction to packages.
The second half would be useful as a challenge, especially if we gave some more step-by-step instructions or provided some scaffolding.
let cowsaying = | ||
` | ||
${topLine.repeat(saying.length)} | ||
< ${saying} > | ||
${bottomLine.repeat(saying.length)} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we stripped these lines out and turned them into an exercise, I think that would make it a lot more approachable for JS1/2 students
Co-authored-by: Alasdair Smith <[email protected]>
Co-authored-by: Alasdair Smith <[email protected]>
Made obsolete by #311 |
What does this change?
Module: JS1-3 or JS2-1
Week(s): 1
Description
Addressing #162
(Assuming this is a jumping off point and will be revised as I am not yet familiar with CYF house style!) But in general the thinking was to sort of "decline the verb" by doing the same thing in progressively more complex ways.
Rendered version
Who needs to know about this?
@ChrisOwen101