Time to say Goodbye to moments

是时候告别朋友圈了,一遍一遍的告诉自己,曾经关闭过很长一段时间的朋友圈,后来又开启了,用过这段时间之后还是选择关闭。关闭之前说过推荐10部不得不看的韩国电影,今天推荐完最后一期,也就是最后关闭朋友圈的时候了。

wechat no talk

##内容匮乏,互动缺失

微信固有的封闭模式导致了微信产生的内容的局限性,原创的内容匮乏,朋友圈中充斥着转载文章,剩下的就是晒吃晒喝晒自己,而对于我,微信的审查机制导致部分文章在我看到之前就已经被删除,白白浪费我加载的时间,其他内容很少找到我感兴趣的,对于各种晒的,其实我也并不是太关心今天吃了什么,喝了什么。而互动性来说,微信是所有SNS中最封闭的,有时候会在网上随意浏览看新闻的时候看到微信朋友圈中的截图,并以此作为一个新闻,这时我会想,到底是哪个朋友出卖了在朋友圈中发表内容的人,就像前段时间网上流传的毕福剑的视频,原本只是朋友酒席上一番玩笑,却被拿到大众面前,我深深的为毕福剑有这样的朋友而感到悲哀。对那些想要堂堂正正发表新闻的人来说,获取别人通过公开渠道发表的内容才是对别人的尊重,如果当时发朋友圈的那个人只是想在朋友间发表内容,那作为他朋友圈中的一名,至少应该得到当事人的许可才能将朋友圈的内容公开,这是最基本的尊重。

而朋友圈最大的问题在于互动的缺失,正像之前看到的文章—-“新技术真能带来变革吗?”一文中提到的,微信对于公共议题的讨论连微博都比不上。朋友圈中的大部分都是内容的消费者,而大部分的内容生产者都是抱着强烈商业目的的,都是想着向你卖东西。而少数剩下能够讲实话说真话的内容早已经在别人分享到朋友圈之前就消失在了微信的平台上。

##即将泛滥的广告

随着微信用户量的增大,微信变现的方式也会越来越激烈,就前段时间还开放了广告自助平台,朋友圈的广告泛滥的结果可想而知,虽然目前朋友圈的广告并不是很多,大部分的广告也并不是很讨人厌,只是我天生的广告洁癖让我无法忍受。

##朋友圈中的信息孤岛

或许有些人会反问我说,他们只是在碎片的时间中刷刷朋友圈,而我会回答他们,关闭朋友圈之后我会利用碎片的时间阅读RSS,有着开放的互联网可以值得我去拥抱,为什么我还要看朋友圈那一点点和整个互联网脱离的孤岛。我宁愿在闲暇的时间看他人博客上经过长时间思考写出的文章,宁愿看Google+上对于某个问题激烈的讨论。我关闭朋友圈的另外一个原因就是经常看到不经过大脑思考就转发的内容,就如之前的“贩卖孩童一律死刑”的转发,虽然我的朋友圈中父母亲并不是很多,但也依然看到了不少的转发。虽然我也并不能有任何指责,拐卖孩童本身就是一件很严重的违法事件,至于判刑,如果真像大家所说的那样呢?那件事情之后我看了很多的文章,有讲到美国儿童失踪之后的警方处理流程,有讲到法律判刑的基准,有讲到民意等等的,只是那些文章我都不是在朋友圈中看到的,朋友圈中终究没有人认真的讨论这件事情,而是无休止的引发着仇恨。

##最后

终于有勇气关闭朋友圈,也再没对朋友圈有何留恋了。

##参考


2015-09-02 微信 , 思考

不得不看的韩国电影

引子

最早接触韩国电影是很久之前的我的野蛮女友,当时地方电视台播放过,那是我印象当中最早看过的韩国电影了,也是为数不多重复看过几遍的电影。说到韩国电影不得不提他们的OST(电影原声),我的野蛮女友让我记住了 I believe 的旋律,而 I believe 的旋律也让我一遍一遍的回想起电影中的情节。这或许就是音乐的魔力,在关键场景播放出动听的背景乐,不仅能够让调动观众的感情,也能让观众在过后听音乐时回想起电影中的一幕幕。曾经有同学和我说过,“有些歌一遍一遍听,听到最后就没有意思了”,其实这个时候我想告诉他,他没有体会到歌声背后发生的故事,听这首 I believe 的时候,会想起牵牛第一次遇见全智贤的时候,会想起他们在山头的喊话,会想起他们无数次的错过,最后有神奇般的相遇。

