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




N-Kodak Gold 100

N-Kodak Gold 100

N-Kodak Gold 100 Warm

N-Kodak Gold 100 Warm



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


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


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


##列表形式 在早期使用轻单的时候就是不知道写什么内容,对于列表这样的一个形式无意中对内容有了较大的限制。而反过来列表的形式又给予了内容更多的整理。轻单内容用来做分享,用来整理个人知识是很好的,当你真正理解这样的一个形式之后,对自己还是他人都是很有帮助的,就像我一直订阅的台湾一位作者的博客—-电脑玩物,其实说白了,作者很大一部分内容都是整理列表—-旅行你需要的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 恢复该文。后来发现作者网站虽然无法访问,但是作者将网站开源 了。


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.


  • 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

   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

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!


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:


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


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:

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

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



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

YAML 学习笔记


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


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的结构:hash,list 和 block literal


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

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

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


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


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


或者叫做 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}


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


0.25: a float key

key的值也可以多行,使用 ? 表示key 的开始:

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



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


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

block literal(文字块)


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 Validation


2015-08-08 YAML , JSON , XML

VSCO cam使用

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


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(阴影色调): 在阴影区域填充紫色、红色、棕色、黄色、绿色、蓝色,效果默认为最强,向左滑动减轻效果。


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.




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.



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


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.


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.


The Chromatic Collection


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.



The Essence/Archetype Collection


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.



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



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


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.



——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.




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.



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



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


New Modern / Lights


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



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.



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


S1-S3 鲜艳

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



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



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



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


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.


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系列的滤镜,已补上


2015-08-05 VSCO , photography , 摄影 , 滤镜 , 应用



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

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





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




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


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

总计:33.20元 平均每个人16.6





2015-08-04 Uber , 人民优步 , 专车


在使用 [[Userscript]] 之前针对使用的浏览器安装如下的插件




userscripts 网站汇总

userscripts.org已挂 原因参见:ghacks.net 对于已挂的 userscripts.org 链接,例如




新兴诞生的 Userscripts 网站列表


GreasyFork 或许是最受欢迎的后起之秀了。它由 Jason Barnabe 创建,Jason Barnabe 同时也是 Stylish 网站的创办者,在其储存库中有大量的脚本资源。

  • 拥有大量的活跃脚本
  • 拥有从 GitHub 同步脚本的功能
  • 非常活跃的开放源码 GitHub


OpenUserJS 继 GreasyFork 之后开始创办。它由 Sizzle McTwizzle 创建,同样地,在其储存库中也拥有大量的脚本资源。


可以在 GitHub 或者 gist 中搜索.user.js 后缀的文件。


Download YouTube videos as MP4

这个脚本最初也是在userscripts.org上面更新的,可能后来网站不维护了,作者就在GitHub更新了。同样在 Greasyfork 也能找到下载链接。

Ingress Intel Total Conversion

简称 IITC ,Ingress 玩家的神器,IITC有一系列的脚本,都能在网站上找到链接,这里推荐我使用的一些桌面版脚本:

  • IITC Plugin draw tools
  • IITC plugin player tracker
  • IITC plugin sync
  • IITC plugin Zaprange
  • IITC plugin show linked portals

如果发现好用的IITC Plugin欢迎交换使用体验。






调用Google Custom Search Engine的脚本,在豆瓣电影页面显示下载链接














2015-08-03 userscript , tampermonkey , greasemonkey , script , greasyfork

我使用的 Chrome Extension

日常使用备份,另外会单独拿出一列写写我用的 Userscript,类似微博去广告,豆瓣页面显示下载链接之类并不会存在这个列表里面。使用这一套扩展的好处有以下几点:

  • 使用账号同步,在不同电脑上同步扩展的配置,即使重装系统,所有的扩展配置都能够同步过来
  • 占用内存相对较少,部分扩展使用 [[Userscript]] 代替,减少 Chrome 常驻内存

Chrome Extension


Checker Plus for Gmail

这是一款检查 Gmail 新邮件的扩展,推送及时,并且可以不离开当前页面查看邮箱内容。

checker plus for gmail


Checker Plus for Google Calendar

一款用来检查 Google Calendar 的插件,可以快速的预览 Google Calendar 中的事项,也可以直接创建 Event。


上面两个扩展都是一位叫做 Jason Savard 的自由开发者开发的。因为我日常使用这两个网页应用比较多,自然的就找到了这两个扩展,免费版本的功能就已经可以满足 80% 需求,不过我还是小小的支持了一下作者,这可能是我付费的第一,二款 Chrome 扩展。


密码管理 LastPass 甚至可以用来共享密码~~

LastPass: Free Password Manager LastPass, an award-winning password manager, saves your passwords and gives you secure access from every computer and mobile device.


Trello 官方的扩展,可以很轻松添加卡片。



当然他是神器 Chrome 下,扩展是能够同步的,而脚本我找到了方法也能够同步~~文中有

Tampermonkey The most popular userscript manager for Blink-based browsers


在浏览页面的时候使用 Vim 的快捷键。



曾经一度不能区别 Adblock(AB) 与 Adblock Plus(ABP), 后来大概了解了一下,可参阅我博客:http://www.einverne.tk/2013/08/ababp.html 至于后来,我只用 Adblock 了,为啥?我觉得 Adblock 更好~~文中有解释

