This page serves to plan the agenda for the session, then logs the finalized minutes, as well as information necessary for final summary, upon the completion.
START A BIT > Learning Packages > LP2402: 4 Weeks Package with Wire Game 2G > This page
Recap: Function basic, how we use it so far
Group programming: Refactor the programming using functions, part 2/2
Practice system thinking, details thinking, synchronization across the functions
Reproduce the program at home
Very good learning experience with Group Programming, the students are well involved, engaged and seemed more motivated
Nice welcomed fika with chips and soft drinks, even not so much healthy, but seemed helping the social better
The planned learning points still seem a little too much, not finished what we planned, some interesting points were left
Not having enough effort to make the cybersecurity topic discussion, on the one hand due to the 1st session unable to happen, on the other hand, due to fewer participants, not suitable for group discussion, will make this in the future.
Not having time to prepare for diploma... But a bag of chocolate prepared for each student as a gift for completion
96 Kr: Tutor parking
80 Kr: Fika, helped by Felix
10:05-10:15:
Check in and prepare snacks
10:15-10:37:
Review last week's refactor 1/2 result, recap the key knowledge points
Talk about the scenario for today's refactor 2/2, with the requirement of auto and random change of mode
Detail discussion about the requirement, what it means, how we can start doing it, and the risks, the purpose is to think about the engineering implementation, and prepare the awareness of the complexity when doing the things
10:38-10:47: Fika break and social
10:47-11:26:
Group programming for refactor step 1 as planned, but we splited into step 1.1 and step 1.2, where 1.1 is just to add the random change of mode, and test the program on board, then we realised that there is no notification to user, so we naturally moved to step 1.2 to add notification.
11:26-11:36:
Extra break, because the work is intensive, the students need a rest before going on.
11:36-12:10:
Group programming for refactor step 2 as planned.
We stopped after finishing step2, so there was some little extra steps planned but not taken.
10:00-10:10: Prepare, check-in discussions -> latecomers could miss this without big lose
Check in and prepare
Scenario: Our CTO demo our prototype product to customer, we got good feedback, and the customer is aware of the unstable untouching issue, we are allowed to sort out a real solution in the future, it's not a critical issue now, but in the TODO. Now we got clearer answer from the customer that the mode change should happen in a random manner! Let's do this today, so then we can put our wire game G2 in a new milestone, ready for production soon!
10:10-10:30: Reflection of group programming last time
5': Short reflection: Wire game key knowledge points (how do you detect the touching from physical action to programming? How do you count the failure?) Boolean type variable https://makecode.microbit.org/courses/csintro/booleans
10': Short reflection on the refactor 1/2 last week, recap function basic understanding
10:30-10:45: Reproduce the refactor 1/2 result, mutual learn and help
20': Reproduce the refactor 1/2 work to your local laptop, please help each other to finish this, then we can enjoy fika earlier.
10:45-11:00: Fika break and social
11:00-11:45: Group programming to refactor the prototype, part 2/2
Random pick an order https://www.randomresult.com/
Goal is to keep everything we made unbroken, but adding a new feature to automatically change mode randomly, but wait, let's think about some details...
The mode changing, it should happen independently in a parallel thread
It should have a clear way to let the player know the mode is changed, so the player can change action
Use the LED matrix and sound? Wait, but the LED matrix and buzzer are possibly being used by the failure warning function now... there could be a competing situation to use those precious shared resources... mutex lock for shared resources sync in competing access
The mode change will happen immediately, just changing the boolean variable to opposite value, what if the player is still focusing on the previous mode playing, and how can he/she get the right time to change playing manner? During the change, the player could miss the target, and fails with unpleasant
If the game is over, it should be over, no strange things still running
Step-by-step idea, perhaps each student can take one step:
Step 1: A quick try and test
Let's get a "forever" block, add a random sleep, then change mode to opposite (using "not" operation is smart).
Add LED display and sound as notification.
Now, let's download to test! -> looks cool, the mode change happens as expected, but wait, after a closer test, it seems very tricky things happen during the mode change! There is always 1-2 times unexpected failure! Why? Because the mode change happens first, and then the sound and LED notification, the player is already too late when hearing or seeing the notification!
Humm... shall we put the mode change after the notification? Sounds fine, but wait, the player is still unable to catch exactly which time point the new mode takes valid after the sound/LED...
A better way is to lock for change, during the changing, we should pause detecting any failures.
Step 2: Add change lock and test
Add a new boolean variable, init it in "prepare" function as false first.
Then change this lock to true before changing mode, and change it to false after mode well changed.
Then pause failure detecting when change lock is true.
Now, let's download to test again! -> Good, it feels much more stable now, during the mode change, the player hears the sound and immediately change action, then the device doesn't miss catch any failure
Step 3: Let's test more, and find improvements
Just play several time, feel and find any issues
Improvement 1: Game over handling
We have found that the game is never ended correctly, even after 10 times failure, the mode change still runs, and failure detection is still running...
It's fine to add "if counter < 10" in the failure detection and mode changing parts, but it'll create duplicate parameter "10" in 3 places, it'll be easy to forget modifying this key number to update the failure threahold in the future, so a better way is to add a game_over variable.
Create a game_over variable, init it as falure in prepare function, change it to true when the counter hits 10, and add "if not game_over" to the failure detection (try to use logical operation "AND") and mode changing, done!
Let's download to test again! Be careful, it can still be buggy! Because the mode change has a "sleep", duing the sleeping, it doesn't know the game is already over, so there will be 1 extra unexpected mode change... so the "if not game_over" should be placed after the sleeping
Improvement 2 (optional): External LED as mode indicator
After mode change, if any failure detected, the LED display is changed, it's hard to remember which mode we are in now... Any ideas? external LED as helper indicator, we can reflect the knowledge of LED usage and digital signal output!
Let's review everything we have now, what do you think? How much do you understand? Any thoughts about the challenges? Isn't it a little more difficult than we thought? So much details and the complexity increases very much when we introduce just a new feature, synchronization issues seem a big thing that we never thought about before
Finally, let's read the Python code together! Is it interesting with the textual coding? We can try learning more in next Learning Package
11:45-12:00: Reproduce everything we have made so far, bring home and test on your own wire game at home with your family! Try to explain to them how you have made this, and what challenges you have met, what you have learnt.