Python 方法的参数种类有很多，而不是通常语言定义的那样， Python 方法的传参能力要比想象的强大很多。很多初学者可能对一些库中带 * 带 ** 的参数类型非常奇怪，但是其实这些语法正是保证 Python 方法传参强大的重要因素。

First Thing

首先要声明 argument 和 parameter 的区别，很多时候这两个单词被直接翻译为参数更导致了很多人无法区分，argument 是调用方发起的称呼，parameter 是定义方法时使用

def foo(a, b):  # <- a and b are "parameters" or "formal arguments"
    pass

foo(1, 2)  # <- 1 and 2 are arguments to foo, that match a and b

参数类型

在讨论参数类型之前，先来看一个例子

def bar(a,    # <- this parameter is a normal python parameter
        b=1,  # <- this is a parameter with a default value
        *,    # <- all parameters after this are keyword only
        c=2,  # <- keyword only argument with default value
        d):   # <- keyword only argument without default value
    pass

这是一个典型的方法定义，其中包括了一些类型，但是还不全面。

Python 的参数类型：

• Positionals: matched from left to right 很多教程都叫做：位置参数

  顾名思义，就是从左往右匹配，比如 def foo(a, b): pass 传参的时候就必须 foo(1,'a') 按照位置传

• Keywords: matched by argument name

  也就是传参时需要指定关键词 (name=value) 这样的形式传，比如定义 def func(name=value):pass 然后调用 func(name=value)

• Defaults: specify values for arguments that aren’t passed

  可以给某些参数默认值，如果不传这些参数则使用默认值，这些可选参数传值时也需要 name=value

• Varargs collecting: collect arbitrarily many positional or keyword arguments

  方法可以使用带 * 或者 ** 的参数来收集任意长度的参数，定义方法时 def func(*name) 用来收集剩下的位置参数然后保存到 tuple 中，定义方法 def func(**name) 将收集所有的 keyword arguments 然后作为 dictionary

• Varargs unpacking: pass arbitrarily many positional or keyword arguments

  调用者可以使用 * 方式来 unpack 参数集合，比如 func(*sequence) 调用者将 sequence 的所有对象一个个按照顺序传入（作为单独的 positional arguments)， func(**dict) 调用者将 dict 中的所有 key/value 以单独的关键词参数传入 (keyword arguments)

• Keyword-only arguments: arguments that must be passed by name

  In Python 3.0 以后引入，可以指定必须 name=value 传递

总而言之，上面定义的参数类型模型，让 Python 能够决定方法需要传递多少参数，通常情况下位置参数调用者必须显示指定，而如果定义了默认参数调用者往往可以省去，而如果定义了 * 参数，则表示调用者可以传任意数量的参数。

顺序

方法定义和方法调用都要遵循一定的顺序：

• 方法调用者，参数列表需要按照如下顺序：positional arguments(value) -> keyword arguments(name=value) -> *sequence -> **dict
• 而方法定义时，参数定义需要按照： normal arguments(name)， 跟着 default arguments(name=value), -> *name -> name or name=value keyword-only arguments -> **name

在定义和调用时， **arg 如果定义都必须在最后出现，如果不按照顺序使用，会给出语法错误。 Python 内部按照下面的步骤来匹配参数列表：

• 先按照 positional arguments 来赋值，对于任何 positional arguments：

  1. 尝试将 argument 绑定到第一个没有填充的 parameter slot，如果 slot 不是 vararg slot，标记 slot 为 filled 。
  2. 如果下一个 unfilled slot 是一个 vararg slot，并且没有 name 那么报错
  3. 否则（下一个 unfilled slot 是一个 vararg slot)，所有剩下的 non-keyword arguments 都传给 vararg slot。

• 再按照 keyword arguments 来赋值任何匹配的参数

  1. 如果 parameters 中存在 name 和 keyword 匹配的参数，在将 argument value 赋值给 parameter slot. 如果 parameter slot 已经 filled，报错
  2. 否则，如果有 keyword dictionary argument, argument 就添加到存在的 dictionary，如果已经存在同名 key，则报错
  3. 否则，如果没有 keyword dictionary, 并且没有匹配的 named parameters , 报错
• 将剩余没有 keyword 的参数赋值给 *name 元组
• 将剩余的 keyword 参数赋值给 **name 字典

• 最后将默认值赋值给没有传入的参数

  • 如果 vararg slot 还没有填充，将空的 tuple 赋值给他
  • 对于剩下的空的 slot，如果有默认值则填充，如果没有默认值，则报错

在这些之后，Python 会检查每个参数都已经有且仅有一个值，如果不是将抛出错误。一旦匹配完成，Python 就将传入的对象赋值给参数名。

在这些都理清楚之后 Python 3.0 还有一个 keyword-only arguments 似乎还要费些笔墨。

Python 3.0 Keyword-Only Arguments

Python 3.0 总结了定义方法时参数列表的顺序，允许我们使用 keyword-only arguments —- 这类参数只能通过 keyword 传入，永远不会使用 positional argument 来填充。当我们既想要方法处理任意数量的 arguments 并且也可选的接受一些 configuration 选项时。

句法上， keyword-only arguments 类似于 named arguments，但是出现在 *args 后面。所有这类 argument 都必须在调用时使用 keyword 形式传入。

>>> def kwonly(a, *b, c):
        print(a, b, c)

>>> kwonly(1, 2, c=3)
1 (2,) 3

>>> kwonly(a=1, c=3)
1 () 3

>>> kwonly(1,2,3)
TypeError: kwonly() needs keyword-only argument c

这里 *b 如果不需要任意长度可以简写为 *

>>> def kwonly(a, *, b, c):
        print(a, b, c)

>>> kwonly(1, c=3, b=2)
1 2 3
>>> kwonly(c=3, b=2, a=1)
1 2 3
>>> kwonly(1,2,3)
TypeError: kwonly() takes exactly 1 positional argument (3 given)
>>> kwonly(1)
TypeError: kwonly() needs keyword-only argument b

在 * 之后依然可以使用带默认值的参数，b,c 如果被使用到则必须使用 keyword

>>> def kwonly(a, *, b='spam', c='ham'):
...
print(a, b, c)
...
>>> kwonly(1)
1 spam ham
>>> kwonly(1, c=3)
1 spam 3
>>> kwonly(a=1)
1 spam ham
>>> kwonly(c=3, b=2, a=1)
1 2 3
>>> kwonly(1, 2)
TypeError: kwonly() takes exactly 1 positional argument (2 given)

如果 keyword-only 参数没有默认值，则在调用时必须传入

在调用时，keyword-only 被传入时，必须要在 **args 之前

>>> def f(a, *b, c=6, **d): print(a, b, c, d)
>>> f(1, *(2, 3), **dict(x=4, y=5))
1 (2, 3) 6 {'y': 5, 'x': 4}

>>> f(1, *(2, 3), **dict(x=4, y=5), c=7)
SyntaxError: invalid syntax

>>> f(1, *(2, 3), c=7, **dict(x=4, y=5))
1 (2, 3) 7 {'y': 5, 'x': 4}

>>> f(1, c=7, *(2, 3), **dict(x=4, y=5))
1 (2, 3) 7 {'y': 5, 'x': 4}

>>> f(1, *(2, 3), **dict(x=4, y=5, c=7))
1 (2, 3) 7 {'y': 5, 'x': 4}

为什么要有 keyword-only arguments ，简单的来说，就是想让方法支持任意的 positional arguments 并且让 configuration 选项作为 keyword 传入。

比如想要实现一个函数，处理传入的一组对象，并且有一个开关用来指定处理完成之后是否通知

process(X, Y, Z)
process(X, Y, notify=True)

如果没有 keyword-only arguments，我们可能需要同时使用 *args 和 **args 并且人工的从 keywords 中获取 notify 。使用 keyword-only 可以节省很多

def process(*args, notify=False): ...

reference

• https://www.python.org/dev/peps/pep-3102/

Argument passing 指的是方法传参，对象是如何被传送到方法作为输入的。

下面是传参的几个要点：

• Arguments are passed by automatically assigning objects to local variable names.

  参数被传递后自动将赋值给局部变量名

• Assigning to argument names inside a function does not affect the caller

  在方法内部对参数进行赋值，不会影响调用者

• Changing a mutable object argument in a function may impact the caller

  方法可能会原地修改可变对象，从而影响到调用者

记住以上几点就能够清晰的明白 Python 中传参的要点了。Learning Python 一书中将 Python 传参模型和 C 语言比较，他们都有共同点：

• Immutable arguments are effectively passed “by value.”
• Mutable arguments are effectively passed “by pointer.”

