Today’s post is going to be a tip on creating a project structure for your Scala projects that is SBT ready. There’s no real magic to it, just a specific structure that you can easily bundle up into a console application.
The shell script
To kick start your project, you can simple use the following shell script:
#!/bin/zshmkdir$1cd$1mkdir-p src/{main,test}/{java,resources,scala}mkdir lib project target
echo'name := "$1"
version := "1.0"
scalaVersion := "2.10.0"'> build.sbt
cd ..
This will give you everything that you need to get up an running. You’ll now have a structure like the following to work with:
Sometimes, it makes sense to have multiple SSH identites. This can certainly be the case if you’re doing work with your own personal accounts, vs. doing work for your job. You’re not going to want to use your work account for your personal stuff.
In today’s post, I’m going to run through the few steps that you need to take in order to manage multiple SSH identities.
Different identities
First up, we generate two different identities:
ssh-keygen -t rsa -C"user@work.com"
When asked, make sure you give the file a unique name:
Enter file in which to save the key (/home/michael/.ssh/id_rsa): ~/.ssh/id_rsa_work
Now, we create the identity for home.
ssh-keygen -t rsa -C"user@home.com"
Again, set the file name so they don’t collide:
Enter file in which to save the key (/home/michael/.ssh/id_rsa): ~/.ssh/id_rsa_home
The wikipedia article for Futures and promises opens up with this paragraph, which I thought is the perfect definition:
In computer science, future, promise, delay, and deferred refer to constructs used for synchronizing program execution in some concurrent programming languages. They describe an object that acts as a proxy for a result that is initially unknown, usually because the computation of its value is yet incomplete.
In today’s article, I’ll walk you through the creation and management of the future and promise construct in the Scala language.
Execution context
Before continuing with the article, we need to make a special note about the ExecutionContext. Futures and promises both use the execution context to perform the execution of their computations.
Any of the operations that you’ll write out to start a computation requires an ExecutionContext as a parameter. These can be passed implicitly, so it’ll be a regular occurrence where you’ll see the following definition:
// define the implicit yourselfimplicitvalec:ExecutionContext=ExecutionContext.global// or - import one already definedimportExecutionContext.Implicits.global
ExecutionContext.global is an ExecutionContext that is backed by a ForkJoinPool.
Futures
We create a Future in the following ways:
/* Create a future that relies on some work being done
and that emits its value */valgetName=Future{// simulate some work hereThread.sleep(100)"John"}/* Create an already resolved future; no need to wait
on the result of this one */valalreadyGotName=Future.successful("James")/* Create an already rejected future */valbadNews=Future.failed(newException("Something went wrong"))
With a future, you set some code in place to handle both the success and fail cases. You use the onComplete function to accomplish this:
Using a for-comprehension or map/flatMap, you can perform functional composition on your Future so that adds something extra through the pipeline. In this case, we’re going to prefix the name with a message should it start with the letter “J”:
If you really need to, you can make your future block.
valblockedForThisName=Future{blocking{"Simon"}}
Promises
The different between a Future and a Promise is that a future can be thought of as a read-only container. A promise is a single-assignment container that is used to complete a future.
Here’s an example.
valgetNameFuture=Future{"Tom"}valgetNamePromise=Promise[String]()getNamePromisecompleteWithgetNameFuturegetNamePromise.future.onComplete{caseSuccess(name)=>println(s"Got the name: $name")caseFailure(e)=>e.printStackTrace()}
getNamePromise has a future that we access through the future member. We treat it as usual with onComplete. It knows that it needs to resolve because of the completeWith call, were we’re telling getNamePromise to finish the getNameFuture future.
In today’s post, I’ll go through a primer of the different facilities that you can use.
Functional Interfaces
Single abstract method interfaces have been taken a step further in Java 8, where the programmer is able to decorate their interface using a @FunctionalInterface annotation. These can then be represented as lambda expressions and method references. These are building blocks for functional programming.
Consumer<T>
Represents an operation that accepts a single input argument and returns no result. Unlike most other functional interfaces, Consumer is expected to operate via side-effects.