而如今想起整理10部不得不看的韩国电影关键是最近看韩国综艺较多,而其中《蒙面歌王》让我改变了对韩国文化的看法。《蒙面歌王》中有一句话说的很好,“摒弃一切偏见,参加比赛”,也正是这个节目让我寻获了很多好听歌,同时也认识了很多的实力歌手,也正是这个节目让我意识到我是不是一直对某些方面存在偏见,我是不是曾经看到韩文,看到日文就无意识的忽略,我是不是曾经对某些品牌,比如联想,存在固有偏见,我是不是曾经对某些方面的认识带有一种倾向。思考良久之后,我觉得我要整理整理我曾经看过的韩国电影, 从电影这一个部分去体会这个和我认识中的存在偏差的韩国。可能大部分的人对韩国的认识都是“棒子”,“中国节日的盗窃者”等等,虽然历史上可能韩国人做过一些坏事,可是几百年过去了,韩国早已跨出一大步,无论是在经济,还是在政治,还是在文化产业上都遥遥领先中国。而我们还在称呼他们“棒子”以为占得一时便宜,占得一时口舌之快就能在现实中超越人家。我们太天真也太傻了。有人说过,”偏见有的时候比无知还要可怕,就像你永远无法叫醒一个装睡的人”。

大部分人接触韩国电影可能都是从爱情片开始的,而看过的韩国爱情片并不是很多,继我的野蛮女友之后,看的第二部爱情片好像是建筑学概论,当然同样,这部电影让我记住了《记忆的习作》一曲,虽然现在剧情有所遗忘,但是如果此时想起《记忆的习作》一曲我依然能够辨识出来,也会想起电影中的一两个镜头。当然,虽然建筑学概论是一部好电影,但还远远没达到我要推荐的韩国电影的水平。近10年的韩国电影发展迅速,各种类型的片子都能找到一些,而我整理出来的10部片子中既包含了爱情片,同样有故事片,现实题材影片等等。10部影片分别是《熔炉》,《辩护人》,《素媛》,《7号房的礼物》,《流感》,《我的野蛮女友》,《杀人回忆》,《老男孩》,《恐怖直播》和《》,这10部影片中现实题材的影片占多数,而其中《熔炉》《素媛》揭露的未成年人性侵案,《辩护人》揭露的政府肆意践踏人权,《恐怖直播》中对电视台内部记者受贿说假话,主持人争权夺利,政府部门不愿意承认错误等等的讽刺,应该让很多中国人感同身受。韩国废除电影审查制度已有几十年时间,这几十年时间中诞生了多少鱼龙混在的电影,我没有做过统计,但却诞生了这么多伟大的电影,我想我可以用伟大来形容,《素媛》让韩国法律改变,《辩护人》让33年前的旧案翻盘,而《7号房的礼物》一片中的小女孩长大成为律师之后,给他的智障父亲翻案,这一系列的电影都在围绕着公平与公正展开,人类普世的价值从来不会因为外力的打击而消失,即使一时被打压,总有一天,所有尘封的黑暗历史都会展露在眼前。抛开现实题材,抛开犯罪电影,韩国的爱情片是最为人知晓的,即使是同样的剧本,韩国总能拍出不一样的味道,我并不是专业人士,也不能辨别镜头剪辑的水平,也并不能知道镜头调度的好坏,但是某种东西,某种感情,总能触动我,也似乎每部爱情片都能留下一两首脍炙人口的歌曲。

韩国电影还在发展,我期待看到更好的影片,当然我最期望能在国内影院上映一部能让我看的下去的国产良心片。

以下就是我整理的十部不得不看的韩国电影:

不得不看的电影之熔炉

韩国电影《熔炉》,视频网站都删了片源,只能下载来看。根据真实案件(性侵儿童案)改编,新闻报说促使韩国国会对相关法案进行了调整。炼心的电影。如果人都是天地培育,天生孤独,本性独立…或者更纯粹一点,存在即是不存在…会否都能活得纯粹一点… 我们一路奋战,不是为了改变世界,而是不让世界改变我们!

不得不看的韩国电影之辩护人

我们落泪,则不仅为电影,更为电影背后相似的历史与现实。我们尚且无法将历史与现实拍成电影。“他们有改变国家的电影,我们有改变电影的国家。”

2013年12月18日,《辩护人》在韩国上映。2014年2月13日,釜山地方法院对“釜林事件”二审宣判,改判被告人无罪。此刻,距离一审已经达33年之久。

不得不看的韩国电影之素媛

最孤独的人最亲切,受过伤的人总是笑的最灿烂,因为他们不愿让身边的人承受一样的痛苦