Python 的这种传值机制使得在函数中传递对象变得非常简单，即使是很大的对象传递一个”指针“也非常快速。但是对于编程者而言需要非常明确地知道，在传递可变对象时需要特别当心方法会修改对象值。所以有必要的情况下，先拷贝一份对象内容再传递给方法。

举例

例子

def test_function_args(s: str, i: int, t: tuple, d: dict, c: tuple):
    print('-' * 10)
    print(f's id: {id(s)}, value: {s}')
    print(f'i id: {id(i)}, value {i}')
    print(f't id: {id(t)}, value {t}')
    print(f'd id: {id(d)}, value {d}')
    print(f'c id: {id(c)}, value {c}')
    print('-' * 10)
    s = 'in function'
    i = i + 10
    t = (3, 4)
    d['age'] = '20'
    c[0].append(3)
    print('-' * 10)
    print(f's id: {id(s)}, value: {s}')
    print(f'i id: {id(i)}, value {i}')
    print(f't id: {id(t)}, value {t}')
    print(f'd id: {id(d)}, value {d}')
    print(f'c id: {id(c)}, value {c}')
    print('-' * 10)


if __name__ == '__main__':
    s = 'this is a test s'
    i = 10
    t = (1, 2)
    d = {'name': 'ev'}
    c = ([1, 2], 3.14)
    print('-' * 10)
    print(f's id: {id(s)}, value: {s}')
    print(f'i id: {id(i)}, value {i}')
    print(f't id: {id(t)}, value {t}')
    print(f'd id: {id(d)}, value {d}')
    print(f'c id: {id(c)}, value {c}')
    print('-' * 10)
    test_function_args(s, i, t, d, c)
    print('-' * 10)
    print(f's id: {id(s)}, value: {s}')
    print(f'i id: {id(i)}, value {i}')
    print(f't id: {id(t)}, value {t}')
    print(f'd id: {id(d)}, value {d}')
    print(f'c id: {id(c)}, value {c}')
    print('-' * 10)

输出

----------
s id: 139714585800824, value: this is a test s
i id: 9277184, value 10
t id: 139714585799240, value (1, 2)
d id: 139714605570160, value {'name': 'ev'}
c id: 139714585797704, value ([1, 2], 3.14)
----------
----------
s id: 139714585800824, value: this is a test s
i id: 9277184, value 10
t id: 139714585799240, value (1, 2)
d id: 139714605570160, value {'name': 'ev'}
c id: 139714585797704, value ([1, 2], 3.14)
----------
----------
s id: 139714605058544, value: in function
i id: 9277504, value 20
t id: 139714585798664, value (3, 4)
d id: 139714605570160, value {'name': 'ev', 'age': '20'}
c id: 139714585797704, value ([1, 2, 3], 3.14)
----------
----------
s id: 139714585800824, value: this is a test s
i id: 9277184, value 10
t id: 139714585799240, value (1, 2)
d id: 139714605570160, value {'name': 'ev', 'age': '20'}
c id: 139714585797704, value ([1, 2, 3], 3.14)
----------

不同预设 USING THE DIFFERENT PRESETS

不同的预设命名都是不同的，开头除了N，之外还有C，F之类，上面演示中N代表的是 Nikon。其他不同字母代表意义如下：

• C - Canon
• F - Fuji
• L - Leica
• N - Nikon
• O - Olympus
• S - Standard
• SO - Sony

相同预设不同版本 FILM PRESET VERSIONS

每一种预设都包含多种版本，用来适应曝光，光照等等因素的影响。每一种胶片模拟都有一个”Normal”的版本，以他的名字命名，不包含任何符号后缀，比如”C - Kodak Portra 400”。

包含+，++，+++符号

包含+符号的版本展示更多的颗粒感，颜色更加强烈(gritter, more aggressive)。通常情况下这些版本产生更多的色调(color toning),阴影(fading),和颗粒(grain)。这些版本产生的效果通常相当于曝光不足，和(scanning variations due to non- daylight white balance conditions at the scene.)

包含-，–，—符号

带-号的预设提供Normal预设较轻柔的版本。通常情况下，这些预设调低对比度，降低颗粒感。

UC,NC,VC 含义

VSCO Film 02 中包含内容， UC 是 “Ultra Color”缩写，提供了合适的色彩饱和度（improved color saturation）和丰富的细节（details with fine grain）。 NC 是 “Natural Color”缩写，适合于低对比度环境（low contrast situation）。 VC 是 “Vivid Color”缩写，适合于中等对比度照片（medium contrast images）。

HC

HC是“High Contrast”的缩写，这些版本提供更加醒目的结果。他们达到的效果和通过工具栏的Contrast滑块调整的效果不一样。

ALT

根据官方的文档, VSCO Film 03 中因为 instant films 的效果和拍摄当时的环境相关， VSCO 为了尽量模拟当时的环境，所以每种滤镜都有不同的版本，ALT 版本就是在其他 + 或者 ++ 版本都无法表现的时候的 Alternative 版本。

VSCO FILM 01

FILM 01：现代系列(Modern Films)，收录了当下在产的专业 负片¹，是一个优秀的全能包，包括：

推荐Kodak Portra 400， Fuji 160C ，Fuji 400H（过曝情况下更合适），黑白胶片质感不强。

COLOR

• Kodak Portra 160 / Kodak Portra 160 ++ / Kodak Portra 160 + / Kodak Portra 160 -
• Kodak Portra 400 / Kodak Portra 400 ++ / Kodak Portra 400 + / Kodak Portra 400 -
• Kodak Portra 800 / Kodak Portra 800 ++ / Kodak Portra 800 + / Kodak Portra 800 -
• Kodak Portra 800 HC
• Fuji 160C / Fuji 160C ++ / Fuji 160C + / Fuji 160C -
• Fuji 400H / Fuji 400H ++ / Fuji 400H + / Fuji 400H - / Fuji 800Z
• Fuji 800Z ++ / Fuji 800Z + / Fuji 800Z -

BLACK & WHITE

• Kodak Tri-X / Kodak Tri-X ++ / Kodak Tri-X + / Kodak Tri-X -
• Kodak T-MAX 3200 / Kodak T-MAX 3200 + / Kodak T-MAX 3200 -
• Ilford HP5 / Ilford HP5 + / Ilford HP5 -

VSCO Film 01 review

VSCO FILM 02

FILM 02：经典系列(Classic Films)，收录了一些已经停产的经典 负片¹，该系列产生一种复古风格，适用于日常生活，婚礼和肖像摄影。

Fuji Superia 系列，室外阴天或者绿色较多情况适用。Kodak Portra 是 01 中Kodak老版本，建议对比使用01中的系列。

包括：

• Fuji Neopan 1600 / + / ++ / -
• Fuji Superia 100 / + / ++ / -
• Fuji Superia 400 / + / ++ / -
• Fuji Superia 800 / + / ++ / -
• Fuji Superia 1600 / + / ++ / -
• Ilford Delta 3200 / + / ++ / -
• Kodak Portra 160 NC / + / ++ / -
• Kodak Portra 160 VC / + / ++ / -
• Kodak Portra 400 NC / + / ++ / -
• Kodak Portra 400 UC / + / ++ / -
• Kodak Portra 400 VC / + / ++ / -

VSCO Film 02 walkthrough

VSCO FILM 03

FILM 03：即时显影系列(Instant films)，收录了在产及停产的 即时显影胶片² 。Film 03 pack中又包含了消费级(consumer)和专业级(professional)，即时成像的照片和周围环境温度相关，所以每一种预设又包含了很多 Cold 和 Warm 版本，适用于街景，旅游，日常生活。

包括：

• PX-70 / - / - - / + / ++ / +++ /
• PX-70 Cold / - / - - / + / ++ /
• PX-70 Warm / - / - - / + / ++ /
• PX-100UV+ Cold / - / - - / + / ++ / +++ /
• PX-100UV+ Warm / - / - - / + / ++ / +++ /
• PX-680 / - / - - / + / ++ /
• PX-680 Cold / - / - - / + / ++ / ++ Alt/
• PX-680 Warm / - / - - / + / ++ /
• Time-Zero Polaroid (Expired) / - / - - / - - - / + / ++ /
• Time-Zero Polaroid (Expired) Cold / - / - - / - - - /
• Fuji FP-100c / - / - - / + / ++ / ++ Alt / +++ /
• Fuji FP-100c Cool / - / - - / + / ++ /
• Fuji FP-100c Negative / - / - - / + / ++ / ++ Alt / +++ /
• Fuji FP-3000b / - / - - / + / ++ / +++ / HC /
• Fuji FP-3000b Negative / - / - - / + / ++ / ++ Alt /
• Polaroid 665 / - / - - / + / ++ /
• Polaroid 665 Negative / - / + / ++ / HC /
• Polaroid 669 / - / - - / + / ++ / +++ /
• Polaroid 669 Cold / - / - - / + /
• Polaroid 690 / - / - - / + / ++ /
• Polaroid 690 Warm / - / - - / + / ++ /
• Polaroid 690 Cold / - / - - / + / ++ /

