First exercise that uses it is showEveryNthPerson

Should we remove validPerson from ExceptionExercises?

 def createValidPeople: List[Person] = ???

and just use:

def createValidPeople2: List[Person] = ???

We are trying to demonstrate that you have to use hacks when you use Exceptions as values.

This will simplify things for people.

In reality I would use NonEmptyList.from(list) and then reduce on the NEL.

But here people have to fold on the tail and it feels so odd.

Maybe we can rewrite this into an exercise where we concatenate a bunch of strings together?

Or to reverse a list?

I think zipping isn't very important in this course. If we de-prioritise it (put it in the bonus section), we can bump getNames, getAdults and reverseList, which are exercises to rewrite imperative code in a functional way. I ran this recently and found that it was valuable.

Or we could introduce collect here to prepare students for Exception and Either exercises.

curriedAdd in IntroExercises may not be very useful because we don't use currying later on.

Feels like a distraction.

~testOnly *TryExercisesTest -- -C fundamentals.SimpleReporter

Consider using immutable docker image reference to ensure better security and stability.

In this case, it can be:
hseeberger/scala-sbt@sha256:83a79dfd0989f1e8404a9731673457139b6d9fceff2fdf7a3e27c3e17d5eb4d6

I think we can explore more of the language in day 1, because day 1 is a little short.

Will help in simplifying type signatures of collections

Depends on Delight and ScalaTest to be upgraded first

I think we need to add at least 1 hard exercise to Types and List.

Some things we could consider adding:

• Tuples (Intro)
• Creating your own case class (Types)

• Add FP concepts into cheat sheet such as Functor and Monad (or create a separate cheat sheet)

This is needed to explain foldLeft

• sequence
• traverse

I think we could add these to end of Day 1

For the createPerson function the assertions need to be fixed for the tests:

• "should return Person if supplied a valid name and age"
  The test should assert Person("Fred", 32)

• "should throw an EmptyNameException if the name supplied is empty"
  The test should assert "provided name is empty"

• "should throw an InvalidAgeValueException if the age supplied is not an Int"
  The test should assert InvalidAgeValueException is thrown instead of InvalidAgeRangeException

Adding a Flashing with a frequency to TypeExercises makes this a little too complex as:

• We need to explain Regex matching or
• Explain splitting and matching on Array.

If we get rid of the frequency this exercise will be much easier and we can easily demonstrate the compile-checked exhaustiveness.

  /**
    * We have a new traffic light called Flashing, with a frequency, e.g. "flashing 20", "flashing 100"
    *
    * Extend `showTrafficLightStr` that you have just implemented above to support this new functionality.
    *
    * Use a test driven approach to implement this new functionality.
    *
    * scala> showTrafficLightStr("flashing 20")
    * = "The traffic light is flashing with a frequency of 20"
    *
    * scala> showTrafficLightStr("flashing 100")
    * = "The traffic light is flashing with a frequency of 100"
    *
    * Hint: Use flashing regex and pattern matching or 
    * use `.split(" ")` and pattern-match on `Array("flashing", frequency)`
    **/

  val flashing = """^flashing\s(\d+)$""".r

This will make it easier to run tests and see the progression better.

In LogParser so getErrors can be reused in showErrorsOverSeverity.

This:

  /**
    * scala> mkTrafficLightThenShow("red")
    * = "Traffic light is red"
    *
    * scala> mkTrafficLightThenShow("bob")
    * = "Traffic light `bob` is invalid"
    *
    * Hint: Use `mkTrafficLight` and pattern matching.
    *
    * You can pattern match on `Option` using its two constructors `Some` and `None`:
    *
    * ```
    * optSomething match {
    *   case Some(a) => // do something with `a`
    *   case None => // do something else
    * }
    * ```
    */
  def mkTrafficLightThenShow(str: String): String = ???