不得不看的韩国电影之7号房的礼物

当一个社会事件发生的时候,尤其当事者是弱势群体时,我们是否要跟随主流媒体去站在旁观者和道德审判者的角度去抨击当事人的无知和无耻。我们是否能独立的判断,这个事件到底是怎么样的,大多数人说的真的是事实真相吗?保持独立的观察和思考,不要成为冤假错案的帮凶,不要成为毁掉一个美好家庭的帮凶。

多年后,龙九被“洗白”,但这种翻案有没有法律效力都没有意义了,因为生命已经终结。我想起废除死刑的提议,我们是不是真的有足够正确的把握去判处一个人的死亡,而没有死亡又是否能填补被害者亲人的悲痛。

人类用千百年的时间竭力去构建一个理性的审判机制,正义、自由、人权是文明社会最圣洁的象征,公检法与律师被看做是正义的代言人,但显然,现实永远不像动画片那么美好。

不得不看的韩国电影之流感

当流感来袭时,让人心寒的不是致命的病毒,而是人性的丑恶与自私。

不得不看的韩国电影之我的野蛮女友

我从来都不认为本片可以代表韩国爱情电影或者相关的电影昌盛现象!可在2002年的夏天,我和身边的一众原本对韩国电影带有蔑视态度的国内观众,却第一次真正领教了这个半岛国家在电影创作上的收放自如!我们的近邻用真正的实际行动告诉了我们,题材上的限制也可以用好的创意和想法来改变!而我们很多国人和电影制作者却仅仅看到了本片掀起的‘女强男弱’题材的热卖,造就了一票《河东狮吼》、《我的野蛮XX》系列众多东施效颦的作品。而完全没有看到韩国电影工作者的努力和想象力! 十几年间,中国的电影票房呈现了几何程度的增长。电影市场的热卖并不是因为题材上创新能力的增强,或者观众审美水平的如何提高。仅仅是因为我们的经济水平在提高,人口基数的优势在日益显现而已! 粗看《我的野蛮女友》不过是部有些别具一格的小清新加喜剧爱情电影,但细心看来本片却完全胜在了电影内容上的无限制性和颠覆性!它没有拘泥于某种形式上的条条框框,而是完全把富有想象力的情节段落做到了为电影本身服务,哪怕这些情节之前几乎难以被亚洲电影人所驾驭!时至今日,又有多少人曾经留意过这部电影留给过我们的感动和意外之喜。而在韩国流行文化肆虐的大陆市场,让国内众多业内人士谈‘韩’色变之时,其实邻国的文化传播及创作优势早在十几年前就已经显示出来,而我们却一直没有意识到和真正理解。。。

包裹着爱情外衣的奇幻电影

深愛自己的人,
就如電視劇裏面的男二號,
總是有的,
但懂得自己的人,
有的人一生都遇不上。

原来在这世上能遇上一个既爱你又懂得你的人是多么难得。那个爱你却不懂你的人,只能用他的爱来伤害你。你亦如此。如今,我只能眼睁睁看着这段感情在伤痕累累中慢慢消逝,无可奈何。他不懂得的,无论你怎么样解释,他还是不懂。

不得不看的韩国电影之杀人回忆

杀人回忆

并不是每一部电影都要在最后揭晓答案,即使你百般追问、寻思闪回也不得其解。其实凶手是谁并不重要,那是一个人情味很淡的年代,各人疲于奔命只能勉强顾及自己,其实晚上戒严所有人都闭门不出是真正的凶手,军队被调去镇压游行而无法执行维护社会治安也是真正的凶手,官员的腐败导致民众的游行也是真正的凶手,所以在片尾.那个小女孩说凶手是一张很普通的脸,也就是说大部分人的冷漠杀死了受害者

不得不看的韩国电影之老男孩

你笑,世界和你一起笑;你哭,只有你一个人哭。

不得不看的韩国电影之恐怖直播

我们一路奋战,不是为了改变世界,而是不让世界改变我们!

不得不看的韩国电影之金南福杀人事件始末

最朴实的人被最信任的人唤醒心中的恶魔,才知道冷漠是这个世界上最锋利的镰刀。

还有好多好多电影值得推荐,由此可以看出韩国电影各种类型的片子百花齐放

喜剧:恋爱操作团,我的PS搭档,奇怪的她
战争:鸣梁海战,
动作:嫌疑人,
变态杀人:杀人回忆,追击者
灾难片:流感,汉江怪物
复仇:老男孩
社会边缘人物的悲剧:黄海(延边的贫民),熔炉(聋哑人),时间(整容),捉迷藏(流浪者)
友情爱情的:我脑中的橡皮擦,阳光姐妹淘,假如爱有天意,触不到的恋人,我妻子的一切,狼少年,建筑学概论
反战片:欢迎来到东莫村,