AdBlock. The #1 ad blocker with over 200 million downloads. Blocks YouTube, Facebook and ALL ads by default (unlike Adblock Plus).

Proxy Switchysharp 已经替换成 Proxy SwitchyOmega

不解释 Proxy SwitchySharp Manage and switch between multiple proxies quickly & easily. Based on “Proxy Switchy!” & “SwitchyPlus”

目前已经替换成 Proxy SwitchyOmega

PT Plugin Plus

一个 PT 站点的管理工具,因为没有上架 Web Store 所以只能自己编译,加载安装。

Plus for Trello

Trello 的扩展,可以对每一个卡片进行计时。


bypass paywalls



2020 年更新

目前我已经不再使用 Evernote,所以也放弃了使用 Evernote 的剪藏。现在推荐 WizNote 或者 Joplin 的剪藏。


Evernote Web Clipper Use the Evernote extension to save things you see on the web into your Evernote account.



惠惠购物助手 网易出品】在您网购浏览商品的同时,自动对比其他优质电商同款商品价格,并提供商品价格历史,帮您轻松抄底,聪明网购不吃亏!

User Agent Switcher


User-Agent Switcher User-Agent Switcher is a quick and easy way to switch between user-agents.

扇贝网查词助手 已弃用

目前转用 GoldenDict,是操作系统级别的查词,所以也放弃了这个插件。


扇贝网查词助手 扇贝网查词 Chrome 扩展,查词更方便。

Image Downloader


Image Downloader Browse and download images on a web page.

RSS Subscription Extension By Google

InoReader 不解释

RSS Subscription Extension (by Google) Adds one-click subscription to your toolbar.

Hover Zoom


Hover Zoom Enlarge thumbnails on mouse over. Works on many sites (Facebook, Twitter, Flickr, Reddit, Amazon, Tumblr, etc).

Search by Image (by Google)


Search by Image (by Google) This extension allows you to initiate a Google search using any image on the web. By the Google Images team.

远方 New Tab


Dream Afar New Tab An unexpected trip everyday by simply opening a new tab

这个扩展看上去从 WebStore 下线了,永久的停留在了 0.3.12_0 版本。

以下 Chrome App


Hangouts 推荐使用 App 版本,看样子 Google 应该会重点发展 App 版的 Hangouts Always stay connected with the new desktop app for Hangouts on ChromeOS and Windows.

Google Keep 已经弃用,使用 Evernote 完全代替

Google Keep - notes and lists Quickly capture what’s on your mind and share those thoughts with friends and family.

2015-08-02 chrome , google , google-extension

Java 查漏补缺一些小问题



public static boolean isOdd(int i) {
	return (i & 1) != 0;

不能 i % 2 == 1,当 i 为负数时,求余数结果为 -1

double 精度问题


2.00 - 1.10

并不是精确等于 0.90 而可能是 0.8999999


方式二,使用 BigDecimal,精确计算小数,另外一定要用


String 构造器,而不要用 BigDecimal(double) 构造函数。


一天的微秒除以一天的毫秒数,理论结果应该是 1000,但实际是 5.

public class LongDivision{
    public static void main(String args[]){
        final long MICROS_PER_DAY = 24 * 60 * 60 * 1000 * 1000;
        final long MILLIS_PER_DAY = 24 * 60 * 60 * 1000;

long 类型可以保存这两个乘积,没有溢出。但问题在于 MICROS_PER_DAY 计算以 int 来执行的,只有运算完成才会提升到 long,而此时计算已经溢出。

乘数因子为 int 时,相乘得到另一个 int。存储结果的变量的类型会影响到计算所使用的类型。


2015-07-27 java , programming , long , double



  • 逃离豆瓣之豆瓣代替服务 这篇笔记新建的时间是 2020 年 12 月 29 号,想来从那个时间点开始我就一直想着怎么离开豆瓣了。过去一年时间里面陆陆续续也发现了不少不错的网站,甚至有一些比豆瓣都要好用。这里就再整理一下。
  • Proxmox 扩展 VM 虚拟机磁盘容量 之前在 Proxmox 上给 Ubuntu 划分了 64GB 的空间,运行一段时间之后磁盘空间剩余不多,就抽时间扩展一下。本文就记录一下给 Proxmox VE 的虚拟机扩展的过程。其实之前的文章里面也略微提到过一些,但是没有完整记录。
  • 使用 lux 下载哔哩哔哩视频 Lux 是一个使用 Go 语言编写的视频下载命令行工具,支持的平台很多,提供了包括 macOS、Windows、Linux 等等平台的命令行支持,安装和使用非常简单的。Lux 原来的名字是叫做 Annie(安妮),对标的是 macOS 上一款非常著名的视频下载软件叫做 Downie(唐尼)。但后来改名成了 Lux。
  • 图片压缩工具 Squoosh 离线版 Squoosh 是 Google 推出的一个图片压缩工具。之前整理macOS 初始化设置 的时候就说过,基本上算是必不可少的一个压缩工具了。
  • 每天学习一个命令:umask 命令简单介绍 在使用 LinuxServer 的 Docker 镜像的时候经常会需要设置 umask 值,这个值的具体作用一直不太清楚,正好整理一下。