(Part 2) Top products from r/scala

What else is there? git history, hopefully clean w/consistent branch/merges and commit messages, server logs w/devop notes (esp. heap, maxInline, GC etc params) annotated stacktrace or profiler runs, breakpoints/debug strategy, db schema, net logs, design docs yadda yadda. Not knowing anything else, i would read thru repo's recent and early history, run unit tests, profile/load test it and see how failure prone the server(s) are

You could start with an old repo that has the basic functionality you're interested in, hopefully it's a lot less LoC.

You could read Fowler or Feathers which i remember being good: http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672/

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052/

Breaking away from the Rails (or in my case Django & SQLAlchemy) mindset of the model is both the business model and the persistence model can be hard to do.

However, why not this? -- This might not be good scala, I mostly tool around in it, you'd probably want status as a private attribute:

abstract class TaskStatus()
case class TaskCompleted() extends TaskStatus()
case class TaskPending() extends TaskStatus()

class Task(var status: TaskStatus) {
def isCompleted: Boolean = status match {
case TaskCompleted() => true
case => false
}

def markCompleted(): Unit = status = TaskCompleted()
}

Then Task is a regular object with no ties to a repository or service.

new Task(TaskCompleted()).isCompleted // true
new Task(TaskPending()).isCompleted // false
val t = new Task(TaskPending())
t.isCompleted // false
t.markCompleted()
t.isCompleted // true

This makes Task an entity it has business logic and state that persists from session to session (this other state is probably a title, who its assigned to, and an ID as a persistence allowance, but I've omitted these for brevity).

You can then stuff these tasks into a data store (pick your poison on how you do that) and reconstitute them from that data store -- essentially that's what a repository is: take in some entities, shove them into a data store; take in a query, pull some entities out of the data store.

With that in mind, your TaskService.isTaskCompleted can be a simple wrapper around a repository query that pulls that one task out and does Task#isCompleted on it (note you'll want to guard against unfound Tasks):

class TaskService(val repo: TaskRepo) {
def isTaskComplete(id: Int) {
repo.findId(id).isComplete
}
}


Expanding this out to your TaskAssignments, your task now holds a reference to many TaskAssignments that probably have an isCompleted on them as well. In that case, Task#isCompleted can end up just being `tasks.forAll(.isCompleted).<br /> <br /> Still no reference to a repository. The trick here is thatTaskis now an aggregate. When you ask the repository "Will you find me task 12345?" It not only pulls the literalTask` out of the data store, but also all the parts of the Task as well. So you get the Task and the TaskAssignment objects.

You might want to check out Domain Driven Design which helped cement these sorts of ideas in my head.

If you're having problems with terms like this, please read a basic book on functional programming, like Bird.

Reactive Messaging Patterns with the Actor Model

Fuzzing is subclass of negative testing. It usually involves sending malformed or unexpected inputs at an interface (socket, file parser, etc). It's one of the techniques bad guys use to find buffer overruns and other exploitable defects in software. My favorite book on the subject is this one:

http://www.amazon.com/Fuzzing-Brute-Force-Vulnerability-Discovery/dp/0321446119