VSCO Film 03 VSCO Film 03 video walkthrough

VSCO FILM 04

FILM 04：正片系列(Slide Films)，收录了在产和停产的经典 正片³ ，这组预设有高对比度，浓重的色彩，适合于旅行，风景，街道和时尚摄影，一般用来处理商业片，风光片，或者纪实片，不要用来处理人像，包括：

• Agfa Scala 200 - / – / + / -/+ / + / ++ / Contrast + / ++ / +++
• Fuji Astia 100F - / – / + / ++ / Balance Cool / Balance Warm / HC / Portrait
• Fuji Fortia SP - / – / + / ++ / +++ / Balance Cool / Balance Warm / Landscape / Portrait
• Fuji Provia 100F - / – / + / ++ / +++ / ++++ / Balance Cool / Balance Warm / HC / Portrait
• Fuji Provia 400X - / – / + / ++ / +++ / Balance Cool / Balance Warm / HC / HC + / HC ++ / Portrait / Vibrant
• Fuji Velvia 50 - / – / + / ++ / +++ / Balance Cool / Balance Warm / HC / Landscape / Landscape+
• Fuji Velvia 100 - / – / + / ++ / +++ / Balance Cool / Balance Warm / HC / Landscape
• Fuji Velvia 100F - / – / + / ++ / +++ / Balance Cool / Balance Warm / HC / Portrait
• Kodak E100G - / – / + / ++ / +++ / Balance Cool / Balance Warm (GX) / HC / Portrait / Vibrant
• Kodak E100VS - / – / + / ++ / +++ / Balance Cool / Balance Warm / Balance Warm + / Portrait
• Kodak E200 - / – / + / ++ / ++ Alt / +++ / Balance Cool / Balance Warm / HC / Portrait / Vibrant

VSCO Film 04 video walkthrough

VSCO FILM 05

FILM 05：原型系列(Archetype Films)，这个是新出的系列，收录了胶片时期市场占有率较大的几种消费级胶片。FILM 05 可以产生一种老旧胶片的美感，适合肖像，婚礼和生活场景。

Agfa Vista，表现红色，减弱青色，夕阳；Kodak Ektar，中性背景下使用；Kodak Gold， Kodak Royal Gold 适合表现黄色色调。

包括：

• Agfa Vista 100 - / – / + / ++ / +++ / Contrast + / Cool / Cool + / Portrait / Soft Highs / Vibrant / Warm / Warm +
• Agfa Vista 400 - / – / + / ++ / Contrast ++ / Cool / Cool + / Portrait / Soft Highs / Vibrant / Warm / Warm + / Night/Tungsten / Night/Tungsten + / Night/Tungsten Alt
• Agfa Vista 800 - / – / + / ++ / Contrast + / Cool / Cool + / Soft Highs / Vibrant / Warm / Warm + / Night/Tungsten / Night/Tungsten + / Night/Tungsten Alt
• Fuji Neopan 400 - / – / + / ++ / +++ / Contrast + / Contrast/Fade + / Soft Highs / Night/Tungsten / Night/Tungsten +
• Kodak BW400CN - / – / + / ++ / +++ / Contrast + / Contrast/Fade + / Soft Highs / Night/Tungsten / Night/Tungsten +
• Kodak Ektar 100 - / – / + / + Blue / + Magenta / ++ / ++ Blue / +++ / Contrast + / Cool / Cool + / Soft Highs / Vibrant / Warm / Warm - / Warm +
• Kodak Gold 100 - / – / + / + Alt / + Alt 2/ + Soft Highs / ++ / +++ / Contrast + / Cool / Cool + / Portrait / Vibrant / Warm / Warm +
• Kodak Gold 200 - / – / + / ++ / ++ Alt / +++ / Contrast + / Cool / Cool + / Green / Portrait / Soft Highs / Vibrant / Warm / Warm +
• Kodak Max 800 - / – / + / ++ / +++ / Alt / Alt + / Alt ++ / Alt Cool / Alt Warm / Contrast + / Cool / Cool + / Soft Highs / Vibrant / Warm / Warm + / Night/Tungsten / Night/Tungsten + / Night/Tungsten Alt
• Kodak Royal Gold 400 - / – / + / ++ / +++ / Contrast + / Cool / Cool + / Soft Highs / Vibrant / Warm / Warm + / Night/Tungsten / Night/Tungsten + / Night/Tungsten Alt
• Kodak Ultramax 400 - / – / + / + Green / ++ / ++ Green / +++ / Contrast + / Cool / Cool + / Soft Highs / Vibrant / Warm / Warm + / Night/Tungsten / Night/Tungsten + / Nigh/Tungsten Alt
• Kodak Ultramax 800 - / – / + / + Alt / ++ / +++ / Contrast + / Cool / Cool + / Soft Highs / Vibrant / Warm / Warm + / Night/Tungsten / Night/Tungsten + / Night/Tungsten Alt

Introducing VSCO Film 05 video walkthrough

VSCO Film 06

Film 06: Alternative Process Films is a well-balanced pack that includes a wide range of push and pull processed looks, which alter grain, contrast, and richness. It also includes cross processed looks, which are best suited for dramatic color effects and vibrancy. From subtle enhancements to bold stylistic editing, this collection is ideal for outdoor and lifestyle photography, modern portraiture, and sunwashed settings.

该系列预设适合拍摄婚礼，生活场景，肖像，或者阳光下场景。推荐Kodak Portra 160+1，Fuji Provia 400X XP。

• Fuji 400H+1 - / + / ++ / +++ / Night / Over / Over+ / Vibrant
• Kodak E100VS XP - / + / ++ / Green / Over
• Ilford HP5-1 - / + / ++
• Ilford HP5+1 - / + / ++
• Ilford HP5+2 - / + / ++
• Ilford HP5+3 - / + / ++
• Kodak Portra 160+1 - / + / ++ / +++ / Alt / Alt+ / Over / Vibrant
• Kodak Portra 400+1 - / + / ++ / +++ / Night / Night+ / Over / Vibrant
• Kodak Portra 400+2 - / + / ++ / Night
• Kodak Portra 400+3 - / + / ++ / Night / Night+
• Kodak Portra 800+1 - / + / ++ / ++ Green / +++ / Night / Night + / Night ++ / Over / Vibrant
• Agfa Precisa XP - / + / ++ / Green / Green- / Over
• Fuji Provia 400X XP - / + Blue / + / ++ / +++ / Over + / Over
• Fuji Provia 400X+1 - / + / ++ / +++ / Night / Night+ / Over / Over+ / Vibrant
• Fuji Sensia XP - / + / ++ / Over / Warm / Warm+ / Warm++
• Kodak TRI-X-1 - / + / ++
• Kodak TRI-X+1 - / + / ++
• Kodak TRI-X+2 - / + / ++
• Kodak TRI-X+3 - / + / ++

VSCO Film 07

Film 07: Eclectic Films features a wide range of looks in our largest release to date, with 18 films and over 100 presets in total. The spectrum of this collection translates to versatility in use and includes muted, vivid, tungsten-balanced, and black and white films — all of which embody an elegant and modern aesthetic. This pack is ideal for most settings and subjects, particularly portraits, night photography, and architecture.

该系列预设适合特定场景的肖像，夜景。推荐Fuji 160S 和 Agfa Ultra 系列。

• Agfa Optima 100 II – / - / + / ++ / Cool / Warm
• Agfa Portrait XPS 160 – / - / + / ++ / Cool / Warm
• Agfa RSX 50 II – / - / + / ++ / Cool / Warm
• Agfa RSX 200 II – / - / + / ++ / Cool / Warm / Warm +
• Agfa Ultra 50 – / - / + / ++ / Cool / Warm
• Agfa Ultra 100 – / - / + / ++ / Cool / Warm
• Fuji 160S – / - / + / ++ / Alt / Cool / Warm
• Fuji Sensia 100 – / - / + / ++ / Alt / Cool / Warm
• Ilford Pan F Plus 50 – / - / + / ++
• Kodak Ektachrome 64 – / - / + / ++ / Alt / Cool / Warm
• Kodak Ektar 25 – / - / + / ++ / Cool / Warm
• Kodak Elite 50 II – / - / + / ++ / Cool / Warm
• Kodak Plus-X 125 – / - / + / ++
• Kodak Tri-X 320 – / - / + / ++ / +++
• Fuji T64 – / - / + Alt / + / ++
• Kodak Ektachrome 64T – / - / + / ++
• Kodak Elite Chrome 160T – / - / + / ++ / Alt + / Alt / Cool / Warm
• Kodak Portra 100T – / - / + / ++ / Cool / Warm

