日常使用备份,另外会单独拿出一列写写我用的 Userscript,类似微博去广告,豆瓣页面显示下载链接之类并不会存在这个列表里面。使用这一套扩展的好处有以下几点:
这是一款检查 Gmail 新邮件的扩展,推送及时,并且可以不离开当前页面查看邮箱内容。
官方地址:https://chrome.google.com/webstore/detail/checker-plus-for-gmail/oeopbcgkkoapgobdbedcemjljbihmemj
一款用来检查 Google Calendar 的插件,可以快速的预览 Google Calendar 中的事项,也可以直接创建 Event。
官方地址:https://chrome.google.com/webstore/detail/checker-plus-for-google-c/hkhggnncdpfibdhinjiegagmopldibha
上面两个扩展都是一位叫做 Jason Savard 的自由开发者开发的。因为我日常使用这两个网页应用比较多,自然的就找到了这两个扩展,免费版本的功能就已经可以满足 80% 需求,不过我还是小小的支持了一下作者,这可能是我付费的第一,二款 Chrome 扩展。
密码管理 LastPass 甚至可以用来共享密码~~
Trello 官方的扩展,可以很轻松添加卡片。
官方地址:https://chrome.google.com/webstore/detail/trello/dmdidbedhnbabookbkpkgomahnocimke
当然他是神器 Chrome 下,扩展是能够同步的,而脚本我找到了方法也能够同步~~文中有
Tampermonkey The most popular userscript manager for Blink-based browsers
在浏览页面的时候使用 Vim 的快捷键。
官方地址:https://chrome.google.com/webstore/detail/vimium/dbepggeogbaibhgnhhndojpepiihcmeb
曾经一度不能区别 Adblock(AB) 与 Adblock Plus(ABP), 后来大概了解了一下,可参阅我博客:http://www.einverne.tk/2013/08/ababp.html 至于后来,我只用 Adblock 了,为啥?我觉得 Adblock 更好~~文中有解释
目前已经替换成 Proxy SwitchyOmega
一个 PT 站点的管理工具,因为没有上架 Web Store 所以只能自己编译,加载安装。
Trello 的扩展,可以对每一个卡片进行计时。
官方地址:https://chrome.google.com/webstore/detail/plus-for-trello-time-trac/gjjpophepkbhejnglcmkdnncmaanojkf
用来绕过付费墙。
2020 年更新
目前我已经不再使用 Evernote,所以也放弃了使用 Evernote 的剪藏。现在推荐 WizNote 或者 Joplin 的剪藏。
Evernote,千万记住用国际版
购物比价
惠惠购物助手 网易出品】在您网购浏览商品的同时,自动对比其他优质电商同款商品价格,并提供商品价格历史,帮您轻松抄底,聪明网购不吃亏!
看名字
User-Agent Switcher User-Agent Switcher is a quick and easy way to switch between user-agents.
目前转用 GoldenDict,是操作系统级别的查词,所以也放弃了这个插件。
查词,wiki
扇贝网查词助手 扇贝网查词 Chrome 扩展,查词更方便。
批量下载图片
Image Downloader Browse and download images on a web page.
InoReader 不解释
RSS Subscription Extension (by Google) Adds one-click subscription to your toolbar.
放大图片
以图搜图
在新建的标签页上显示随机的美景。
Dream Afar New Tab An unexpected trip everyday by simply opening a new tab
这个扩展看上去从 WebStore 下线了,永久的停留在了 0.3.12_0 版本。
Hangouts 推荐使用 App 版本,看样子 Google 应该会重点发展 App 版的 Hangouts Always stay connected with the new desktop app for Hangouts on ChromeOS and Windows.
Google Keep - notes and lists Quickly capture what’s on your mind and share those thoughts with friends and family.
对于本博客的 Jekyll 修改全纪录
增加中文拼音支持 参考:
开源项目 Github
参考:
http://yizeng.me/2013/05/26/create-a-custom-jekyll-404-page/
This Jekyll introduction will outline specifically what Jekyll is and why you would want to use it. Directly following the intro we’ll learn exactly how Jekyll does what it does.
Jekyll is a parsing engine bundled as a ruby gem used to build static websites from dynamic components such as templates, partials, liquid code, markdown, etc. Jekyll is known as “a simple, blog aware, static site generator”.
This website is created with Jekyll. Other Jekyll websites.
Jekyll is a ruby gem you install on your local system.
Once there you can call jekyll --server
on a directory and provided that directory
is setup in a way jekyll expects, it will do magic stuff like parse markdown/textile files,
compute categories, tags, permalinks, and construct your pages from layout templates and partials.
Once parsed, Jekyll stores the result in a self-contained static _site
folder.
The intention here is that you can serve all contents in this folder statically from a plain static web-server.
You can think of Jekyll as a normalish dynamic blog but rather than parsing content, templates, and tags on each request, Jekyll does this once beforehand and caches the entire website in a folder for serving statically.
Jekyll is a parsing engine.
Jekyll does not come with any content nor does it have any templates or design elements. This is a common source of confusion when getting started. Jekyll does not come with anything you actually use or see on your website - you have to make it.
Jekyll is very minimalistic and very efficient. The most important thing to realize about Jekyll is that it creates a static representation of your website requiring only a static web-server. Traditional dynamic blogs like Wordpress require a database and server-side code. Heavily trafficked dynamic blogs must employ a caching layer that ultimately performs the same job Jekyll sets out to do; serve static content.
Therefore if you like to keep things simple and you prefer the command-line over an admin panel UI then give Jekyll a try.
Developers like Jekyll because we can write content like we write code:
The following is a complete but concise outline of exactly how Jekyll works.
Be aware that core concepts are introduced in rapid succession without code examples. This information is not intended to specifically teach you how to do anything, rather it is intended to give you the full picture relative to what is going on in Jekyll-world.
Learning these core concepts should help you avoid common frustrations and ultimately help you better understand the code examples contained throughout Jekyll-Bootstrap.
After installing jekyll you’ll need to format your website directory in a way jekyll expects. Jekyll-bootstrap conveniently provides the base directory format.
Jekyll expects your website directory to be laid out like so:
.
|-- _config.yml
|-- _includes
|-- _layouts
| |-- default.html
| |-- post.html
|-- _posts
| |-- 2011-10-25-open-source-is-good.markdown
| |-- 2011-04-26-hello-world.markdown
|-- _site
|-- index.html
|-- assets
|-- css
|-- style.css
|-- javascripts
_config.yml Stores configuration data.
_includes This folder is for partial views.
_layouts This folder is for the main templates your content will be inserted into. You can have different layouts for different pages or page sections.
_posts
This folder contains your dynamic content/posts.
the naming format is required to be @YEAR-MONTH-DATE-title.MARKUP@
.
_site This is where the generated site will be placed once Jekyll is done transforming it.
assets This folder is not part of the standard jekyll structure. The assets folder represents any generic folder you happen to create in your root directory. Directories and files not properly formatted for jekyll will be left untouched for you to serve normally.
(read more: https://github.com/mojombo/jekyll/wiki/Usage)
Jekyll supports various configuration options that are fully outlined here: (https://github.com/mojombo/jekyll/wiki/Configuration)
Content in Jekyll is either a post or a page. These content “objects” get inserted into one or more templates to build the final output for its respective static-page.
Both posts and pages should be written in markdown, textile, or HTML and may also contain Liquid templating syntax. Both posts and pages can have meta-data assigned on a per-page basis such as title, url path, as well as arbitrary custom meta-data.
Creating a Post
Posts are created by properly formatting a file and placing it the _posts
folder.
Formatting
A post must have a valid filename in the form YEAR-MONTH-DATE-title.MARKUP
and be placed in the _posts
directory.
If the data format is invalid Jekyll will not recognize the file as a post. The date and title are automatically parsed from the filename of the post file.
Additionally, each file must have YAML Front-Matter prepended to its content.
YAML Front-Matter is a valid YAML syntax specifying meta-data for the given file.
Order Ordering is an important part of Jekyll but it is hard to specify a custom ordering strategy. Only reverse chronological and chronological ordering is supported in Jekyll.
Since the date is hard-coded into the filename format, to change the order, you must change the dates in the filenames.
Tags Posts can have tags associated with them as part of their meta-data. Tags may be placed on posts by providing them in the post’s YAML front matter. You have access to the post-specific tags in the templates. These tags also get added to the sitewide collection.
Categories Posts may be categorized by providing one or more categories in the YAML front matter. Categories offer more significance over tags in that they can be reflected in the URL path to the given post. Note categories in Jekyll work in a specific way. If you define more than one category you are defining a category hierarchy “set”. Example:
---
title : Hello World
categories : [lessons, beginner]
---
This defines the category hierarchy “lessons/beginner”. Note this is one category node in Jekyll. You won’t find “lessons” and “beginner” as two separate categories unless you define them elsewhere as singular categories.
Creating a Page Pages are created by properly formatting a file and placing it anywhere in the root directory or subdirectories that do not start with an underscore.
Formatting
In order to register as a Jekyll page the file must contain YAML Front-Matter.
Registering a page means 1) that Jekyll will process the page and 2) that the page object will be available in the site.pages
array for inclusion into your templates.
Categories and Tags Pages do not compute categories nor tags so defining them will have no effect.
Sub-Directories If pages are defined in sub-directories, the path to the page will be reflected in the url. Example:
.
|-- people
|-- bob
|-- essay.html
This page will be available at http://yourdomain.com/people/bob/essay.html
Recommended Pages
Templates are used to contain a page’s or post’s content.
All templates have access to a global site object variable: site
as well as a page object variable: page
.
The site variable holds all accessible content and metadata relative to the site.
The page variable holds accessible data for the given page or post being rendered at that point.
Create a Template
Templates are created by properly formatting a file and placing it in the _layouts
directory.
Formatting Templates should be coded in HTML and contain YAML Front Matter. All templates can contain Liquid code to work with your site’s data.
Rending Page/Post Content in a Template
There is a special variable in all templates named : content
.
The content
variable holds the page/post content including any sub-template content previously defined.
Render the content variable wherever you want your main content to be injected into your template:
...
<body>
<div id="sidebar"> ... </div>
<div id="main">
{{content}}
</div>
</body>
...
Sub-templates are exactly templates with the only difference being they define another “root” layout/template within their YAML Front Matter. This essentially means a template will render inside of another template.
In Jekyll you can define include files by placing them in the _includes
folder.
Includes are NOT templates, rather they are just code snippets that get included into templates.
In this way, you can treat the code inside includes as if it was native to the parent template.
Any valid template code may be used in includes.
Templating is perhaps the most confusing and frustrating part of Jekyll. This is mainly due to the fact that Jekyll templates must use the Liquid Templating Language.
Liquid is a secure templating language developed by Shopify. Liquid is designed for end-users to be able to execute logic within template files without imposing any security risk on the hosting server.
Jekyll uses Liquid to generate the post content within the final page layout structure and as the primary interface for working with your site and post/page data.
GitHub uses Jekyll to power GitHub Pages. GitHub cannot afford to run arbitrary code on their servers so they lock developers down via Liquid.
The short story is liquid is not real code and its not intended to execute real code. The point being you can’t do jackshit in liquid that hasn’t been allowed explicitly by the implementation. What’s more you can only access data-structures that have been explicitly passed to the template.
In Jekyll’s case it is not possible to alter what is passed to Liquid without hacking the gem or running custom plugins. Both of which cannot be supported by GitHub Pages.
As a programmer - this is very frustrating.
But rather than look a gift horse in the mouth we are going to suck it up and view it as an opportunity to work around limitations and adopt client-side solutions when possible.
Aside My personal stance is to not invest time trying to hack liquid. It’s really unnecessary from a programmer’s perspective. That is to say if you have the ability to run custom plugins (i.e. run arbitrary ruby code) you are better off sticking with ruby. Toward that end I’ve built Mustache-with-Jekyll
Static assets are any file in the root or non-underscored subfolders that are not pages. That is they have no valid YAML Front Matter and are thus not treated as Jekyll Pages.
Static assets should be used for images, css, and javascript files.
Remember Jekyll is a processing engine. There are two main types of parsing in Jekyll.
And thus there are two main types of file formats needed for this parsing.
_layouts
folder and contain your blogs templates. They should be made in HTML with the help of Liquid syntax.
Since include files are simply injected into templates they are essentially parsed as if they were native to the template.Arbitrary files and folders. Files that are not valid pages are treated as static content and pass through Jekyll untouched and reside on your blog in the exact structure and format they originally existed in.
We’ve outlined the need for valid formatting using YAML Front Matter. Templates, posts, and pages all need to provide valid YAML Front Matter even if the Matter is empty. This is the only way Jekyll knows you want the file processed.
YAML Front Matter must be prepended to the top of template/post/page files:
---
layout: post
category : pages
tags : [how-to, jekyll]
---
... contents ...
Three hyphens on a new line start the Front-Matter block and three hyphens on a new line end the block. The data inside the block must be valid YAML.
Configuration parameters for YAML Front-Matter is outlined here: A comprehensive explanation of YAML Front Matter
The layout
parameter in the YAML Front Matter defines the template file for which the given post or template should be injected into.
If a template file specifies its own layout, it is effectively being used as a sub-template.
That is to say loading a post file into a template file that refers to another template file with work in the way you’d expect; as a nested sub-template.
Ultimately, Jekyll’s job is to generate a static representation of your website. The following is an outline of how that’s done:
Jekyll collects data. Jekyll scans the posts directory and collects all posts files as post objects. It then scans the layout assets and collects those and finally scans other directories in search of pages.
Jekyll computes data.
Jekyll takes these objects, computes metadata (permalinks, tags, categories, titles, dates) from them and constructs one
big site
object that holds all the posts, pages, layouts, and respective metadata.
At this stage your site is one big computed ruby object.
Jekyll liquifies posts and templates. Next jekyll loops through each post file and converts (through markdown or textile) and liquifies the post inside of its respective layout(s). Once the post is parsed and liquified inside the the proper layout structure, the layout itself is “liquified”. Liquification is defined as follows: Jekyll initiates a Liquid template, and passes a simpler hash representation of the ruby site object as well as a simpler hash representation of the ruby post object. These simplified data structures are what you have access to in the templates.
Jekyll generates output. Finally the liquid templates are “rendered”, thereby processing any liquid syntax provided in the templates and saving the final, static representation of the file.
Notes.
Because Jekyll computes the entire site in one fell swoop, each template is given access to
a global site
hash that contains useful data. It is this data that you’ll iterate through and format
using the Liquid tags and filters in order to render it onto a given page.
Remember, in Jekyll you are an end-user. Your API has only two components:
All the data objects available to you in the templates via Liquid are outlined in the API Section of Jekyll-Bootstrap. You can also read the original documentation here: https://github.com/mojombo/jekyll/wiki/Template-Data
I hope this paints a clearer picture of what Jekyll is doing and why it works the way it does. As noted, our main programming constraint is the fact that our API is limited to what is accessible via Liquid and Liquid only.
Jekyll-bootstrap is intended to provide helper methods and strategies aimed at making it more intuitive and easier to work with Jekyll =)
Thank you for reading this far.
Please take a look at or jump right into Usage if you’d like.