最近整理轻单的内容，发现了之前整理过的一些关于轻单的想法，现在就当是备份吧。原单内容部分由复制他人轻单内容而来。轻单早期是有类似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
• 应用中也可以估算费用

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

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

浏览器插件

如果想要在浏览器中快捷方便的管理和安装脚本，可以使用如下的插件：

• Chrome install Tampermonkey Tampermonkey
• Firefox install Greasemonkey Greasemonkey
• Opera install https://addons.opera.com/en/extensions/details/violent-monkey/
• safari install http://ss-o.net/safari/extension/NinjaKit.safariextz

userscripts 网站汇总

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

http://userscripts.org/scripts/show/175005

在网址中间添加-mirror即可访问，如下:

http://userscripts-mirror.org/scripts/show/175005

新兴诞生的 Userscripts 网站列表

Greasyfork

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

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

OpenUserJs

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

• 大量的脚本
• 可以从 GitHub 中进行同步
• 开放源代码 https://github.com/OpenUserJs/OpenUserJS.org

GitHub/Gist

可以在 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欢迎交换使用体验。

下载地址：http://iitc.jonatkins.com/?page=desktop

百度网盘助手

获取百度网盘直链

下载地址：Greasyfork

豆瓣电影自定义搜索

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

下载地址：Greasyfork

知乎免登录

看名字就能看出来，知乎隐藏完整的答案，只有登录才能查看全部的答案。用这个脚本可以破除这个限制。

下载地址：Greasyfork

verydou

该脚本在豆瓣上显示veryCD内容，我将此脚本转移到greasyfork

下载地址：Greasyfork

vipVideos_skipAd

优酷、土豆VIP免费看，去iqiyi、PPS、sohu、56.com视频广告

下载地址：Greasyfork

最后

好吧，放弃了，脚本好多失效了，等再发现好用的再更新吧，可以经常到上面提到的两个网站上逛一逛，会有惊喜，昨天就发现了优酷土豆爱奇艺等等国内视频网站的去广告脚本。

reference

• https://tampermonkey.net/scripts.php

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

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

效率类

Checker Plus for Gmail

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

官方地址：https://chrome.google.com/webstore/detail/checker-plus-for-gmail/oeopbcgkkoapgobdbedcemjljbihmemj

Checker Plus for Google Calendar

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

官方地址：https://chrome.google.com/webstore/detail/checker-plus-for-google-c/hkhggnncdpfibdhinjiegagmopldibha

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

LastPass

密码管理 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

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

官方地址：https://chrome.google.com/webstore/detail/trello/dmdidbedhnbabookbkpkgomahnocimke

Tampermonkey

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

Tampermonkey The most popular userscript manager for Blink-based browsers

Vimium

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

官方地址：https://chrome.google.com/webstore/detail/vimium/dbepggeogbaibhgnhhndojpepiihcmeb

广告屏蔽

曾经一度不能区别 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 所以只能自己编译，加载安装。

• https://github.com/ronggang/PT-Plugin-Plus

Plus for Trello

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

官方地址：https://chrome.google.com/webstore/detail/plus-for-trello-time-trac/gjjpophepkbhejnglcmkdnncmaanojkf

bypass paywalls

用来绕过付费墙。

• https://github.com/iamadamdev/bypass-paywalls-chrome

印象笔记·剪藏

2020 年更新

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

Evernote，千万记住用国际版

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，是操作系统级别的查词，所以也放弃了这个插件。

查词，wiki

扇贝网查词助手 扇贝网查词 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

以下 Chrome App

Hangouts

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.

判断奇数

正确做法：

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，精确计算小数，另外一定要用

BigDecimal(String)

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;
        System.out.println(MICROS_PER_DAY/MILLIS_PER_DAY);
    }
}

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

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

当你在操作很大的数字时，千万要提防溢出。