vsco film 07 review

Reference

VSCO Cam 一直深受摄影爱好者的喜爱，VSCO Cam 能够提供极佳的模拟胶片效果(analog film)。而桌面的 VSCO 产品叫做 VSCO Film，这些天试用 Adobe Light Room 突然想起来这样一款产品，上官网一查，VSCO Film 给入门者提供了一套免费的预设(Preset)—-VSCO FILM 00 free starter pack，正好试用一下。

VSCO FILM 00 free starter pack

• 官网及下载地址：http://vsco.co/film/00/lightroom
• 产品介绍及效果演示：http://grid.vsco.co/journal/introducing-vsco-film-00-free-starter-pack

VSCO Film 00 is a FREE starter pack which includes two of our most popular digital emulations of analog film (Kodak Gold 100 from Film 05 and Kodak Tri-X from Film 06).

Perfect for anyone who uses VSCO Cam and is looking to take the next step, VSCO Film 00 brings beautiful presets, custom camera profiles, and the familiar VSCO editing experience to your desktop in Adobe Lightroom (available for a free trial here).

预设安装的路径： C:\Users\Ein Verne\AppData\Roaming\Adobe\Lightroom

预设效果演示(官方演示请见以上链接)：

原图

N-Kodak Gold 100

N-Kodak Gold 100 Warm

N-TRI-X+1

最近整理轻单的内容，发现了之前整理过的一些关于轻单的想法，现在就当是备份吧。原单内容部分由复制他人轻单内容而来。轻单早期是有类似Github fork的复制轻单功能的，后来去掉了。

##够“轻”，但不够简“单”

轻，是我知道可以看什么，不够简“单”，是我不知道该发布什么。知乎/Quora以问题为切入口，引导UGC；豆瓣以图片/电影等内容评论为切入口，来引导；Pinterest以图片收集为切入口，来引导收集整理； 轻单，只提供了新的类容发布形式，却没有给出好的内容发布引导。大类别分类，贪大求全，定位不明，其实也是形式创新局限的表现。 “显性内容决定产品气质”，目测又是一个互联网蝗虫的小圈子玩物 （虽然有问题，但写List确实是喜闻乐见的形式）

From:qdan

##列表形式 在早期使用轻单的时候就是不知道写什么内容，对于列表这样的一个形式无意中对内容有了较大的限制。而反过来列表的形式又给予了内容更多的整理。轻单内容用来做分享，用来整理个人知识是很好的，当你真正理解这样的一个形式之后，对自己还是他人都是很有帮助的，就像我一直订阅的台湾一位作者的博客—-电脑玩物，其实说白了，作者很大一部分内容都是整理列表—-旅行你需要的App，10大素材网站等等。只是作者通过博客，以列表的形式分享了出来。而我们平时如果学会了这样的一种方法，对个人知识的整理是大有益处的。比如我自己学习Vim，Git在初期看了很多的资料，有段时间会很混乱，而如果一段时间之后整理自己学到的知识，并且用列表的形式分享出来会得到更好的理解。 就像上面提到的一样，轻单没有引导UGC，因此新用户会完全找不到主题，或者内容。而我之前也发过一个轻单说“豆瓣无所不在的豆列对轻单是不是一种威胁”，里面提到我会用豆瓣列表去整理看过的电影，会用网易云音乐去整理喜欢的歌曲，而订阅源的列表分享我会用InoReader集成的功能。定期的整理对自己知识体系的形成会有很大的帮助。而如果想要与别人分享，轻单，我说列表，这样的形式对读者有很大的帮助。 回想起来豆瓣在全站推广豆列，Google+更新Collection功能，是不是对列表这种形式的认可呢？

##复制列表 由上，引出了轻单早期的“复制轻单”功能，我一直认为这样的一个功能是Github fork的延伸，我觉得我可以使用复制轻单这样的功能给原始轻单添加更多内容，并且分享出来。而现实中“复制轻单”这个功能并没有很多的人使用，所以后来这个功能也就消失了。

##总结 轻单的创业已经告一段落，开发团队也已经解散了。对于我这样的用户来说，改变并不是很大，我依然用着List这样的形式来写下这样一篇总结，我依然还是用着很多的List来整理方方面面。但是对于一个产品来说，轻单算是一个终结了，期待有更多的新想法的产生，并由此诞生出伟大的产品。

曾经收藏过的一篇文章 How to write a Git commit message，今天无意中点开却发现网站无法访问，故而使用 Google Cache 恢复该文。后来发现作者网站虽然无法访问，但是作者将网站开源 了。

Introduction: Why good commit messages matter

If you browse the log of any random git repository you will probably find its commit messages are more or less a mess. For example, take a look at these gems from my early days committing to Spring:

$ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009"

e5f4b49 Re-adding ConfigurationPostProcessorTests after its brief removal in r814. @Ignore-ing the testCglibClassesAreLoadedJustInTimeForEnhancement() method as it turns out this was one of the culprits in the recent build breakage. The classloader hacking causes subtle downstream effects, breaking unrelated tests. The test method is still useful, but should only be run on a manual basis to ensure CGLIB is not prematurely classloaded, and should not be run as part of the automated build.
2db0f12 fixed two build-breaking issues: + reverted ClassMetadataReadingVisitor to revision 794 + eliminated ConfigurationPostProcessorTests until further investigation determines why it causes downstream tests to fail (such as the seemingly unrelated ClassPathXmlApplicationContextTests)
147709f Tweaks to package-info.java files
22b25e0 Consolidated Util and MutableAnnotationUtils classes into existing AsmUtils
7f96f57 polishing

Yikes. Compare that with these more recent commits from the same repository:

$ git log --oneline -5 --author pwebb --before "Sat Aug 30 2014"

5ba3db6 Fix failing CompositePropertySourceTests
84564a0 Rework @PropertySource early parsing logic
e142fd1 Add tests for ImportSelector meta-data
887815f Update docbook dependency and generate epub
ac8326d Polish mockito usage

Which would you rather read?

The former varies wildly in length and form; the latter is concise and consistent. The former is what happens by default; the latter never happens by accident.

While many repositories’ logs look like the former, there are exceptions. The Linux kernel and git itself are great examples. Look at Spring Boot, or any repository managed by Tim Pope.

The contributors to these repositories know that a well-crafted git commit message is the best way to communicate context about a change to fellow developers (and indeed to their future selves). A diff will tell you what changed, but only the commit message can properly tell you why. Peter Hutterer makes this point well:

Re-establishing the context of a piece of code is wasteful. We can’t avoid it completely, so our efforts should go to reducing it [as much] as possible. Commit messages can do exactly that and as a result, a commit message shows whether a developer is a good collaborator.

If you haven’t given much thought to what makes a great git commit message, it may be the case that you haven’t spent much time using git log and related tools. There is a vicious cycle here: because the commit history is unstructured and inconsistent, one doesn’t spend much time using or taking care of it. And because it doesn’t get used or taken care of it, it remains unstructured and inconsistent.

But a well-cared for log is a beautiful and useful thing. git blame, revert, rebase, log, shortlog and other subcommands come to life. Reviewing others’ commits and pull requests becomes something worth doing, and suddenly can be done independently. Understanding why something happpened months or years ago becomes not only possible but efficient.

A project’s long-term success rests (among other things) on its maintainability, and a maintainer has few tools more powerful than his project’s log. It’s worth taking the time to learn how to care for one properly. What may be a hassle at first soon becomes habit, and eventually a source of pride and productivity for all involved.

In this post, I am addressing just the most basic element of keeping a healthy commit history: how to write an individual commit message. There are other important practices like commit squashing that I am not addressing here. Perhaps I’ll do that in a subsequent post.

Most programming languages have well-established conventions as to what constitutes idiomatic style, i.e. naming and formatting and so on. There are variations on these conventions, of course, but most developers agree that picking one and sticking to it is far better than the chaos that ensues when everybody does their own thing.

A team’s approach to its commit log should be no different. In order to create a useful revision history, teams should first agree on a commit message convention that defines at least the following three things:

Style. Markup syntax, wrap margins, grammar, capitalization, punctuation. Spell these things out, remove the guesswork, and make it all as simple as possible. The end result will be a remarkably consistent log that’s not only a pleasure to read but that actually does get read on a regular basis.

