What, when and where

[VincentVelthuizen]

In previous iterations of a document very much like this we planned to have every chapter correspond to a week. I think it might be time to break from this paradigm.

Instead I think we should have chapters that are setup like a good OO project. High cohesion, low coupling. It should still make sense to go through them in order. This way we can see how far we get every week without there being any 'judgement' from the book.

With regards to the first few chapters I'd suggest roughly the following, despite the remarks earlier I'd expect to cover Chapter 2 in week 1 Chapter 3 in week 2 and Chapter 4 in weeks 3&4.

Chapter 0 - Introduction, why this book, who wrote it, who helped it get better

Chapter 1 - What are computers, what is programming, what is software engineering, what will we teach here? In essence what are we working towards, and how far can you expect to get based on this book/course

Chapter 2 - Getting started Get your development environment setup, write and run your first program, print() basic arithmatic

Chapter 3 - Flow Control functions if-elif-else for

Chapter 4 - Libraries Start using other peoples code

Chapter 5 - Objects

[szirbik]

In chapter 1, we should have links to free access webpages for further reading (what are computers, etc.)

[N-Wouda]

I fear we will start 'losing' people from chapter 4 onwards since that is where @szirbik's jet plane metaphor comes into play.

Shall we create individual issues for these chapters and open them here (and in the project view)? I suggest we copy the tex lay-out/framework from the Java book (if that is okay with you, @VinnieBoySlim).

[lukko]

It might be an idea to have the book hosted on Github Pages (using Jekyll and Markdown)? So you don’t need a physical book in which errors can’t be fixed. Also, students can easily propose new ideas and report errors. Changes are then immediately visible.

[N-Wouda]

@lukko I like the idea of using Github pages, but mostly because I have always wanted to use it sometime. I, however, do not think it is desirable here: there will be quite a view students that will prefer a paper copy, and I feel we should facilitate that.

The advantages you mention can be achieved by letting students open bugs/issues in this repo, and fixing those errors in the code and PDF output. I think we may leave it up to the students themselves to actually print the book - we offer just the PDF, and then always the most recent version.

[VincentVelthuizen]

I have to admit I am not very familiar with GitHub pages. I think we should select a good (free) online course (something along the lines of codecademy for example). And supplement the exercises they do there in this document.

I'm agnostic with regards to the technique used for the document. Needing to learn something new for it does not seem prudent though.

[lukko]

I do indeed see the need for a physical version. However, that could also be achieved by having a single page that lists all the content. Then you can print the page.

And with regards to the learning curve, I believe it is not that hard (https://pages.github.com/ , http://jmcglone.com/guides/github-pages/).

I could play around with it this weekend and see if it is useful/easy to maintain, if this is an option of course 😅.

[szirbik]

I have the feeling that we focus too much on form and less on content. There are plenty of websites, quite useful to start with, like www.learnpython.org, for example. We should not make this "python book" a means in itself, but a means to an end.

[VincentVelthuizen]

We have decided to base the course and the course document on the python course offered by codecademy (https://www.codecademy.com/learn/learn-python). The document will be written in LaTeX and principally distributed as PDF.

I think that closes this topic, at least for now.