We should remove the licensed font and replace it by open source icon set.

We need a set of exercises about Shapeless so we can show it on our Presentation Demo in TypeLevel Summit.

Having a set of 5 exercises is fair enough for the demo, we'll add more exercises in the future.

We should propose a usable view to deal with other kind of exercises, for instance with textareas to insert code to be evaluated.

The actual list of sections defined at the content module should be shown at the home screen.

The solution for this koan is coded in the .json like this: "assert(List() === Nil)"
When it simply should be: "Nil"

We need to add a license text to all our files.

@raulraja, a couple of questions to answer before considering it ready to work on:

• What's the text? Do we have a template? What kind of license are we going to set?
• Are we going to add it as a footer or as a header?

We need to use Github API to get all contributors for each category so we can show them properly on each category page.

We need to have a README file where we explain how to compile/build the project.
Bear in mind that we will change master with our current V2 branch, so our current README file will be out of date.

We should create new GitHub application with the 47 account, in order to have more appropriate app_id/secret in the production environment.

Also we should define a properly Authorization callback URL in order to enable oAuth in production.

Extra: This should be created here

We should start working on create the library Cats, organize its sections and add some exercises.

It would be interesting having Codacy reviews in our pull request.

Free algebras will have both Production and test interpreters. Prod interpreters lift the Free monads/aplicatives to an effect capturing monad such as scalaz.concurrent.Task whereas test interpreters will mock persistence, etc... and use cats.Id when lifting the algebras.

We should be able to:

• Save/Update the progress: userId, library, section, method, args, state (succeeded/failed) and date
• Given an userId, library, section, retrieve all the methods and their args (also the state could be useful).
• Given an userId and a library, retrieve the percentage of exercises completed.

The URL path for exercises is under GET /:librayName/, since the library name is matched to an arbitrary string on the first fragment of the URL it acts like a wildcard for URLs that don't match previous routes.

When coercing user-submitted inputs to boolean (for example in the "Literal Booleans" exercise), strings that are converted to boolean will be false by default unless they are the text "true". Coercing a string to a boolean should ensure that the input is either "true" or "false" and fail otherwise.

This means that the inputs that are expected to be false will be considered as good even when containing bogus strings that aren't "true".

• Including Libraries
• Ad-hoc exercises

Exercises that require longer code blocks should be allowed.
For example when showing how to implement typeclasses a koan style approach may not be appropriate and the user should be able to provide a longer code style impl.

After a successful login, a reloading should occur.

Add codecov.io to all repos currently part of Scala Exercises.
See the non/cats project as an example on how it is integrated with their PRs

Since we aren't using Slick and its integration with Play anymore but we are using Doobie instead, evolutions are not run automatically. @juanpedromoreno suggests using Flyway for managing DB schema evolution.

The order doesn't make sense. For example: Classes, then Option, then Objects?

Exercises should be able to include simple placeholders such as:

/** <code>var</code> parameters in class definition define getter and setter:
    *
    * ###Something to set where the description ends and where the explanation starts.###
    *
    * You can define class with private fields:
    *
    * {{{
    * class ClassWithPrivateFields(name: String)
    * val aClass = new ClassWithPrivateFields(\"name\")
    * }}}
    *
    * NOTE: <code>aClass.name</code> is not accessible
    */
  def classWithVarParameter(res0: String, res1: String): ExerciseResult[Unit] = ExerciseRunner("Class With Var Parameter") {

    class ClassWithVarParameter(var description: String)

    val aClass = new ClassWithVarParameter("Flying character")
    aClass.description should be(res0)

    aClass.description = "Flying white character"
    aClass.description should be(res1)
  }(∞)

Evaluate if resX convention is the best approach.