Content. What kind of information should the body of the commit message (if any) contain? What should it not contain?

Metadata. How should issue tracking IDs, pull request numbers, etc. be referenced?

Fortunately, there are well-established conventions as to what makes an idiomatic git commit message. Indeed, many of them are assumed in the way certain git commands function. There’s nothing you need to re-invent. Just follow the seven rules below and you’re on your way to committing like a pro.

The seven rules of a great git commit message

Keep in mind: This has all been said before.

1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how

For example:

Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequenses of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

 - Bullet points are okay, too

 - Typically a hyphen or asterisk is used for the bullet, preceded
   by a single space, with blank lines in between, but conventions
   vary here

If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: #123
See also: #456, #789

1. Separate subject from body with a blank line

From the git commit manpage:

Though not required, it’s a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git. For example, git-format-patch(1) turns a commit into email, and it uses the title on the Subject line and the rest of the commit in the body.

Firstly, not every commit requires both a subject and a body. Sometimes a single line is fine, especially when the change is so simple that no further context is necessary. For example:

Fix typo in introduction to user guide

Nothing more need be said; if the reader wonders what the typo was, she can simply take a look at the change itself, i.e. use git show or git diff or git log -p.

If you’re committing something like this at the command line, it’s easy to use the -m switch to git commit:

$ git commit -m "Fix typo in introduction to user guide"

However, when a commit merits a bit of explanation and context, you need to write a body. For example:

Derezz the master control program

MCP turned out to be evil and had become intent on world domination.
This commit throws Tron's disc into MCP (causing its deresolution)
and turns it back into a chess game.

This is not so easy to commit this with the -m switch. You really need a proper editor. If you do not already have an editor set up for use with git at the command line, read this section of Pro Git.

In any case, the separation of subject from body pays off when browsing the log. Here’s the full log entry:

$ git log
commit 42e769bdf4894310333942ffc5a15151222a87be
Author: Kevin Flynn <kevin@flynnsarcade.com>
Date:   Fri Jan 01 00:00:00 1982 -0200

 Derezz the master control program

 MCP turned out to be evil and had become intent on world domination.
 This commit throws Tron's disc into MCP (causing its deresolution)
 and turns it back into a chess game.

And now git log --oneline, which prints out just the subject line:

$ git log --oneline
42e769 Derezz the master control program

Or, git shortlog, which groups commits by user, again showing just the subject line for concision:

$ git shortlog
Kevin Flynn (1):
      Derezz the master control program

Alan Bradley (1):
      Introduce security program "Tron"

Ed Dillinger (3):
      Rename chess program to "MCP"
      Modify chess program
      Upgrade chess program

Walter Gibbs (1):
      Introduce protoype chess program

There are a number of other contexts in git where the distinction between subject line and body kicks in—but none of them work properly without the blank line in between.

2. Limit the subject line to 50 characters

50 characters is not a hard limit, just a rule of thumb. Keeping subject lines at this length ensures that they are readable, and forces the author to think for a moment about the most concise way to explain what’s going on.

Tip: If you’re having a hard time summarizing, you might be committing too many changes at once. Strive for _atomic commits_ (a topic for a separate post).

GitHub’s UI is fully aware of these conventions. It will warn you if you go past the 50 character limit:

And will truncate any subject line longer than 69 characters with an ellipsis:

So shoot for 50 characters, but consider 69 the hard limit.

3. Capitalize the subject line

This is as simple as it sounds. Begin all subject lines with a capital letter.

For example:

• Accelerate to 88 miles per hour

Instead of:

• accelerate to 88 miles per hour

4. Do not end the subject line with a period

Trailing punctuation is unnecessary in subject lines. Besides, space is precious when you’re trying to keep them to 50 chars or less.

Example:

• Open the pod bay doors

Instead of:

• Open the pod bay doors.

5. Use the imperative mood in the subject line

Imperative mood just means “spoken or written as if giving a command or instruction”. A few examples:

• Clean your room
• Close the door
• Take out the trash

Each of the seven rules you’re reading about right now are written in the imperative (“Wrap the body at 72 characters”, etc).

The imperative can sound a little rude; that’s why we don’t often use it. But it’s perfect for git commit subject lines. One reason for this is that git itself uses the imperative whenever it creates a commit on your behalf.

For example, the default message created when using git merge reads:

Merge branch 'myfeature'

And when using git revert:

Revert "Add the thing with the stuff"

This reverts commit cc87791524aedd593cff5a74532befe7ab69ce9d.

Or when clicking the “Merge” button on a GitHub pull request:

Merge pull request #123 from someuser/somebranch

So when you write your commit messages in the imperative, you’re following git’s own built-in conventions. For example:

Writing this way can be a little awkward at first. We’re more used to speaking in the indicative mood, which is all about reporting facts. That’s why commit messages often end up reading like this:

And sometimes commit messages get written as a description of their contents:

To remove any confusion, here’s a simple rule to get it right every time.

A properly formed git commit subject line should always be able to complete the following sentence:

• If applied, this commit will your subject line here

For example:

• If applied, this commit will _refactor subsystem X for readability_
• If applied, this commit will _update getting started documentation_
• If applied, this commit will _remove deprecated methods_
• If applied, this commit will _release version 1.0.0_
• If applied, this commit will _merge pull request #123 from user/branch_

Notice how this doesn’t work for the other non-imperative forms:

• If applied, this commit will _fixed bug with Y_
• If applied, this commit will _changing behavior of X_
• If applied, this commit will _more fixes for broken stuff_
• If applied, this commit will _sweet new API methods_

Remember: Use of the imperative is important only in the subject line. You can relax this restriction when you’re writing the body.

6. Wrap the body at 72 characters

Git never wraps text automatically. When you write the body of a commit message, you must mind its right margin, and wrap text manually.

The recommendation is to do this at 72 characters, so that git has plenty of room to indent text while still keeping everything under 80 characters overall.

A good text editor can help here. It’s easy to configure Vim, for example, to wrap text at 72 characters when you’re writing a git commit. Traditionally, however, IDEs have been terrible at providing smart support for text wrapping in commit messages (although in recent versions, IntelliJ IDEA has finally gotten better about this).

7. Use the body to explain what and why vs. how

This commit from Bitcoin Core is a great example of explaining what changed and why:

commit eb0b56b19017ab5c16c745e6da39c53126924ed6
Author: Pieter Wuille <pieter.wuille@gmail.com>
Date:   Fri Aug 1 22:57:55 2014 +0200

   Simplify serialize.h's exception handling

   Remove the 'state' and 'exceptmask' from serialize.h's stream
   implementations, as well as related methods.

   As exceptmask always included 'failbit', and setstate was always
   called with bits = failbit, all it did was immediately raise an
   exception. Get rid of those variables, and replace the setstate
   with direct exception throwing (which also removes some dead
   code).

   As a result, good() is never reached after a failure (there are
   only 2 calls, one of which is in tests), and can just be replaced
   by !eof().

   fail(), clear(n) and exceptions() are just never called. Delete
   them.

Take a look at the full diff and just think how much time the author is saving fellow and future committers by taking the time to provide this context here and now. If he didn’t, it would probably be lost forever.

In most cases, you can leave out details about how a change has been made. Code is generally self-explanatory in this regard (and if the code is so complex that it needs to be explained in prose, that’s what source comments are for). Just focus on making clear the reasons you made the change in the first place—the way things worked before the change (and what was wrong with that), the way they work now, and why you decided to solve it the way you did.

The future maintainer that thanks you may be yourself!

Tips

Learn to love the command line. Leave the IDE behind.

For as many reasons as there are git subcommands, it’s wise to embrace the command line. Git is insanely powerful; IDEs are too, but each in different ways. I use an IDE every day (IntelliJ IDEA) and have used others extensively (Eclipse), but I have never seen IDE integration for git that could begin to match the ease and power of the command line (once you know it).

Certain git-related IDE functions are invaluable, like calling git rm when you delete a file, and doing the right stuff with git when you rename one. Where everything falls apart is when you start trying to commit, merge, rebase, or do sophisticated history analysis through the IDE.

When it comes to wielding the full power of git, it’s command-line all the way.

Remember that whether you use Bash or Z shell, there are tab completion scripts that take much of the pain out of remembering the subcommands and switches.

Read Pro Git

The Pro Git book is available online for free, and it’s fantastic. Take advantage!

Sometimes you need more accounts than one for access to Github or Gitlab and similar tools. For example you can have one account for your projects at home/github and second account for your company/gitlab.

Generate first key

ssh-keygen -t rsa -C "youremail@example.com"

When you see this message

Generating public/private rsa key pair.
Enter file in which to save the key (/home/user_name/.ssh/id_rsa):

