docker login [OPTIONS] [SERVER]

aws-docker
  ├── Dockerfile
  └── java-webapp-0.0.1-SNAPSHOT.jar

Bash 环境

多数时候我们用的是 Bash, 比如个人的 Linux 不愿去定制，远程服务器的由不得你去定制，所以就从 Bash 说起。

默认键绑定 emacs, 操作是 ctrl-x, ctrl-e

在默认的 Bash  环境下，只要在命令行中按下 ctrl-x, ctrl-e 就会把当前命令的内容调入到环境变量  $EDITOR 指示的编辑器(默认为 emacs)去编辑，编辑后保存退出就会立即执行。

如果未安装 Emacs 编辑器，在按下 ctrl-x, ctrl-e 会得到如下提示

[vagrant@localhost ~]$
-bash: emacs: command not found

如果希望使用 vi 来编辑当前命令，就需要设置 EDITOR 环境变量，比如在 .bashrc 中加入

export EDITOR=vi

那么在命令行中按下 ctrl-x, ctrl-e 使用打开  vi 来编辑当前命令。

注：Emacs 要用 ctrl-x, ctrl-c, 再回答 y, 命令保存到临时文中; 而 vi 的相应操作是 :wq, 至少这个操作上 vi 要简洁些。 Read More

Java 世界里进行并发编程有 Future 和  ExecutorService(当成 ThreadPool 来对待)，及至 Java 8 引入了更为趁手的 CompletableFuture。那么使用 Scala 该如何进行并发编程呢？Scala 能毫无障碍的使用 Java 类库，所以完全可以用 Java 的 API 来使用线程池，只是那不太 Scala 罢了。

既然是 Scala, 就尽量写成 Scala Style 吧，Scala 也有自己的 Future, 还有 Promise 呢? 至于 Promise 与 Future 多大区别，语义上似乎也差不多，只看到 Promise 中有一个 Future 的属性。如果想玩得高级一点的话就该把  Actor 弄起来，它算是所谓的纤程，多个  Actor 可跑在同一个线程中，当然启动要快，内存消耗少，还避免了上下文切换。

这里还是先体验 Scala Future 的用法。Future 本身只是描述了一个任务，及将要获得的结果(或执行的动作)，因此那样一个任务也是要放到线程池中去执行。这和 Java 的 Future/ThreadPool 是一样的概念。稍有不同的是线程池的创建与使用，线程池的默认大小配置等。看个简单的应用示例，本次测试的 Scala 版本是 2.11.12，为了突出实际的线程池大小，我们把任务数设置为 20 个

Scala Future 并发编程体验

探索是否能以流式写数据到 S3

通常，在我们项目中用 Java 代码上传数据到 S3 是下面那样的操作

AmazonS3 s3Client = AmazonS3ClientBuilder.defaultClient();

s3Client.putObject("bucket_name", "s3key.txt", new ByteArrayInputStream("hello".getBytes()), new ObjectMetadata()); //ObjectMetadata 没什么特别的话可以为 null

虽然  putObject() 的第三个参数是一个流，但它是输入流, 并非输出流啊。也就是说在执行该方法时必须把所有待上传的上据全部准备在这个输入流中，所以这里就直接用一个 ByteArrayInputStream 来包裹需上入到 S3 的数据内容。

当然 putObject() 也就无法像 FileObjectOutputStream 那样流式写入内容到文件中，因为 putObject() 前后都没有与 bucket 上那个文件上有联系。即使是用 PipedInputStream/PipedOutputStream  也不行, 比如说下面的代码 Read More

上一次关注 Scala 新版本特性还是在将近五年前，针对的是  Scala 2.10. 后来也一直在使用 Scala，基本上是 Scala 2.11， 但对 Scala 2.11 所带来的新特性基本无知，大约有个 Macro 功能，没什么机会用上，应用 sbt 时稍有接触。还是老句老话， 了解新特性最可靠的文档是每个版本的的 Release Notes, 比如 Scala 2.12.0 Release Notes.

其中 Scala 2.12 带来的主要特性在于对 Java 8 的充分支持：

1. Scala 可以有方法实现的 trait 直接编译为带默认方法的 Java 接口
2. Lambda 表达式无需生成相应的类，而是用到 invokedynamic 字节码指令(这个是 Java 7 加进来的新指令)
3. 最方便的功能莫过于终于支持 Java  8 风格的 Lambda，即功能性接口的 SAM(Single Abstract Method)

Scala 的 Lambda 内部实现

这儿主要是体验 Scala 2.12 如何使用 Java 8 风格的 Lambda. 在 Scala 2.12 之前，Scala 对 Lambda 的支持是为你准备了一大堆的 trait 类，有

1. Function0, Function1, ...... Function22 (接收多个参数，返回一个值)
2. Product1, Product2, ...... Product22 (函数返回多个值，即 TupleX 时用的)

第一次用  spark-submit 提交任务，是 Scala 的程序，命令格式是

spark-submit --class <main-class> --master local[*] --name "My first Spark Job" spark-test-fat-1.0-SNAPSHOT.jar

结果报出错误

Exception in thread "main" java.lang.SecurityException: Invalid signature file digest for Manifest main attributes
at sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:330)
at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:263)
at java.util.jar.JarVerifier.processEntry(JarVerifier.java:318)
......
at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:119)
at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala)

Google 查了下，是需要把 jar 文件中的 META-INF/*.RSA META-INF/*.DSA META-INF/*.SF 文件清理掉。我们可以执行如下命令从现有的 jar 中除去

zip -d <jar file name>.jar META-INF/*.RSA META-INF/*.DSA META-INF/*.SF

是因为 jar 包中包含有这些文件才造成提交 Spark 时验证文件签名摘要时失败。 Read More