不可变性(Immutable--不是不让谁变性) 在设计模式中似乎不那么显眼，但是它在函数式编程却起着举足轻重的意义了。我们都知道 Java 的 String 是设计为 Immutable 的，对 String 改变都会产生新的 String 实例，这有助于共享常量池中字符串与并发。
这里再回顾上一篇关于纯虚函数(输入决定输出，无副作用函数，非 C++ 中可重载无 Body 的函数)，由此可知，Immutable 也有助于实现纯虚函数，因为一个不可变实例被传入到某个函数中，该实例的内部状态是无法被修改的，也就是说该函数是无副作用的。
先来感受一下可变类型在并发环境下的一个弊端，看个例子，可变的 Customer 类有三个属性 name, email 和 age, 它还有一个更新方法 updateNameAndEmail() 阅读全文 >>
函数式编程第二式，纯函数 (Pure Functions). 何谓纯函数，纯函数就是数据库的函数一样没有副作用，不修改对象的内部状态，或者说只进行计算。给定什么输入，永远得到相同的输出，即输出只依赖于输入。
纯函数有什么好处呢？极其容易测试，只需要给定一组输入，对输出进行断言。如果是带副作用的方法，它修改了某个私有的属性，很难进行状态判定。
Scala 基于统一访问原则，属性与方法不需要那么明晰，所以属性与方法名是不能重名的。它对有无副作用存在这么一个约定：
空括号方法 (empty-paren method), 如 def width() {...} 它是有副作的。这样调用 obj.width()
无参方法 (parameterless method), 如 def width {...}, 它是无副作的。这样调用 obj.width, 这和使用属性一致形式
Java 也有类似的约定，get 开头的或 getter 方法往往是无副作用的。要是有人偏偏在 getName() 方法里修改了对像的属性而引入了 Bug，那只会让人唏嘘不已。
方法的副作用一般有哪些呢？
本人正在阅读 《Becoming Functional》这本书，且对 Scala 的使用经验已有数年，所以品读的同时更是对头脑中函数编程的概念进行重新整理。函数编程并非一定要诸多语言特性的支持，它是一种不同的思维方式；比如说我们公司项目如今还是用的 Java 7，但我们一直以函数式思维来书写我们的代码。我们正在从 Java 7 升级到 Java 8，待到 Java 8 时代码行文肯定要比现在简练的多，但函数式编程思维未变。
下面是函数式编程基本概念
《Becoming Functional》逐章对上面七大概念进行讲解.
First-class functions: 函数是第一类型 阅读全文 >>
今天才发现 Jackson 其实是支持 Json-Path 的，但以前一直不知道，关键是 Jackson 的文档也没见提到。所以很久以前是自己给 Jackson 写了一个简陋的 Json-Path 支持类，这个是为测试代码用的，所以基本够用。想要更全面的功能可使用 https://github.com/jayway/JsonPath 这个项目。对于 Jackson 中如何使用 Json-Path, 我还会进一步研究下。
我写的 RichJsonNode 类是一个 Scala 版本，最早也写过一个 Java 版本，还有一个基于 GSON 的 Java 版本的。这里只贴出 Scala 版源码。支持的基本方法及语法如下：
a/b, a/b[2], a/b[1]/c, a[1]/b, $[0]
selectNode(path), selectString(path), selectInt(path), selectDouble(path), selectBollean(path), hasField(path) 和 arrayLength(path)
源码如下： 阅读全文 >>
几年前整理过一篇 JUnit 4 如何正确测试异常，类似的问题：如何在 Scala 中测试异常呢？因 Scala 可以完全采用 JUnit 测试用例的风格，所以当然可以运用 Java 的三种方式来测试异常，即
回到 Scala 中来，我并不那么情愿在 Scala 中使用 JUnit 的 @Test def testMethod() 这样的测试方法风格，而多少采用 BDD 或者叫更 DSL 的风格。
那看看我们 Scala 有些什么独到的异常测试方法
一： intercept 阅读全文 >>
Jackson 是 Playfrmework 2 中默认的 JSON 处理框架，先前是 GSON，JSON 是 Playframework 中的第一等公民，可见 Jackson 在 Playframewok 中的重要地位。Jackson 提供了一系列的注解可用，像 @JsonIgnore, @JsonProperty, @JsonUnwrapped, @JsonFilter 等。人的需求总是很难得到满足，所以免不了还是要定义自己的注解。比如有这样一个需求，JavaBean 中被 @MaskField(这个即将成为我第一个自定义的注解) 标记的属性或 getter 方法，总是输出为 ******, 无此标记的属性或方法输出原始值。
我尝试过 @JsonFilter 或是单纯的自定义 JsonSerializer, 并不怎么如意。本人最终的实现方式涉及到
初学 Java 的人很不经意间就会把常量定义在接口中，大概唯一的理由是接口不能实例化，而使用接口中定义的常量也是不用附着在实例上的。这主要还是 JDK 本身给我们做了很多这样的榜样, 如 java.io.ObjectStreamConstans，多是出现在 Enum 类型到来之前。
其实 Java 的接口常量是一种反模式，理由如下：
1. 接口是不能阻止被实现或继承的，也就是说子接口或实现中是能够覆盖掉常量的定义(重名)，这样通过父，子接口(或实现) 去引用常量是可能不一致的
2. 同样的，由于被实现或继承，造成在继承树中可以用大量的接口, 类 或实例去引用 同一个常量，从而造成接口中定义的常量污染了命名空间。(Java 编译器竟然允许使用实例去引用类变量)
3. 接口暗含的意思是：它是需被实现的，代表着一种类型，它的公有成员是要被暴露的 API。而在接口中定义的常量说不上是 API
4. 这点有些重复，Java 允许通过子类去引用父类中定义的常量，各级对像实例去引用父类的常量，所以这会造成相当的混乱不堪。定义的常量不能保证单一的引用方式。
参见： Effective java 第 19 条: 接口只用于定义类型
既然接口中不适于定义常量，那么该在何处为常量安家呢？接口为 实现/继承 而生，如果放在类中，并且这个类是 final，且封闭掉构造方法就行。于是我们先前的接口常量定义 阅读全文 >>
随着 Mac 下终端的使用日益增多，系统默认的 bash 已经满足不了需求了，于是有了更为强劲的 fish 和 zsh，以及它们各自的强心剂 Oh-My-Fish 和 Oh-My-Zsh. 我的选择是 Fish 和 Oh-My-Fish。
到目前为止，最新的 fish 2.2.0 于 2015 年 7 月 12 日发布，Release notes 如下 http://fishshell.com/release_notes.html，其中显著改变有：
abbr command allows for interactively-expanded abbreviations, allowing quick access to frequently-used commands (#731).fish_vi_mode to switch fish into the key bindings and prompt familiar to users of the Vi editor (#65).fishd universal variable server has been removed as it was a source of many bugs and security problems. Notably, old fish sessions will not be able to communicate universal variable changes with new fish sessions. For best results, restart all running instances of fish.我对第二点比较感兴趣，即增加了 vi 模式，在 fish 下运行 fish_vi_mode 命令，或者在 ~/.config/fish/config.fish 中加上 fish_vi_mode 便自动进入 vi 模式。 阅读全文 >>
枚举的声明很简单, 像 enum Gender { Male, Female }, 其余事情就是 Java 编译器帮我们干的了，所以 enum 也就是一块语法糖。有了枚举确实是很方便，避免了传统常量的无范围性。那么编译器到底在后面做了什么呢？以及理解了这个之后我们可以怎么去使用 Java 的枚举, 下面就从这个例子说起：
public enum Gender {
Male,
Female
}
把上面的编译成 Gender.class, 然后用 javap -c Gender 反编译出来就是 阅读全文 >>
我们无论是在写批处理还是 Linux 的 Shell 都常用到 >, >> 或 <，这是输入输出重定向。特别是 Linux 的 Shell 常见到 2>&1 这样的写法，这是在干什么呢？这里就来了解下 Linux 下的输入输出重定向的一些来龙去脉。
在 Linux 下几乎一切都号称是文件，标准输入、输出也不例外，它们是叫做 fd (File Descriptor) 文件描述符。这里我们关注三个东西
| 名称 | 代码 | 操作符 | Java中表示 | Linux 下文件描述符（Debian 为例) |
| 标准输入(stdin) | 0 | < 或 << | System.in | /dev/stdin -> /proc/self/fd/0 -> /dev/pts/0 |
| 标准输出(stdout) | 1 | >, >>, 1> 或 1>> | System.out | /dev/stdout -> /proc/self/fd/1 -> /dev/pts/0 |
| 标准错误输出(stderr) | 2 | 2> 或 2>> | System.err | /dev/stderr -> /proc/self/fd/2 -> /dev/pts/0 |
从以上表格我们可以理解 0, 1 和 2 分别是什么东西了，它们的输入源或输出目的地默认都是屏幕。
下面不作系统解释输入, 输出重定向的完整使用，只说明一些常见的例子： 阅读全文 >>