Enter unique name, for example:

id_rsa_gitlab

Next, you’ll be asked to enter a passphrase.

So, you have created SSH key for your home/github account, now you can generate SSH key for your company/gitlab account.

Generate second key

Call SSH key generator again with second mail.

ssh-keygen -t rsa -C "your_another_email@example.com"

Enter name for github

id_rsa_github

After all steps you can check that all keys were created.

$ ls ~/.ssh

You should see a similar files list:

id_rsa_gitlab id_rsa_github id_rsa_gitlab.pub id_rsa_github.pub

Create config file

Now you need a config file for organize these keys. Create a config file under ~/.ssh/

$ vim config

Add following to config file:

#gitlab
Host gitlab.com
  HostName gitlab.com
  PreferredAuthentications publickey
  IdentityFile ~/.ssh/id_rsa_gitlab

#github
Host github.com
  HostName github.com
  PreferredAuthentications publickey
  IdentityFile ~/.ssh/id_rsa_github

Check connection

Next you can check connection

$ ssh -T git@github.com
Hi einverne! You've successfully authenticated, but GitHub does not provide shell access.

$ ssh -T git@gitlab.com
Welcome to GitLab, Ein Verne (einverne)!

Till now, everything seems ok.

Q & A

Q1. Can one single SSH key be used to push to different Git remotes?

Yes, assuming you are using the one id_rsa.pub or otherwise named public key, together with your private key on all of your development workstations, then simply uploading that one public key to multiple Git hosts will allow you the same access as you currently get from the multiple keys. This will also make your production life a bit easier, without having to manage multiple keys and ensuring you connect with the right one each time you communicate with the server. If you use multiple workstations (ie, home and office), you may also choose to use the same public/private key-pair on each of your local workstations. This further reduces the number of different keys you need to keep track of.

Q2. What is the purpose that we have to generate multiple SSH keys for different remote server?

There is no reason that you have to generate multiple keys for multiple remote Git repository servers, as indicated by the answer to your first question. As Jan Hudec has mentioned though, the reason one might choose to use different keys for different Git repositories, would be for an additional layer of security or management control.

Q3. 如果遇到权限问题，可能是新建的 config 文件权限问题

ssh -T git@gitlab.com
Bad owner or permissions on /home/einverne/.ssh/config

比如遇到上述问题，需要修改一下 config 文件权限

chmod 600 ~/.ssh/config
chown $USER ~/.ssh/config

reference

From:stackoverflow

YAML格式的文件在Jekyll的时候接触到，Jekyll的配置文件就是YAML。Jekyll本身由Ruby写成，而Ruby本身和YAML有着方方面面的联系，Ruby的配置文件约定是YAML。同时，YAML还是Ruby的文本序列化格式。

YAML是一个可读性高，用来表达资料序列的文件格式。YAML是”YAML Ain’t a Markup Language”（YAML不是一种标记语言）的缩写¹ 。在开发的这种语言时，YAML 的意思其实是：”Yet Another Markup Language”（仍是一种标记语言），但为了强调这种语言以数据做为中心，而不是以标记语言为重点，而用反向缩略语重新命名。

空格缩进和JSON选项

YAML文件格式主要集中于空格与缩进的概念，它用于指出数据的层次结构 – 而不是使用XML嵌套标记或JSON的大括号（{}）和方括号（[]），实际上，它是JSON的一个超集，因此，在使用的时候，你可能需要采用JSON风格的语法来跳出空格流，它的创始人将其形容为“为所有编程语言提供人性化的数据序列化标准²”，其重点是人性化。

世上有很多的数据结构，但是都可以归结到三种最基本的结构(primitives)：mappings (hashes/dictionaries), sequences (arrays/lists) and scalars (strings/numbers). 有了这三种基本结构，绝大部分的编程语言都能够使用YAML了。

YAML 可以被用来作为：configuration files （配置文件）， log files（日志文件），interprocess messaging（进程间通信），cross-language data sharing（跨语言数据交换），object persistence（对象持久化）和debugging of complex data structures（复杂数据结构的调试）。当数据能够容易的被读懂的时候，任何事情都会变得简单。

YAML 的目标

The design goals for YAML are³, in decreasing priority:

1. YAML is easily readable by humans.
2. YAML data is portable between programming languages.
3. YAML matches the native data structures of agile languages.
4. YAML has a consistent model to support generic tools.
5. YAML supports one-pass processing.
6. YAML is expressive and extensible.
7. YAML is easy to implement and use.

YAML结构组件

YAML的结构：hash，list 和 block literal

YAML举例，一般扩展名为.yaml，也可以为.yml，比如：John.yml

name: John Smith
age: 37
spouse:
  name: Jane Smith
  age: 25
children:
  - name: Jimmy Smith
	age: 15
  - name: Jenny Smith
	age 12

语义介绍：John今年37岁，有一个幸福的四口之家。两个孩子Jimmy 和Jenny活泼可爱。妻子Jane年轻美貌。

值得注意的是字符串不一定需要双引号，当然如果强行添加双引号也可以。比如 "name: "John Smith" 同样也是可以的。

sequence

也可以叫做 list/array ，数组，列表，清单等等

使用-表示list

- Mark McGwire
- Sammy Sosa
- Ken Griffey

同样可以使用中括号来在行内表示：inline format, using [] ,

[Mark McGwire, Sammy Sosa, Ken Griffey]

二维数组，或者数组中包含数组可以写成

- [name        , hr, avg  ]
- [Mark McGwire, 65, 0.278]
- [Sammy Sosa  , 63, 0.288]

map

或者叫做 hash/dictionary ，键值对,散列,哈希，字典等等。使用:表示，以:分割key:value

hr:  65    # Home runs
avg: 0.278 # Batting average
rbi: 147   # Runs Batted In

使用大括号来在行内表示inline format, using {} ,

{hr: 65, avg: 0.278, rbi: 147}

hash中包含hash可以写成这样：

Mark McGwire: {hr: 65, avg: 0.278}
Sammy Sosa: {
	hr: 63,
	avg: 0.288
  }

散列的key值可以不为字符串，比如

0.25: a float key

key的值也可以多行，使用 ? 表示key 的开始：

? |
  This is a key
  that has multiple lines
: and this is its value

list和hash相互包含

hash内包含数组：

american:
  - Boston Red Sox
  - Detroit Tigers
  - New York Yankees
national:
  - New York Mets
  - Chicago Cubs
  - Atlanta Braves

数组内包含hash：

- # one hr
  name: Mark McGwire
  hr:   65
  avg:  0.278
-
  name: Sammy Sosa
  hr:   63
  avg:  0.288

block literal（文字块）

使用|表示文字块,YAML中字符串不需要包含在引号之内。

literal_block: |
  This entire block of text will be the value of the 'literal_block' key, with line breaks being preserved.
  The literal continues until de-dented, and the leading indentation is stripped.
another_block: >
  This is another block of text

YAML VS XML & JSON

正如你从前面例子中清楚地看到那样，YAML没有XML那么啰嗦了，大部分YAML文件内容就是真实的数据，没有了无穷尽的打开和关闭标记列表，在XML中，这些标记往往比它们描述的数据还大，YAML更适合你需要手工维护的数据文件类型。

YAML没有提供方案或DTD概念，因此无法验证文件格式是否符合你的预期，XML的啰嗦也有它的价值，但总的说来是因为XML的成熟使它具有大量额外的工具来验证它的格式，而YAML还没有。

JSON也适合与任何数据，它主要面向提高性能和文件尺寸的大小，因为它几乎不使用空格和关闭标签，然而，JSON文件的内容增加了复杂性，它的关闭标识就象下地狱一样，这就是JavaFx代码（它基于JSON）中可见的最痛苦的了，在数据文件中，使用UI结构使结果更复杂，其复杂程度几乎使文件变得无法理解。

掺和了{}结构和[]清单，使得手工维护大型的JSON风格的文件变得相当困难，YAML使用它的空格缩进方法巧妙地解决了这个问题，当然，无论何时，你都可以切换到JSON风格的语法（如在底层节点）。

YAML Validation

作为一种格式，必然是人为规定，也必然存在格式检查工具，下面就是俩：

• YAML lint http://www.yamllint.com/
• YAML online Parser http://yaml-online-parser.appspot.com/

还没怎么用过，没形成自己的使用习惯，先搜罗一些滤镜的特性 vsco.co，还有一些参数的意义。

Toolkit工具简介：（以个人重要程度介绍）

Exposure（曝光度）： 向左滑动图片整体变暗，向右滑动变亮。

Contrast（对比度）： 向左滑动图片整体明暗差异变小，向右滑动变大。

