Because sbt-typescript uses the standard tsconfig.json file for configuration it is possible to compile using both sbt-typescript and tsc.
I use this mostly to have my IDE (IntelliJ) signal type errors early while I'm typing.
To do that I only have to check 'enable typescript compiler' and 'use tsconfig.json'.
Similarly you can run tsc -p -w from the commandline.
The only downside is that you need to copy the right npm dependencies to node_modules from the directory in target/web/node_modules
| public Mono<Void> gitterSlackRelay() { | |
| ObjectMapper mapper = new ObjectMapper(); | |
| return create() | |
| .get(gitterStreamUrl, gitterStreamHandler()) | |
| .flatMap(replies -> replies | |
| .receiveByteArray() | |
| .filter(b -> b.length > 2) // ignore gitter keep-alives (\r) | |
| .map(b -> { | |
| try { | |
| return mapper.readValue(b, Map.class); |
| Installeer de volgende tools als je die nog niet hebt: | |
| - java 8 | |
| - [sbt](http://www.scala-sbt.org/download.html) | |
| - Docker Machine | |
| - je kunt prima met een teksteditor werken zoals sublime of atom. Als je liever met een IDE werkt: installeer Scala IDE (variant van Eclipse) of IntelliJ (Community werkt ook) met de Scala plugin. | |
| Maak een github account aan als je die nog niet hebt en stuur de handle naar mijn email. Dan voeg ik je toe aan onze repo. |
The example of John de Goes' Haskell's Type Classes: We Can Do Better written in Scala.
It is precisely to allow for multiple type class implementations that Scala uses implicits to implement them. So I thought it would be interesting to compare Scala and Haskell here.
Discussion on HN
object MonoidInt{
implicit val MonoidPlus = new Monoid[Int] {
def empty = 0
def append(v1: Int, v2: Int) = v1 + v2
}This Gist is related to the article The Rough Experience with Slick which points out performance problems with a Slick DSL query with 3 joins. The article is discussed on Linkedin and in the Slick newsgroup
I've tried this query on Slick 3.0M1 for Postgresql.
The query that uses the join DSL expression
val salesQuery = {
val salesJoin = sales join purchasers join products join suppliers on {
case (((sale, purchaser), product), supplier) =>
sale.productId === product.id &&
sale.purchaserId === purchaser.id &&| scalaVersion := "2.11.4" | |
| libraryDependencies += "org.scala-lang" % "scalap" % scalaVersion.value | |
| InputKey[Unit]("scalap") := { | |
| import complete.DefaultParsers._ | |
| val classes = spaceDelimited("<class names>").parsed | |
| val pathSeparator = java.lang.System.getProperty("path.separator") | |
| val classpath = "-classpath" :: (fullClasspath in Compile).value.map(_.data).mkString(pathSeparator) :: Nil | |
| val args = "-verbose" :: classpath ::: classes.toList |
| @echo off | |
| set MY_JAVA_HOME=D:\devtools\jdk1.8.0_25 | |
| set SYMLINK_PATH=C:\ProgramData\Oracle\Java\javapath | |
| set JAVA_VERSION=1.8 | |
| rem set environment variable for user | |
| setx JAVA_HOME %MY_JAVA_HOME% | |
| rem change default java version in registry | |
| REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment" /v "CurrentVersion" /t REG_SZ /d %JAVA_VERSION% /f |
git config --global credential.helper wincred
I've been thinking about the way Haskell picks out an implementation of a function that's defined on a type. F.i. the way the type of mappend is defined on the type Monoid. But the implementation is defined on an instance of Monoid. So when we use mappend the implementation is found by looking up the implementation of the runtime type of the Monoid.
glueTwice:: Monoid m => m -> m
glueTwice m = m `mappend` m
glueTwice "bla" -- uses mappend implementation of ListThis seems very much like the key point of OO: the Liskov substitution principle and like having an interface Monoid that's implemented by String.
So what's different between OO and these functions defined on types and implemented on instances?
A lot of explanations of monads start from a mathematical terminology. Which is unnecesarily obscure if you just want understand why they're handy in programming.
If you have a background in OO you can see Monad as an interface. Similarly Monoid can also be viewed as an interface. Gilad Bracha said that something that supports a function like mappend should really be called Addable (instead of Semi-group). Because that's what we can do with it. And if it also supports a function like mempty it should be called Foldable (instead of Monoid); because it provides the two arguments that a fold function requires.
Following the same naming convention the name Chainable would be more intuïtive than Monad. Because the reason that we value bind (or flatMap) so much is that we can chain (or 'compose) smaller parts into bigger parts and automatically handle alternate flows or side effects.
Because that's why Chainables (or Monads) are a big deal: we can build bigger things from flatmap invocations; you can cha