2015-09-01 电影 , 韩国 , 推荐

Python 参数类型和参数匹配模型

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


2015-08-27 python , argument-matching , argument , model

Python 方法的参数传递 argument passing 引用传值

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)
----------

2015-08-24 python , argument-passing , notes

VSCO film pack

不同预设 USING THE DIFFERENT PRESETS

不同的预设命名都是不同的,开头除了N,之外还有CF之类,上面演示中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),收录了当下在产的专业 负片1,是一个优秀的全能包,包括:

推荐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),收录了一些已经停产的经典 负片1,该系列产生一种复古风格,适用于日常生活,婚礼和肖像摄影。

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),收录了在产及停产的 即时显影胶片2 。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),收录了在产和停产的经典 正片3 ,这组预设有高对比度,浓重的色彩,适合于旅行,风景,街道和时尚摄影,一般用来处理商业片,风光片,或者纪实片,不要用来处理人像,包括:

  • 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

  1. 将卤化银涂抹在聚乙酸酯片基上,此种胶片为软性,卷成整卷方便使用,所以又称胶卷,当有光线照射到卤化银上时,卤化银转变为黑色的银,经显影工艺后固定于片基,成为我们常见到黑白负片。彩色负片则涂抹了三层卤化银以表现三原色。负片  2

  2. 即时成像相机(Instant Camera)是一种拍摄后相片能够即时快速成像的照相机,在按下快门后数秒内便能够自动从机身内吐出照片,并在几分钟内完成显影。因为其快速显影的优势,在胶卷时代有着众多的使用者。但是由于数码摄影的普及,已经逐渐淡出市场。即时成像相机 

  3. 正片(英语:Positive Film)为底片的分类标准之一,胶片功能类似相纸,利用负片冲印得到正像显影,但不像负片和反转片是摄影胶片;由于以反转冲洗法(Reversal Process)的反转片(Reversal film)亦采正像显影方式,“正片”遂成与负片相对的感光材料总称,可供影片拷贝、幻灯机及灯箱观赏等用途上,也可印制照片、印刷制版。正片 


2015-08-20 VSCO , photography , 摄影

VSCO Film 00 free starter pack

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

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

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

原图

origin

N-Kodak Gold 100

N-Kodak Gold 100

N-Kodak Gold 100 Warm

N-Kodak Gold 100 Warm

N-TRI-X+1

N-TRI-X+1


2015-08-19 VSCO , photography , 摄影 , LightRoom

轻单体验

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

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

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

From:qdan

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

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

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


2015-08-13 List , 豆瓣

How to Write a Git commit message

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

xkcd

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:

gh1

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

gh2

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:

- Refactor subsystem X for readability - Update getting started documentation - Remove deprecated methods - Release version 1.0.0

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:

- Fixed bug with Y - Changing behavior of X

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

- More fixes for broken stuff - Sweet new API methods

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!


2015-08-12 git , github

Git 配置多个 ssh key

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


2015-08-12 git , github , gitlab , ssh

YAML 学习笔记

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

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

空格缩进和JSON选项

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

世上有很多的数据结构,但是都可以归结到三种最基本的结构(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 are3, 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

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


2015-08-08 YAML , JSON , XML

电子书

最近文章

  • Git worktree 作用及使用 在偶然逛 Stackoverflow 的时候看到一个提问,能不能在同一个 repo 中同时有两份代码,并且可以保持两份相似但不是完全相同的代码并行开发?虽然对其需求有些好奇和疑惑 ,但也关注了一下下方的回答。
  • CPU 负载 之前在 Openwrt 负载 中也曾经谈到过 CPU 的负载,通过 top, uptime 等等命令都可以非常快速的查询当前 CPU 的负载。
  • Jenkins 使用 流水线任务
  • jks pem cer pfx 不同种类的证书 通常在安全级别较高的场景经常需要对通信信息进行加密传输,有一种情况就是非对称加密,将信息使用对方提供的公钥加密传输,然后对方接收到之后使用私钥解密。今天在对接时对方发送了一个压缩包,其中包含了 SSL 不同类型的证书,包括了 jks, pem, cer, pfx 等等文件,现在就来了解一下。
  • Spring 中的 @Transactional 注解 Spring 中有两种不同方式实现事务 —- annotations 和 AOP。