Crop（剪裁）： 按一定比列选取图片内容。

Straighten（旋转）： 调整照片角度。

Horizontal Perspective（水平透视调整）： 校正水平方向的透视效果，可将水平方向的收聚线条拉直。

Vertical Perspective（垂直透视调整）： 校正垂直方向的透视效果，可将垂直方向的收聚线条拉直。

Sharpening（清晰度）： 数值越大，图片整体锐利度越高。

Saturation（饱和度）： 向左滑动图片整体色调变轻淡，向右滑动变浓郁。

Highlights Save（高光去除）： 降低高光部分的亮度，对阴影部分影响较小。

Shadows Save（阴影补充）： 提高阴影部分的亮度，对高光部分影响较小。

Temperature（色温）： 向左滑动图片整体变蓝，向右滑动变黄。

Tint（色相）： 向左滑动图片整体变绿，向右滑动变紫。

Skin Tone（肤色）： Skin Tone is a simple but effective tool for creating healthier looking skin. This tool allows for subtle tone adjustment to a subject’s skin, as well as the evening out of color irregularities. The Skin Tone tool combats patchiness found in yellow and red skin tones, as well as enables the correction of overly red or green hues.

肤色是一个用于创造健康肌肤的简单有效的工具。这个工具能够对拍摄对象的肌肤进行细微的色调调整，哪怕是色彩繁杂的夜晚。肤色工具可以减轻黄色和红色调肌肤的斑块，也能修正过度的红绿色调。 对肤色（橙红色调）影响较大，向右滑动偏黄绿，向左滑动偏橙红。

Vignette（暗角）： 数值越大，图片四周失光越重。

Grain（颗粒）： 数值越大，图片整体颗粒感越重。

Fade（淡化）： 数值越大，图片整体灰度越高。

Highlights Tint（高光色调）： 在高光区域填充橘色、奶油色、黄色、绿色、蓝色、洋红色，效果默认为最强，向左滑动减轻效果。

Shadows Tint（阴影色调）： 在阴影区域填充紫色、红色、棕色、黄色、绿色、蓝色，效果默认为最强，向左滑动减轻效果。

A1-A3

With hints of pastels, lifted mid-tones and slight overexposure, this A Series is inspired by analog film. Analog / Archetype is the perfect choice for portraits, interiors and food.

拍摄肖像，室内和食物的完美选择，提高了中间色的同时轻微过曝，拥有柔和的色调。是拍摄肖像，室内和食物的完美选择。

http://grid.vsco.co/journal/new-vsco-cam-presets-available-now

A4-A6

With natural tones, subtle color shifts and slight dimming, Analog / Aesthetic is inspired by classic analog film. Well-suited for interiors, portraits, and food photography, the A series is free for a limited time.

受经典拟真胶片的启发，它带着不做作的色调、微妙的偏色和略微的暗调。相当擅于室内、肖像和食物的拍摄。TAG:肖像，低饱和度

http://grid.vsco.co/journal/introducing-analog-aesthetic

Black & White Classic

B1-B3 黑白

Simple yet enduring, the B Series presets provide subtle black and white refinement. With excellent shadow detail and contrast, this pack is an accommodating addition to any image. Tag: BLACK / WHITE

简单却经久不衰，B系列预设能提取最细微的黑白变化。凭借出色的阴影细节和对比度，它能够容纳任何图像。

B4-B6 黑白

Boasting a dark presence, B4, B5 and B6 give gravity and depth to portraits. This high contrast pack greatly enhances detail in textures and environments.

在阴暗中，B4，B5和P6让肖像变得有力而深沉。这个有高对比度的包大大提高了纹理和环境的细节。

Vibrant Classic C1-C3

Boasting vibrant yet controlled colors, C1, C2 and C3 are timeless, all-purpose presets created for a variety of scenarios and uses.

拥有鲜亮活泼的色彩，C1，C2和C3是为各种各样的场景和用途而创造出来的永恒且万能的预设。

The Chromatic Collection

C4-C9

Inspired by the aesthetic of early color photography, The Chromatic Collection embodies the bright and bold look of mid-century analog film. Strong primary colors mix with muted neutral tones, perfect for portraits, environments, and stylized editorial.

取自早期彩色摄影之美，展现中世纪胶片的明艳和热情。浓烈而精准的色彩配合淡然的色调，用于肖像、环境和随性记录是最棒的。

link:http://grid.vsco.co/journal/the-chromatic-collection

The Essence/Archetype Collection

E1-E8

Essence / Archetype embellishes golden highlights and deep shadows, harkening back to the gilded age of consumer film stock. This comprehensive collection excels in a variety of situations. Unveiling shades of indigo within the shadows to marigold hues revealed in the highlights, E1-E8 are must-have presets to capture the essence of classic film stock.

E1-E8泛出灿烂亮光和深层阴影，带你回溯消费级胶片的黄金年代。它不惧任何拍摄情形。阴影处深藏的靛蓝色搭配亮处流出的橙黄色，E1-E8是捕捉古典胶片精髓的好手。

Link

F1-F3 低饱和度

——MELLOW / FADE Desaturated and understated, this F Series preset pack yields elegant results. An all-purpose pack with analogue film qualities, it excels at beautiful skin tones and quiet everyday moments. Tag: DESATURATED / PORTRAIT

柔和，淡色,低饱和度且颜色轻淡，F系列预设包用于展现出一种简洁。作为一个能保证表现出胶片品质的万能包，漂亮的肤色和宁静的日常生活是它的长项。标签：低饱和度，肖像

http://grid.vsco.co/journal/introducing-vsco-cam-f-series-mellow-fade

G1-G3 肖像

Capture vibrant portrait with the G Series. Boasting brilliant skin tones, G1, G2 and G3 provide a flattering collection of presets for any portrait. Tag: PORTRAIT

用G系列捕捉充满活力的肖像。拥有明亮的肤色，G1，G2和G3为所有肖像提供一个讨人喜欢的预设集合。

H1-H3 夏日静物

An ideal all-purpose pack, Polychrome Summer excels in fashion, lifestyle and still objects. Subtle pink, yellow and purple hues evoke the best memories of summertime. Tag: PORTRAIT / MODERN

多彩夏日擅长潮流，生活和静物，是一个完美的通用包。微妙的粉色、黄色、紫色调唤起夏日时光的美好回忆。标签：肖像，现代

H4-H6 冬季冷色

An ideal all-purpose pack, Polychrome Winter excels in fashion, lifestyle and still objects. Understated cool tones create dreamlike hues inspired by the winter season. Tag: PORTRAIT / MODERN

缤纷冬季对拍摄时尚，生活和静物性能优异，是一个完美的万能包。利用低调的冷色创造出冬季的梦幻色彩。标签：肖像，现代

The Minimalist Collection

A7-A10 蓝色调

——ANALOG / ESSENTIAL With hints of blues, desaturated highlights, and understated, muted exposure, the A7, A8, A9, and A10 presets embody analog film.

带着轻微的蓝色调、弱化的高亮光和轻柔的亮度，A7-A10是胶片的重现。

J1-J6

——PREMIER / SIMPLE Emphasizing the beauty in stillness, the J1, J2, J3, J4, J5, and J6 presets lend to quiet moments, contemplative settings, portraiture, and architecture.

简约，突出静态之美，J1-J6适于宁静片刻、肃穆场合、肖像和建筑。

http://grid.vsco.co/journal/the-minimalist-collection

K1-K3

Inspired by classic Kodachrome film, the K Series emulates the bright and poppy look of its analog forefather. K1, K2 and K3 are classic and bold, recommended for a variety of scenarios.

灵感来自经典的柯达彩色幻灯片Kodachrome，K系列效仿着它前身的明亮醉人视觉。K1，K2和K3是经典且吸引人的，推荐用于各种场景。

M1-M3

A slightly faded and underexposed look define M1, M2 and M3. Exaggerated browns and greens make this pack preferable with nature, still life and expansive environments. Tag: DESATURETED

轻微的灰度和曝光不足的视觉诠释了M1，M2和M3。夸张的棕色和绿色让这个包十分适合自然，静物和广阔的环境。标签：低饱和度

M4-M6

Exhibiting subtle tones, the second pack in the M Series evoke the vintage hues of the 70’s. These desaturated and mellow presets are ideal for urban environments and portraits. Tag: DESATURATED

展现细微的色调，M系列的第二部分透出七十年代的复古色彩。这些预设低饱和度且柔和，用于城市环境和生活非常理想。标签：低饱和度

New Modern / Lights

N1-N3

Tailor-made for bright lights and colors, this N Series works well with photographs shot with the flash or direct sunlight. Modern and bold.