##简介与历史 花札亦成为花牌，源于日本，后传入朝鲜半岛，是一种传统的纸牌游戏。纸牌上画有12个月份的花草，每种个4张，整副牌48张。

##纸牌牌面介绍

月份	图案	20点牌（光）	10点牌（种）	5点牌	1点牌
1月	松树	松上鹤		松上赤短	松
2月	梅花		梅上莺	梅上赤短	梅
3月	樱花	樱上帘幕		樱上赤短	樱
4月	紫藤		藤上鹃	藤上短册	藤
5月	菖蒲		蒲间八桥	蒲上短册	菖蒲
6月	牡丹		牡丹蝶	牡丹青短	牡丹
7月	萩(三叶草)		萩间猪	萩上短册	萩
8月	芒草	芒上月	芒上雁		芒
9月	菊花		菊上杯	菊上青短	菊
10月	枫叶红叶		枫间鹿	枫上青短	枫叶
11月	柳树(雨)	柳间风	柳上燕	柳上短册	柳雷雨鼓
12月	泡桐	桐上凰			桐(三枚)

• 20點 共5張，松上鶴、櫻上幕簾、芒上月、柳間小野道風、桐上鳳凰。
• 10點 共9張，畫上動物或物品的牌、菖蒲間八橋、菊上盃，即「鶯、杜鵑、八橋、蝶、豬、雁、盃、鹿、燕」。
• 5點 共10張，畫上短籤的牌，赤短三張（紅色有寫字的短籤）與沒寫字的四張紅色短籤及三張青色短籤。
• 1點 共24張，11月為1張，12月為3張，其他月份各有兩張，只畫出植物的牌（也有不計分的情形）。

##游戏流程

###发牌

游戏可由两人或者三人进行，如果遊戲两人进行，第一局前先抽牌決定莊家或閑家，庄家先出牌，第二局以後由前一局的勝者當親先出牌。玩家从牌堆中随意抽取一张牌，抽到月份较晚的玩家成为第一局的庄家。

两名玩家时，每位玩家各拿10张牌，台面上8张牌，其余牌放置一旁做牌堆；三名玩家时，每位玩家7张牌牌，台面上6张牌，一般顺序是先发3张台面牌，然后给三人分别发4张牌，然后台面3张牌，最后三人各发3张牌，其余牌放置一旁。

###出牌

出牌时从庄家开始，以逆时针方向轮流进行。

每个玩家回合内，如果手中和台面上有相同的牌，则将手上的牌与台面上的牌匹对，然后将匹对好的两张牌放到自己的点数牌中。如果手中和台面上无相同的牌，则必须选择放弃手中任何一张牌，以开牌的方式放置于台面。在配对或者放弃牌之后，玩家从旁边牌堆抽取一张牌，以开牌的方式放置于台面上，如果这张牌与台面上的牌能够配对，就必须将配对的两张牌收回到自己的点数牌堆中，如果与台面有不同配对方式，可自行选择要吃哪一张牌，不然就得放弃这张牌。

玩家回合结束时，若有因本次吃進的牌組成「役」，則可決定是否結束牌局，玩家可以选择喊出Stop结束游戏并结算他所获得的点数，也可以喊出Go继续玩以获得更多的点数。一旦玩家结束一局，就结算得分，并开新局。

###牌局結束

有三種方式：

• 其中一方喊停(喊停權力如上述)。喊停的一方則可以計算手上所有吃進牌的役，另一方則不能計算役。所以什麼時候喊停也是一個重要的策略。
• 雙方牌都已出完，但兩方最後一張牌都沒能吃進湊成役。這種結束方式，不管你吃了什麼牌，雙方就不能計算任何役。有些規則裡有「親權」，就是在這種狀況下，莊家直接得6點。
• 某方的最後一張吃進的牌恰好湊成役，也會強制結束。這時計算役的權力在手上無牌的一方(也就是最後一次的出牌方)。

##参考

• 花札
• Go-Stop
• 花札图片相册