How to improve Bank?

[OlofBen]

During the lunch meeting there were some ideas on how the Bank project could be improved. Feel free to post ideas in this issue!

[OlofBen]

One idea is to reduce the amount of given code, and remove some of the mandatory parts (e.g. save to file).

Pros:

• This will (hopefully) remove some confusion over the current design.
• Improve the students ability to structure programs on their own.

Cons:

• It will probably also increase the time each lab assistant needs to help a student, since the programs will differ more.
• Students who are bad at structuring their own code will probably create spaghetti code, making the project harder for students who are already struggling.

[Jocen01]

One idea is to reduce the amount of given code, and remove some of the mandatory parts (e.g. save to file).

Pros:

• This will (hopefully) remove some confusion over the current design.
• Improve the students ability to structure programs on their own.

Cons:

• It will probably also increase the time each lab assistant needs to help a student, since the programs will differ more.
• Students who are bad at structuring their own code will probably create spaghetti code, making the project harder for students who are already struggling.

Argee but if too much is removed it will probably reduce their ability to structure the program in a reasonable way. If there would be an exercise practicing the pattern used in doEvent the student will more easily understand the concept. Then an option would be to remove some of the methods from the Bank and just leave a comment that the student is supposed to add methods and attributes. Then a comment about the user is expected to add a data structure responsible for in and output to file. Here the student needs to create it from scratch covering their ability to structure programs on their own

[valterbergstrand]

Some small and unconneted thoughts of mine:

• I have seen multiple students having 100+ lines of code in doEvent and in their user-input-parser. I would like to add tips to the lab to promote abstraction for smaller and more narrow methods.
• Should we add more explicity in that the students not only are welcome but are nessesary to add and change attributes and methods to classes on their own?

[theolundqvist]

I think that the fundamentals of the project are good enough. Though the given code is definitely unclear about what approach the student should take regarding reading/writing to file. Many students have trouble understanding what the intended approach is.

We should have someone look into the code and see if anything can be done to clear the confusion up.

We could:

1. Look into name changes and small refactors
2. Rethink how the memory is kept in sync with the file

[valterbergstrand]

I feel that the "logging to txtfile"-feature should stay in the lab. Even though it's this property that has caused some problems, I see it as a core challenge to the project, since why shouldn't a bankingsystem keep logs between system starts?

[bjornregnell]

I also think that the save/load-feature is needed to make the app satisfying to implement. We can always provide given code to help fix the hurdles. One confusion seems to be that introprog.io does not offer append. We could implement append by overwrite + extra, or similar.

[theolundqvist]

Many have been confused to as why the old events get a new time when saving to file. (As they rewrite the whole file instead of appending). They are putting Date.now() into the events when they create them from file with doEvent. In that case I have let them change it to doEvent(event: BankEvent, date: Date = Date.now())

[Jocen01]

I think the save/load-feature is good and agree it should stay. One option would be to specify to the user that a class or object which takes care of this is a good idea. I don't think introprog has to have an append feature but let the student implement it themselves. implementing append will be a more natural step once you implement the class/object. At the moment it is common for this responsibility to be split all over the program which makes it harder for the student to realice what happen.

[trilleplay]

I also think that the save/load-feature is needed to make the app satisfying to implement. We can always provide given code to help fix the hurdles. One confusion seems to be that introprog.io does not offer append. We could implement append by overwrite + extra, or similar.

I took the liberty to open https://github.com/lunduniversity/introprog-scalalib/issues/45 and https://github.com/lunduniversity/introprog-scalalib/pull/46 which I believe might address the hurdles you mention. Using the append method may feel more natural in the banks doEvent and make what they want to do more easier to grasp.

[bjornregnell]

Improved appendString and appendLines is now available here: https://github.com/lunduniversity/introprog-scalalib/blob/master/src/test/scala/testIO.scala#L12

TODO: Update compendium, exercises and bank project with info about appendString and appendLines, also explaining how newline is handled.