-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.qmd
570 lines (392 loc) · 20 KB
/
index.qmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
---
title: 'Fun and Learning. In a Dungeon!'
subtitle: 'Matt Dray, March 2023<br>[matt-dray.github.io/in-a-dungeon](https://matt-dray.github.io/in-a-dungeon)'
format:
revealjs:
theme: [default, assets/styles/dungeon-styles.scss]
---
## tl;dr {.center}
Try project-driven learning. Have fun.
`r fontawesome::fa('github')` [github.com/matt-dray/r.oguelike](https://github.com/matt-dray/r.oguelike)
`r fontawesome::fa('book')` [rostrum.blog/tags/r.oguelike/](https://www.rostrum.blog/tags/r.oguelike/)
`r fontawesome::fa('globe')` [matt-dray.com](https://www.matt-dray.com)
::: {.notes}
* 'Too long; didn't read' for a summary. Snapshot this slide and then fall asleep.
* Basically: try small-scale, focused project-driven learning where you have fun and fail. I've often found found this preferable to what I'm calling module-driven development.
* Links are to these slides; an R package I'll be talking about; to a series of blogs about its development; and to my own personal page.
:::
# \[1\] Hello
::: {.notes}
* We've got some exciting speakers today from a range of interesting organisations.
* ...And you've also got me.
* I've been in the Civil Service for nearly a decade in multiple data and analysis roles across several orgs.
* I'm currently involved in statistics quality, production, presentation and Reproducible Analytical Pipelines (RAP). Part of that will involve advising on learning and development.
* I'm not here to tell you anything particularly clever. This is not a technical talk, per se. I'm going to talk about capability, and learning and development,m ostly.
* And yes, I'm using 1- instead of 0-indexing. Come at me bro.
:::
## Disclaimers {.center}
* These are my thoughts
* We're all different
* This is context-dependent
::: {.notes}
* These are my personal experiences and I'm not speaking officially.
* I'm privileged: my managers have given me time and space; I have some time to learn as a hobbyist too.
* What works for me might not work for you. Approaches may suit one environment but not another.
* You might think about this from the perspective of a learner, or as a manager wanting to develop staff.
:::
# \[2\] The idea
::: {.notes}
* I had little experience of programming when I joined the Civil Service. I didn't come from a computer science background.
* I think I'm competent now (in R at least). I have a good sense of what has helped me develop on that journey.
* Maybe one person will rethink their approach to learning and development.
* Maybe one person will be mildly be amused by making R go off-piste, or will feel a pang of nostalgia.
:::
## Learning approaches {.center}
A. Module-driven
B. Project-driven
::: {.notes}
* I need to start by setting up a bit of a false dichotomy.
* I want to tell you about learning with a project-driven focus, which requires a definition.
* But I will also need to define what I think is the status quo, 'module-driven development', for comparison.
:::
## \[A\] Module-driven {.center}
* Passive walkthroughs
* Comprehension tests
* It's done _to_ you
::: {.notes}
* I'm talking generally about short videos or static documents, probably followed with comprehension exercises.
* This extends to taking part in big workshops with a low teacher-to-student ratio.
* I'm not naming any providers, but you might be able to think of some.
* The training is administered to you, a participant.
:::
## \[A\] Module-driven {.center}
* Box-ticking? Badge-chasing?
* Too generic?
* Forgettable?
::: {.notes}
* I've been told to do these to tick a box in my learning plan.
* They're rarely tailored to your specific needs.
* You're at the mercy of the trainer.
* Often not a good mimic of how the world actually works.
* They often lack engagement; you just need to sit through them all and get a passing grade.
* I personally find it difficult to retain the information and the notes are often just the content.
:::
## \[B\] Project-driven {.center}
* Solve a small 'problem'
* Discrete scope
* It's done _by_ you
::: {.notes}
* What do you need to learn? How can you make this a discrete project in the form of a package, an app, generative art, a series of scripts, etc?
* Limit its scope early, solve one problem, expand later.
* The learning is controlled by you, not administered to you. You are not a sponge.
:::
## \[B\] Project-driven {.center}
* Fail meaningfully
* Talk about it
* Have fun
::: {.notes}
* Making a mistake will engage you to solve it.
* Broadcasting can help keep you in check, bring other people on your journey, and help you in unexpected ways. I don't think this is emphasised in modular learning.
* The data you use and the functionality of the thing you create don't have to be meaningful. It might be something that helps your organisation. But it can be a bit silly, like in the example I'll show in a minute.
:::
# \[3\] Example
::: {.notes}
* This is a project-driven example of mine.
* It's slightly contrived because I chose a past example that involves connectivity and patterns (themes of this conference).
* It also panders to the nerds.
* I'll tell you about some specific things I wanted to learn; the silly, discrete project I concocted to learn them; how communicating about it has helped me; and how this approach led to some unexpected bonus outcomes.
:::
## Goals {.center}
1. Interact with user
2. Detect and respond to IDE
3. Build simple algos from scratch
::: {.notes}
* I have a running list of things I want to learn. Sometimes these are really small things, like an individual function.
* A good exercise is to think how a few of them might be combined to achieve some goal.
* I expect to build packages for use by near-beginners; interactive confirmation is more friendly and could limit damage.
* Sometimes behaviour differs by operating system, but sometimes the development environment too. It's easy to get stuck thinking about RStudio if you're an R user, but what about people on the terminal or elsewhere?
* I mentioned coming into the Civil Service without computing experience. I think it's a good exercise to think through the logic of an approach and 'roll your own' in a learning context.
:::
## Format {.center}
* An R package
* Openly available on GitHub
* Narrative devlogs
::: {.notes}
* So I know what I want to achieve, what project format makes most sense?
* Packages are a fundamental discrete structure for R code.
* This has the advantage of being open for others to use and contribute to.
* I also decided that I would write short blogposts, or 'developer logs', to explain my thinking out loud.
:::
## {.center-h}
<img src="assets/images/r.oguelike-hex.png" alt="A black hexagon with a green border. Text below center on the hexagon reads 'r.oguelike' in green. Above that is a 3 by 10 grid of punctuation characters in green. Far left and right edges are hashmarks and between them are periods, as well as a single 'at' symbol and dollar symbol. The pattern mimics a text-only roguelike videogame typical of the 1980s.">
`r fontawesome::fa('github')` [github.com/matt-dray/r.oguelike](https://github.com/matt-dray/r.oguelike)
`r fontawesome::fa('book')` [rostrum.blog/tags/r.oguelike/](https://www.rostrum.blog/tags/r.oguelike/)
::: {.notes}
* The whole thing is bundled up in the r.oguelike package, which is available from GitHub.
* You can also read the devlog series.
:::
## {.center-h}
<img src="assets/images/r.oguelike-chase.gif" alt="Output in the R terminal. The top section is a tile grid of characters laid out like an 80s videogame with text-only graphics, like Rogue. Red hashes are wall tiles Black periods are floor tiles. A green dollar sign, a yellow 'a', a pink letter 'E' and a blue 'at' symbol. Underneath is a status bar with some inventory information and instructions on how to play. The cursor is waiting on a line that says 'input'.">
::: {.notes}
* So what did I end up doing? Well, I made an interactive, turn-base, tile-based game for the R console. Which is... unnatural.
* I created functions to procedurally-generate dungeons, where the player collects useable items into an inventory and battles an enemy, which chases you around.
* This takes inspiration from Rogue, released in 1980, and later 'roguelikes' that it influenced.
:::
## Goals {.center}
1. Interact with user `r fontawesome::fa('check')`
2. Detect and respond to IDE `r fontawesome::fa('check')`
3. Build simple algorithms from scratch
::: {.notes}
* I used `readline()` to prompt the user and read the response.
* I detected whether the user was in RStudio, where they would have to use WASD keys to move, or Terminal, where I could use the {keypress} package for detecting keypresses directly (i.e. arrow keys).
* I also implemented procedural 'cave' generation and simple breadth-first pathfinding. I'll talk about hose in a little more detail.
:::
## Procgen {.center}
::: {.panel-tabset}
## Step 1
```
# # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # . # # # # # # # #
# # # # # # # # # # # # # # # # # # # #
# # # # # # # # # . # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # #
# # # . # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # . # # # # #
# # # # # # # # # # # # # # # # # # # #
```
## 2
```
# # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # #
# # # . . . . . . . . . # # # # # # # #
# # # . # # # # # # # . # # # # # # # #
# # # . # # # # # . . . # # # # # # # #
# # # . # # # # # # # # # # # # # # # #
# # # . . . . . . . . . . . . # # # # #
# # # # # # # # # # # # # # . # # # # #
# # # # # # # # # # # # # # . # # # # #
# # # # # # # # # # # # # # . # # # # #
# # # # # # # # # # # # # # . # # # # #
# # # # # # # # # # # # # # # # # # # #
```
## 3
```
# # # # # # # # # # # # # # # # # # # #
# # # # # # . # # . # # # # # # # # # #
# # # . . . . . . . . . # # # # # # # #
# # # . # # . # # # # . . # # # # # # #
# # # . # # # # # . . . # # # # # # # #
# # . . # . # # # # . # # # # # # # # #
# # . . . . . . . . . . . . . # # # # #
# # # # . . # # # # # # # # . # # # # #
# # # # # # # # # # # # # . . # # # # #
# # # # # # # # # # # # # . . # # # # #
# # # # # # # # # # # # # # . # # # # #
# # # # # # # # # # # # # # # # # # # #
```
## 4
```
# # # # # # # # # # # # # # # # # # # #
# # # # # # . # . . # # # # # # # # # #
# # . . . . . . . . . . # # # # # # # #
# # . . # # . # . # # . . # # # # # # #
# # # . # # # # # . . . # # # # # # # #
# # . . # . # # # # . # # # # # # # # #
# # . . . . . . . . . . . . . . # # # #
# # # . . . # # . # . # # # . # # # # #
# # # # . # # # # # # # # . . . # # # #
# # # # # # # # # # # # # . . # # # # #
# # # # # # # # # # # # # # . # # # # #
# # # # # # # # # # # # # # # # # # # #
```
## 5
```
# # # # # # # # # # # # # # # # # # # #
# # . # # # . # . . # # # # # # # # # #
# . . . . . . . . . . . . # # # # # # #
# # . . # # . # . # # . . # # # # # # #
# # # . # # # # # . . . # # # # # # # #
# # . . # . . # # # . # # # . . # # # #
# # . . . . . . . . . . . . . . # # # #
# # . . . . # . . # . # # # . # # # # #
# # # # . # # # . # # # # . . . . # # #
# # # # # # # # # # # # # . . . # # # #
# # # # # # # # # # # # # # . # # # # #
# # # # # # # # # # # # # # # # # # # #
```
:::
::: {.notes}
* The basic process for dungeon building is to lay some randomised points; join them; expand randomly to the north, south, east or west over _n_ iterations.
* The user can select a number of parameters like the size of the dungeon; the number of iterations, whether to join the points randomly or frin order ('snakiness').
:::
## Pathfind {.center}
::: {.panel-tabset}
### Step 1
```
# # # # # # #
# . . . . . #
# . E . . . #
# . . . . . #
# # # # # . #
# . . . . . #
# . @ . . . #
# . . . . . #
# # # # # # #
```
### 2
```
# # # # # # #
# C B A 9 8 #
# B A 9 8 7 #
# A 9 8 7 6 #
# # # # # 5 #
# 2 1 2 3 4 #
# 1 0 1 2 3 #
# 2 1 2 3 4 #
# # # # # # #
```
### 3
```
# # # # # # #
# . . . . . #
# . . E . . #
# . . . . . #
# # # # # . #
# . . . . . #
# . @ . . . #
# . . . . . #
# # # # # # #
```
:::
::: {.notes}
* How can the enemy navigate to the player?
* Generate a layer or 'mesh' that gives you the number of tiles away from the player.
* Move the enemy to a tile with a lower value in this 'nav mesh'.
* Recalculate every time the player moves.
* This means the enemy will move around obstacles to meet the player.
:::
## Goals {.center}
1. Interact with user `r fontawesome::fa('check')`
2. Detect and respond to IDE `r fontawesome::fa('check')`
3. Build simple algorithms from scratch `r fontawesome::fa('check')`
::: {.notes}
* So that's all the goals ticked off.
:::
## Format {.center}
* An R package `r fontawesome::fa('check')`
* Openly available on GitHub `r fontawesome::fa('check')`
* Narrative devlogs `r fontawesome::fa('check')`
::: {.notes}
* So that means that I met the discrete project structure of the approach.
* I have a minimum viable product that taught me what I needed; that exists openly for me and others to refer to; and that has some supporting narration that explains my thinking.
:::
## Bonus round {.center}
1. Package maintenance
2. [Play in-browser](https://mybinder.org/v2/gh/matt-dray/play-r.oguelike/main?urlpath=rstudio) with [Binder](https://mybinder.org/)
3. A _third_ dimension?!
::: {.notes}
* But there were also some extra things I learnt as a bonus of the project-based approach.
* These are things I hadn't set out to learn.
* I got suggestions as a result of the project being open.
* I was able to build on the output of my original goals to expand the project.
:::
## {.center-h}
<img src="assets/images/snapshot-pr.png" alt="A screenshot of a pull request in the r.oguelike GitHub repository. User trevorld added snapshot tests to the repo and matt-dray merged it.">
::: {.notes}
* Working in the open on GitHub and in writing devlogs meant that others could contribute.
* This user noted that I wanted to test my function for generating dungeons to make sure the output was what I expected.
* This introduced me to [snapshot testing](https://testthat.r-lib.org/articles/snapshotting.html), where you can compare a function's output to some known output on record.
:::
## {.center-h}
<img src="assets/images/issue.png" alt="A screenshot of an issue in the r.oguelike GitHub repository. User trickytank added a printout of an error after user input.">
::: {.notes}
* In a similar vein, working in the open meant that people could find issues.
* This user came across a bug.
* I was able to hunt it down and refactor the code a bit, given me more experience of package maintenance.
:::
## {.center-h}
<img src="assets/images/binder.png" alt="A screenshot of RStudio running in the browser with the package r.oguelike preinstalled.">
::: {.notes}
* This is RStudio running in the browser with the {r.oguelike} package pre-installed.
* This witchcraft is thanks to the Binder project.
* This means you can play {r.oguelike} in the browser, lol.
* Binder has implications for teaching people R concepts on the same 'hardware' without the hiccups that can come from everyone having slightly different set ups on their computers.
:::
## {.center-h}
<!-- Vertical centering of QR code via https://github.com/quarto-dev/quarto-cli/discussions/1386 -->
:::: {.columns style='display: flex !important; height: 90%;'}
::: {.column width='50%'}
<img src="assets/images/binder-mobile.jpg" height="650px" align="center" lt="A screenshot of RStudio running in a mobile-phone browser with the package r.oguelike preinstalled.">
:::
::: {.column width='50%' style='display: flex; justify-content: center; align-items: center;'}
<img src="assets/images/binder-qr.png" height="350px" align="center" alt="A QR code that opens RStudio in the browser with the R package r.oguelike preinstalled.">
:::
::::
::: {.notes}
* At least one nerd in the room is probably wondering if you could run this in your mobile's browser.
* Yes, you can.
* No, you shouldn't.
* But I put a QR code there anyway. Is it a rickroll?
:::
## {.center-h}
<img src="assets/images/isocubes-chase.gif" alt="Output in the R terminal. The top section is a tile grid of characters laid out like an 80s videogame with text-only graphics, like Rogue. Red hashes are wall tiles. Black periods are floor tiles. A green dollar sign, a yellow 'a', a pink letter 'E' and a blue 'at' symbol. Underneath is a status bar with some inventory information and instructions on how to play. The cursor is waiting on a line that says 'input'.">
::: {.notes}
* And purely for fun, I did a series of extensions to the graphics using experimental packages.
* [This example](https://gist.github.com/matt-dray/a2db654bc7c09a7be1f1d32cdc3e1a45) uses [the {isocubes} package](https://github.com/coolbutuseless/isocubes) by [Mike Cheng](https://coolbutuseless.github.io/) to draw my tiles as cubes This is made entirely within R, which is impressive for R.
* I also looked at [the {eventloop} package](https://github.com/coolbutuseless/eventloop) by the same author for continuous keypress inputs.
* more impressively, Mike [presented](https://www.youtube.com/watch?v=LPotWAJnE_s) at last year's Posit conference an R port of the 1991 game Another World.
* So R is not a language for statistical computing anymore, it's a game engine!
:::
## Project-driven? {.center}
* Solve a small ‘problem’ `r fontawesome::fa('check')`
* Discrete scope `r fontawesome::fa('check')`
* Fail meaningfully `r fontawesome::fa('check')`
* Talk about it `r fontawesome::fa('check')`
* Have fun `r fontawesome::fa('check')`
::: {.notes}
* So, did I meet my own definition of a project-driven learning?
* Yeah.
:::
# \[4\] Consider
::: {.notes}
* So hopefully my point is clear and the example is useful, if contrived.
* But where to start?
* There's a few ideas for you to get started, or for you to share with your team.
:::
## In-gov {.center}
* [Accelerators](https://www.gov.uk/government/publications/data-science-accelerator-programme/introduction-to-the-data-science-accelerator-programme)
* [Volunteering](https://analysisfunction.civilservice.gov.uk/careers/volunteering/)
* [Coffee & Coding](https://analysisfunction.civilservice.gov.uk/support/reproducible-analytical-pipelines/coffee-and-coding/#cabinet-office)
::: {.notes}
* There are some structured offers within government that implement contained, project-driven learning.
* Data Science and visualisation accelerators are cross-government.
* You are entitled to volunteering, where you could take on a project-driven approach.
* Coffee & Coding (or similar) let you share your progress, hold yourself to account and to network with the wider analytical community. This can improve your chances of those 'bonus' features for your project.
:::
## External {.center}
* [tidytuesday](https://github.com/rfordatascience/tidytuesday)
* [30DayChartChallenge](https://30daychartchallenge.org/), [30DayMapChallenge](https://30daymapchallenge.com/)
* [genuary](https://genuary.art/)
::: {.notes}
* There are several prompt-driven schemes that also work in the context of project-driven learning.
* Tidytuesday is a community-hosted event that provides a dataset on a weekly basis that you can go away and explore to produce some kind of output (a table, a chart, an app, etc).
* There's a bunch of month-long events throughout the year that do a similar thing, but give you a daily challenge within the monthly theme (e.g. charts, maps, generative).
:::
## To reiterate {.center}
* Module-driven isn't always bad
* Project-driven might be useful
* Think before you default
::: {.notes}
* There's a time for module-driven learning, perhaps when you literally know _nothing_ about a subject.
* But project-driven can be a really fruitful.
* Consider how you/your team can make best use of this approach.
:::
## tl;dr {.center}
Try project-driven learning. Have fun.
`r fontawesome::fa('github')` [github.com/matt-dray/r.oguelike](https://github.com/matt-dray/r.oguelike)
`r fontawesome::fa('book')` [rostrum.blog/tags/r.oguelike/](https://www.rostrum.blog/tags/r.oguelike/)
`r fontawesome::fa('globe')` [matt-dray.com](https://www.matt-dray.com)