blouerat

import java.util.regex.Pattern

def convert(in: String, delimiter: String) = in.split(Pattern.quote(delimiter)).toList.map(str => str.head.toUpper+str.tail).mkString(delimiter)
def convert(in: String):String = convert(in, "\n")

// Test with delimiter & without
println(convert("bli\nbla\nblu"))
println(convert("bli$bla$blu", "$"))

blouerat

/*
Based on the second part of the talk "Dead-Simple Dependency Injection in Scala" by @runarorama at NEScala 2012
http://marakana.com/s/dependency_injection_in_scala,1108/index.html
*/

sealed trait KVS[A]
case class Put[A](key: String, value: String, a: A) extends KVS[A]
case class Get[A](key: String, h: String => A) extends KVS[A]
case class Delete[A](key: String, a: A) extends KVS[A]

blouerat

/*
Based on the first part of the talk "Dead-Simple Dependency Injection in Scala" by @runarorama at NEScala 2012
http://marakana.com/s/dependency_injection_in_scala,1108/index.html
*/

class Connection {
  def prepareStatement(query: String) = new Statement()
}

class Statement {

blouerat

Understanding Functional IO in Scala

A bunch of interesting links to understand Functional IO in Scala from scratch.

John A. De Goes at NEScala2012:

"IO is the trickiest of operations to tackle in a functional way. Try to make IO efficient, non-leaky, composable, and pure, and the problem becomes virtually unsolvable. In this talk, John A. De Goes, CTO of ReportGrid, discusses three different approaches to functional IO in Scala, beginning with iteratees, and continuing on to stream processors and transducers."

blouerat

Ceux qui codent en C/C++, Objective-C, Java, Pascal ou Ada mettent en avant le typage fort.

On va surtout mettre en avant le typage statique. Les termes typage "fort" et "faible" sont loins d'être clairement définis anyway. Un type-checking strict ne doit pas rendre le code illisible. Par exemple, on pourrait aujourd'hui écrire un typesystem qui empêche d'accéder à des cases hors des limites d'un tableau mais toutes les solutions rendent le code illisible pour le moment. Donc typesafety, oui, mais dans les limites du raisonnable.

Même en n’étant pas forcément complètement d’accord, je dois reconnaître que le risque de bugs diminue quand une variable doit être déclarée avant d’être utilisée, et qu’elle ne peut contenir que des données d’un type défini.

Le typesystem t'apporte une preuve "for all" quand un test t'apporte une preuve "for one". Dijkstra a dit : "Program testing can be used to show the presence of bugs, but never to show their absence." Le risque de bug diminue effectivement. D'autant qu'un

blouerat

package controllers

import play.api._
import play.api.mvc._

object Application extends Controller {
  
  def index = Action { request =>
    Ok(views.html.index(request))
  }

blouerat

package oop;

public class OOP {
    
    public static void main(String[] args) {
        Pants pants = new Pants("dark blue");
        System.out.println("I have a pair of " + pants.getColour() + " pants!");
        pants.setColour("vermilion");
        System.out.println("Now my pants are " + pants.getColour() + ", and it's much better!");
    }

blouerat

with a new array: 10
with a new array and new value: 10
with a new value: 42

blouerat

reverseMap :: [a -> b] -> a -> [b]
reverseMap = sequence

blouerat

package java8fun;

public class Foobar {

    private String foo;
    private Integer bar;

    public Foobar(String foo, Integer bar) {
        this.foo = foo;
        this.bar = bar;