The exercise "Map values can be iterated" (http://scala-exercises.47deg.com/koans#maps) is a little misleading, because it relies on the example values coincidentally coming out in the same order that they were put in.

In general, this is not true for Maps since they are unordered.

We need a new application in heroku like that: https://scala-exercises.herokuapp.com/

http://scala-exercises.47deg.com/koans#implicits

The required answer to: add(3, 6) should be(__) is: Int2BigIntegerConvert(9)

which returns a new BigInteger. Therefore new BigInteger("9") would be a valid and more obvious answer.

http://scala-exercises.47deg.com/koans#iterables says that "sameElements will return true if the two iterables have the same number of elements"

That's a necessary, but not sufficient condition. The elements have to be the same, too. Whether the ordering matters depends on the collection:

scala> List(1,2,3) sameElements List(1,2,3)
res13: Boolean = true

scala> List(1,2,3) sameElements List(3,2,1)
res14: Boolean = false

scala> Set(1,2,3) sameElements Set(3,2,1)
res15: Boolean = false // WHAT?

scala> Set(1,2,3,4,5,6) sameElements Set(6,5,4,3,2,1)
res16: Boolean = true

Also, sameElements for Set produces unexpected results - the behaviour changes depending on the size of the Set, as you can see above! This is arguably a bug in the Scala library: https://groups.google.com/forum/#!topic/scala-debate/je4vZbR3WbA

Integrate Doobie in the persistence layer:

@franciscodr 's approach could be interesting: https://github.com/47deg/nine-cards-backend/blob/paco-9c-314-backend-create-generic-persistence-class/modules%2Fservices%2Fsrc%2Fmain%2Fscala%2Fcom%2Ffortysevendeg%2Fninecards%2Fservices%2Fpersistence%2FPersistenceImpl.scala

Some exercises have and convenient explanation after the code, that are taken from a 'scalaDoc` within the code. I think that we should move the explanation to the same scaladoc of description, something like that:

From:

  /** <code>var</code> parameters in class definition define getter and setter:
    */
  def classWithVarParameter(res0: String, res1: String): ExerciseResult[Unit] = ExerciseRunner("Class With Var Parameter") {

    class ClassWithVarParameter(var description: String)

    val aClass = new ClassWithVarParameter("Flying character")
    aClass.description should be(res0)

    aClass.description = "Flying white character"
    aClass.description should be(res1)

    /** You can define class with private fields:
      *
      * {{{
      * class ClassWithPrivateFields(name: String)
      * val aClass = new ClassWithPrivateFields(\"name\")
      * }}}
      *
      * NOTE: <code>aClass.name</code> is not accessible
      */
  }(∞)

To:

  /** <code>var</code> parameters in class definition define getter and setter:
    *
    * ###Something to set where the description ends and where the explanation starts.###
    *
    * You can define class with private fields:
    *
    * {{{
    * class ClassWithPrivateFields(name: String)
    * val aClass = new ClassWithPrivateFields(\"name\")
    * }}}
    *
    * NOTE: <code>aClass.name</code> is not accessible
    */
  def classWithVarParameter(res0: String, res1: String): ExerciseResult[Unit] = ExerciseRunner("Class With Var Parameter") {

    class ClassWithVarParameter(var description: String)

    val aClass = new ClassWithVarParameter("Flying character")
    aClass.description should be(res0)

    aClass.description = "Flying white character"
    aClass.description should be(res1)
  }(∞)

Exercises are showing up without proper indentation. Indentation of all exercises even those provided by third parties should be automatically formatted with something like scalariform to provide users with a consistent experience.

We'll need a list of the software requirements of the Play application in order to provision the servers.

• All inputs have been filled
• The exercise hasn't been already solved
• The exercise is not currently being evaluated

Create:

• Followup Model
• Followup Store
• Evolution to create Followup table
• Followup Service
• Followup Controller
• Followup Routes

We should have at last some full sections of stdlib

Email and Name are optional values that can be empty. We should reflect that in our User model.

We should make sure we are using the latest and greatest versions of both of these libraries. IMHO-- we should ideally just use one or the other-- and it seems we're migrating towards Cats.

At the very least, I'd like to adjust the builds so that Scalaz and Cats versions are shared across both core and site. Maybe common dependencies/versions should be defined in common/BuildCommon.scala or common/Dependencies.scala?

Thoughts?

Enhance the test cases that show how method code extraction should work. Then we can more easily seek help for the best way to fully identify the block of code that belongs to a given tree.

Remote libraries containing exercises should be able to be loaded and parsed.

We need to add a reference to the code of conduct we are going to join. It should be referenced at README file.
We are going to follow the TypeLevel Code of Conduct: http://typelevel.org/conduct

The current Github integration and login came from an example which is far from clean. We need to integrate the login ops as its own algebra in the context Free as we have done with other Biz logic ops.

We are getting strange sbt exceptions on Travis CI that cause the process to exit with a non-zero status code and fail the build. As it can be seen in this build even when the tests are passing failure is caused by an sbt issue with the following stacktrace:

Exception in thread "Thread-21" java.net.SocketException: Connection reset
    at java.net.SocketInputStream.read(SocketInputStream.java:189)
    at java.net.SocketInputStream.read(SocketInputStream.java:121)
    at java.net.SocketInputStream.read(SocketInputStream.java:203)
    at java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2296)
    at java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:2589)
    at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2599)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1319)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
    at sbt.React.react(ForkTests.scala:114)
    at sbt.ForkTests$$anonfun$mainTestTask$1$Acceptor$2$.run(ForkTests.scala:74)
    at java.lang.Thread.run(Thread.java:745)

Placeholder to track parsing, evaluation and discovery of exercises in the Classpath