should change to:

  /**
    * scala> mkTrafficLightThenShow("red")
    * = "Traffic light is red"
    *
    * scala> mkTrafficLightThenShow("yellow")
    * = "Traffic light is yellow"
    *
    * scala> mkTrafficLightThenShow("green")
    * = "Traffic light is green"
    *
    * scala> mkTrafficLightThenShow("bob")
    * = "Traffic light `bob` is invalid"
    *
    * Hint: Use `mkTrafficLight` and pattern matching.
    *
    * You can pattern match on `Option` using its two constructors `Some` and `None`:
    *
    * ```
    * optSomething match {
    *   case Some(a) => // do something with `a`
    *   case None => // do something else
    * }
    * ```
    */
  def mkTrafficLightThenShow(str: String): String = ???

  /**
    * scala> mkTrafficLight("red")
    * = Some(Red)
    *
    * scala> mkTrafficLight("bob")
    * = None
    **/
  def mkTrafficLight(str: String): Option[TrafficLight] = ???

should also have:

  /**
    * scala> mkTrafficLight("red")
    * = Some(Red)
    *
    * scala> mkTrafficLight("green")
    * = Some(Green)
    *
    * scala> mkTrafficLight("yellow")
    * = Some(Yellow)
    *
    * scala> mkTrafficLight("bob")
    * = None
    **/
  def mkTrafficLight(str: String): Option[TrafficLight] = ???

The current implementation of:

def min(nums: List[Int]): Int

uses a INT.MInValue as default.

I guess this is because we haven't covered Option yet?

We cover most of what Wallet does in TypeExercises with Person. Do we need to double up?

 //Type -> String
  def showWallet(wallet: Wallet): String = ???

is the same as:

def showPerson1(person: Person): String 
def showPerson2(person: Person): String 

 //immutable copy
  def purchase(cost: Double, wallet: Wallet): Wallet = ???

is the same as:

 def changeName(newName: String, person: Person): Person = ???

• list.drop
• list.take
• list.last
• list.reverse
• Range

• For simplicity, let's allow changing to an empty name, like:

Change this like we did for Options.

should we introduce flatMap on findJobIdByHumanId.

At this point people understand what an Option type is and how/when to use it. findJobIdByHumanId is a very good example of how you combine two Options. The IDE suggest that you should use flatMap instead of map.flatten.

The next exercise findJobByHumanId has the same intuition. We could introduce it here to show the difference.

Possibly confusing and distracting?

Currently people can do .copy(newName) and it'll just work because name is the first param.

I think getAge should not allow 0.

If it does, then createValidPeople returns Arturo as well, which violates the test.

It would be useful to have the presenters names against their scheduled items.

I think I can complete the Exceptions2EitherExercises in 45 mins similar to the ExceptionsExercises. The content of Exceptions2EitherExercises is very similar to ExceptionsExercises so there is much less overhead in going from one to the other - only translating Exceptions -> Eithers.

This should free up 30 mins which we can use somewhere else; maybe on the
TryExercises or LogParser?

The for-comp exercise needs to be added to the README.

Remove mkTrafficLightOrNull exercises from NullExercises:

def mkTrafficLightOrNull(str: String): TrafficLight = ???
def mkTrafficLightOrNullThenShow(str: String): String = ???

as these are covered by the Person exercises:

def mkPersonOrNull(name: String, age: Int): Person = ???
def mkPersonOrNullThenChangeName(oldName: String, age: Int, newName: String): Person = ???

Add a sortBy exercise and test for List. This will be needed in the LogParser exercise.

To support the extension of TyperExercises.showTrafficLightStr:

We have a new traffic light called Flashing, with a frequency, e.g. "flashing 20", "flashing 100"

Extend showTrafficLightStr that you have just implemented above to support this new functionality.

should we mention:

Hint: String.split and pattern match on Array

or were you thinking of introducing regexs here?

"""flashing\s\(d+)""".r

Add instructions for:

1. Intellij
2. Any text editor