为明亮光照和色彩定制的N系列，在闪光灯及直射阳光的环境下表现优秀。带有醒目的现代风格。标签：肖像，鲜艳。

http://grid.vsco.co/journal/new-vsco-cam-presets-available-now

P1 - P3

——INSTANT + WARM The P Series emulates the warm, creamy overtones and pop qualities of quintessential consumer instant films. P1, P2 and P3 are best suited for images of food, fashion, and everyday life. Tag: INSTANT

——拍立得 + 暖色
P系列是仿照拥有暖调奶油色的消费型拍立得胶片的典范。P1，P2和P3是食物，时尚和日常生活的最佳选择。 标签：拍立得

Instant Cool P4-P6

The second pack in the P Series, P4, P5 and P6 manifest an instant film appeal with emboldening cool and faded tones. Instant + Cool are well suited for food, fashion and everyday life.

P系列的第二部分，P4，P5和P6表现出浓烈冷色和淡化色调的拍立得风格。拍立得+冷色相当适合食物，时尚和日常生活。标签：拍立得

P7-P9

The third pack in the Instant Film series, P7, P8, and P9 represent a wide range of Instant Film aesthetics and are purposed for all-around use. Tag: INSTANT

拍立得胶片系列的第三部分，P7，P8和P9代表着大部分拍立得胶片的美感以及全面。标签：拍立得

S1-S3 鲜艳

Flourishing with brightness, the S Series generates splendid skin tones and works optimally with portraits and scenes with lighter backgrounds.

亮度充足时，S系列显示出极好的肤色，明亮背景下的肖像和景色亦是最佳。

S4-S6

Create instant memories with the presets S4, S5 and S6. The warm orange and yellow tones are perfectly suited for on-the-go portraits and sun-drenched lifestyle images. Tag: VIVID

用S4，S5和S6创作瞬间的回忆吧。温暖的橙黄色调对于旅行肖像和阳光生活完美契合。标签：鲜艳

T1-T3

T1, T2 and T3 posses deep faded values, that are complemented by dramatic color hues. The T Series pulls the ambiance into a realm well suited for environments, nature and darker lit images. Tag: DESATURATED

T1，T2和T3拥有高度的灰度加之戏剧般的色彩。T系列将气氛带入到一个非常适合环境，自然及暗光照片的范围。

X1-X3

The X Series exults gorgeous grey tones and a strong faded quality. X1, X2 and X3 are applicable for a broad range of situations. Tag: BLACK / WHITE

X系列以华丽的灰色调和强力的灰度为荣。X1，X2和X3广泛应用于各种情形。

Black & White Light Tone X4-X6

Spirited and gently hued, the third X Series pack naturally replicates classic sepia tones. X4, X5 and X6 set forth an emboldened duotone pack fitting for a variety of occasions.

黑白，亮色调。浓烈而温柔的色调，X系列的第三部分自然的复刻出古典怀旧色调。X4，X5和X6正是适合各种场合的双色调的预设包。标签：黑白

The Alchemy Collection Q1-Q10

VSCO 自己的描述，Q1-Q10适合日常拍摄，适合肖像和强烈表达的照片。

The Alchemy Collection includes new presets Q1-Q10. Featuring rich vibrancies by refined tones in a wide range of Cross Processed looks, this pack is ideal for lifestyle photograph, stylized portraiture, and strong statement images.

总体来说，新的 Alchemy Collection Q系列滤镜对照片改变比较温和，Q系列预设亮度有所提高，其中一些提高了对比度和饱和度。S曲线以牺牲高光区域和阴影区域的细节来提高中间色调的对比对和饱和度。Q5，Q2，Q1 是Q系列中比较流行的几个预设，而Q7，Q8，Q10为暖色调预设，Q3，Q4，Q6，Q9为冷色调预设。

From: dpreview

轻单搬运过来的文章

2016-01 新增10个Q系列的滤镜，已补上

Reference

• https://www.douban.com/review/6013824/

时至今日，快的，百度易到用车，Uber算是已经完全体验到了。短短一两年出租车行业被互联网颠覆，曾经杂乱的出租车市场被快的，Uber等新生的打的应用迅速抢占。在快的，滴滴打车服务进行的同时，专车服务同样如火如荼的开展着。我不是行业人士，我也不曾知道是谁首先推出的专车服务，我只就一普通用户来谈谈我的使用感受。所以有任何错误或者误解的地方尽管留言讨论或者指正。

15/04/12 更正：记忆错误，百度易到用车首次减免40元

12/04/15 今天早上收到Uber邮件，在04/20前使用优惠码 UBERBJGO 可以三次优惠半价。

12/04/20 输入1UBER1WORLD 2TAPS2REQ 3MINSTORIDE

##打车契机

作为一名普通学生，在出行方面不会优先选择出租车，所以基本上打车的情况是在有优惠券的情况下，并且路途比较偏僻，地铁公交等线路比较难走的情况下。最早使用快的是去年在南京的时候，当时因为不熟悉路况，所以就直接用了快的。而百度易到用车和Uber都是今年较晚的时候才使用过。同学家在天通苑，从学校学院路出发如果从五道口走地铁线路的话得60~80分钟才能勉强到，所以在百度易到用车打折力度比较大的时候尝试过。而Uber同样是去同学家玩，从他家到学校的路程。百度的费用在55~65左右（经同学再三检验），减去40元券，实付15~25元；而Uber当时晚上23点打车回来29元，因为有注册新用户30元优惠，实付0元，余额还剩余1元。

##打的流程

打的流程中我觉得最大的区别在于：快的和易到用车是在确定起始地点和目的地点的情况下，司机能确定接不接这个单，而最近使用Uber感觉到是预约到了车才需要告诉师傅目的地，当然你也可以提前输入目的地。但是使用感受上却是司机可以忽略的你打车请求，所以经常可能半天没有响应，当然快的等等的专车除外，而Uber在之前的尝试（3次）中司机响应都非常快，无论是在大半夜（23点），还是在中午（10点），当然今天早上5点钟尝试的时候是没有车辆可以预约的 T_T 。其实快的，易到用车，Uber专车服务响应都还是不错的~但总体感觉上Uber的流程有点怪异，可能是之前使用了前两个而没习惯吧。

##支付流程及价格

当然最终都是走的支付宝，而Uber比较特殊，在最初注册Uber账号时就已经绑定支付宝账号，在完成打车之后可以自动扣款，当时绑定的时候还犹豫了一下，“快捷支付”的支付宝，会不会乱扣款？犹豫之后还是用了，外国公司总不会不讲信誉吧。而快的和易到用车是在完成时用支付宝付款。这两种支付流程导致的最后结果和体验截然不同。Uber最舒心，到达目的地，不用任何操作和司机说拜拜即可，而快的和易到用车都是需要支付完毕再拜拜的，而在网络不好，或者手机电量不足的情况下无法让人忍受，最终的结果就是很多次直接用现金结算了。

##优惠力度

快的，不用说，当时和滴滴开战，各种，相信如果和司机交流过就知道，最初的时候应该打车是不需要花钱的，反而司机还要倒贴前的。而最近快的可能是推广他们的专车吧，一个劲的给我优惠券，听上去力度很大，100的券啦，30的券啦，进去一看全是单张20一张，15一张，还不能叠加的券，哎，坑啊。百度易到用车，当时新用户首次使用立减50，现在不知道还有没有，所以当时很好玩，同学三个来学校用一个电话号码减40，回去用一个电话号码减40 。 当时就吐槽百度了，和易到用车合作却没有引入一个账号体系，我承认我用过一次之后我应该不会再想到用它了，除非说再减40。而最后Uber，他有他自己的账号系统，手机邮箱，支付宝，在注册的时候就已经定下来，而注册新用户使用别人的优惠码可以得30元，加入余额，在打车中回优先扣减余额中的钱。单次打车最高减免30元。

##Uber特有

今天同学发现Uber还能平摊费用，所以尝试了一下，过程也比较好玩，我用他的优惠券我得30，他得30，打车15.41公里，行程00:29:10，所以结果是： 起步价 0.00 距离 23.17 时间 7.29 小计：30.46元 Uber不计小数点后面的也就是30元 然后车费平分：3.2元

总计：33.20元 平均每个人16.6

所以我账户里面的钱也没用完，我同学账户里面的钱也没用完，所以神奇的免费做了半个小时的出租车。

所以最后容许我推广一下我的优惠码：re3qx，使用此优惠码，你我都可以获得30元的优惠。

##Uber费用估算

• 网页: https://www.uber.com/cities/beijing
• 应用中也可以估算费用

是一篇由轻单搬运过来的文章。