Jenkins 2.0 pipeline 学习

发布在 Devops

问题

长久以来,jenkins不能通过code管理config都是个缺点,我说的code管理不仅仅是配置保存的git/svn,而是每个jenkins的配置都能先进git/svn,
再有个jenkins的功能能获取config的更新,自动更新jenkins的job,这样jenkins的管理也就可控了,任何变更都可review和追溯,做到真正的code as

目的

大概简单试用了一下Jenkins 2.0的pipeline功能, 看了jenkinsfile和一些dsl的介绍,比想象中的功能要强很多.
所以想系统的学习一下,看看没有可能通过jenkinsfile直接替换job config的定义.

注释和共享

If you don’t like something, change it. If you can’t change it, change your attitude.
如果你不喜欢某事,那就去改变它。如果你不能改变它,那就改变你自己的态度。

玛雅·安吉罗

文章简介

the new stack 上一篇非常赞的文章,是对当先management layer的一览
http://thenewstack.io/devops-landscape-2015-the-race-to-the-management-layer/

虽然软文嫌疑比较大,不过写的还是非常全面易懂的,看完之后觉得很清晰,所以翻译一方面是自己加深理解,另一方面也希望对大家有点帮助
由于自己翻译水平实在是很差,还挺怕误导大家,发现不对的还请仔细看原文。

Kevin Fishner is director of customer success at HashiCorp, a leader in the DevOps marketplace. Author note: As an actor in the DevOps ecosystem, we certainly have biases.
This summary is our view of the current DevOps environment backed by our experiences and the experiences of our customers. It is not exhaustive.

作者简介,作为devops生态圈的从业者,我们肯定会有些曲解,这个总结是基于我们以及客户的经验,对当前devops生态圈的一些看法,并不彻底。

There has been so much activity in DevOps tooling and best practices in the past few months that it has become difficult to understand the current and future state of the industry. This summary is the outcome of explaining HashiCorp’s thoughts on the current DevOps landscape and future roadmap.

过去几个月有太多的活动是关于DevOps的tools和最佳实践,以至于我们很难理解当前和未来发展的状态,这个总结是HashiCorp公司对于devops概览和未来发展呢的一些解释

The Goal of DevOps is to Turn Application Code Into a Running Application Through a Repeatable, Safe Process

DevOps的目标是让application的code通过一个可重复安全的流程deploy到产品线变成运行的程序

“DevOps” as a term has many meanings, but for the purposes of this summary “DevOps” will be defined by its goal. Across organizations, the goal of DevOps is to turn application code into a running application through a repeatable, safe process.

DevOps是个有很多解释的术语,但是对于这篇总结,devops是通过它的目标来定义的。DevOps的目标是让application的code通过一个可重复安全的流程deploy到产品线变成运行的程序。

The Road to a Complete DevOps Management Layer: Configuration Management vs Immutable Infrastructure

通往完整的的DevOps Management层之路:配置管理 vs 不可变基础设施

Darcy: 感觉这翻译真不好整啊,比写代码难,这句英文那么通顺,换成中文就不知道该咋说了 #_#

There are two paradigms to provide a complete management layer for delivering applications

为了递交程序,有两种模式可以实现全面的管理层

Paradigm 1: Runtime Configuration.

In this view, the workflow from application code to running application is provision a server; configure the server with dependencies and application code; and monitor application and server health with scheduled, continuous configuration management runs.

模式1: 实时的配置

在这个视图, 从代码到运行的程序的工作流是:

  • provision一台server
  • 在这台server上安装进行系统配置,安装依赖和应用程序
  • 安装monitoring和一些cron job

Paradigm 2: Immutable Infrastructure.

In this view, the workflow from application code to running application code is to package the application into a deployable artifact, such as a Docker container, AMI, jar, etc; then provision the server in the likeness of that artifact; and finally, monitor application and server health. It is very important to note that immutable infrastructure and configuration management are not mutually exclusive. Configuration management tools are often used to configure build-time artifacts.

模式2:不可变基础设施

在这个视图里,从代码到运行的程序的工作流是将应用程序打包到一个可以直接部署的artifact中,比如Docker, Ami,jar等等,然后用这个artifact provision一台server,最终监控应用程序和健康状况
需要注意的是,配置管理不可变基础设施和不是互斥的,配置管理工具通常用来配置build阶段的artifacts

The key difference between immutable infrastructure and configuration management paradigms is at what point configuration occurs. In the immutable infrastructure view configuration happens at build-time, before deployment. In the configuration management view configuration happens at runtime, after deployment. To make a service change in the immutable infrastructure world, a new artifact is built, the old service is destroyed, and a new service is brought up using the new artifact. The service is never changed once it has been deployed, and thus why this paradigm is called “immutable” infrastructure. To make a service change in the configuration management world, the same server is updated with new service code. Again, these paradigms are not mutually exclusive, as configuration management tools are often used to help build build-time artifacts.

这两个模式最关键的区别在于配置何时发生:

  • 对于不可变基础设施,config是在build时做的,在deployment之前
  • 对于配置管理,配置是运行时做的,在deployment之后

对于这两个模式,当要对server进行改动时的区别:

  • 对于不可变基础设施,由于配置是发生在build time,那么理所当然,配置更改时,需要重新build artifact,因此老的server需要destroy掉,然后用新的artifact创建新的server,server在deploy后永远不会改变,所以这个方式被称作“不可变”
  • 对于配置管理,相同的server被新的配置管理的code更新。

再次重申,这两个不是互斥的,配置管理工具经常被用来构建artifacts

There’s arguably a nascent third paradigm, which treats servers as a generic resource pool which heterogeneous workloads are scheduled on top of. This technically fits under the immutable infrastructure paradigm, but is unique enough to define independently. This paradigm is in active development as Mesos, Kubernetes, Docker Swarm, and various other schedulers gain in popularity.

还有个可论证的刚出现的第三种模式,这个模式把server当做一个通用的资源池,这个池子顶层安排有各式各样的工作,这项技术适合不可变基础设施模式,但是足够特殊到可以单独定义。这个模式是正在活跃的开发中,比如Mesos,Kubernetes和Docker Swarm和多种其他产品等

The Management Layer is the Revenue Opportunity in DevOps

There are three basic layers in DevOps — infrastructure, tooling, and management:

管理层是DevOps是盈利点

基本上DevOps有三层: infrastructure, tooling 和 management

  • The infrastructure layer

    is comprised of technology that provides virtualization functionality to physical hardware to make compute, network and storage easily accessible. Example technologies are Amazon’s EC2 and Google Compute Engine in the public cloud arena, along with VMware and OpenStack in the private cloud arena.

infrastructure层主要提供虚拟化的基础设施,比如在公有云方面,有亚马逊aws,谷歌的GAE。在私有云方面,有openstack和vmware

  • The tooling layer

    is comprised of technologies that make access and configuration of the infrastructure layer an easier process. These tools still require functional knowledge of the underlying infrastructure. Examples here are the open source tools by HashiCorp, Mesos, Docker, Puppet, Chef, Jenkins and many, many more. It’s interesting that the majority of the tooling layer is comprised of open source software.

tooling层是为了简化接入管理和基础设施层的流程,这些工具仍然需要基本的基础设施知识,这里有些例子,比如HashiCorp, Mesos, Docker, Puppet, Chef, Jenkins和其他许多,有趣的是,这一层基本都是开源的。

  • The management layer

    is at the top and has the goal of abstracting away both the tooling and infrastructure layers into one common workflow for turning application code into a running application. An example end goal would be to just package your application — potentially as a Docker container, rkt container, jar or binary — and have it be able to run on any cloud or physical infrastructure. Ideally, no knowledge of the infrastructure itself is necessary and all the logic is held at the application level.

管理层是最上层,目标是将tooling and infrastructure layers 合并为一个通用的工作流,从而让产品代码可以转化成上线,举例来说,最终目标可能仅仅需要打包你的应用程序,比如docker容器,rkt容器,jar或者二进制文件,然后让它可以运行在各种cloud或者物理机上。理想状况下,不需要任何infrastructure相关的只是,只需要集中于应用层开发即可。

The infrastructure layer is facing a wave of competition and commoditization, and we now see the companies in this space trying to move up the stack into tooling and management. Amazon Web Services (AWS) has released tools like EC2 Container Service (ECS) and AWS CodeDeploy, which allow users to simply package their applications and ignore the infrastructure configuration and provisioning processes. Google Cloud Platform has similarly released Google App Engine and Google Container Service, as well as sponsoring open source projects such as Kubernetes. VMware has moved into tooling and management with heavy support for Pivotal’s Cloud Foundry. These tools make it easier for users to deploy applications and allow infrastructure providers to lock users into their platforms.

基础设施层经过一番竞争,地位已经确立,现在我们可以看到这些公司正在往tooling和management发展,aws最近发布了tool,比如EC2 Container Service (ECS)和AWS CodeDeploy,这些工具可以让用户简单的打包自己的应用程序,并且忽略基础设施配置和provision的过程。Google的云平台也有类似的GAE和Google Container Service,并且google也赞助了Kubernetes,Vmvare也做类似的事情。这些工具让用户能轻松的deploy应用程序,并且让基础设施提供商锁定住用户在自己的平台上。

The tooling layer is more difficult to monetize as the tools themselves solve pieces of the greater DevOps goal. It’s difficult to charge at enterprise levels for tools that package applications or provision infrastructure. Enterprises pay for tools that reduce costs through employee timesavings or material savings. These tools still require significant employee effort and are difficult to tie to material savings, thus are harder to monetize. It is certainly possible to monetize this layer through support and services; however, those are more difficult to scale.

Tooling层比较难作为商品区卖,针对devops庞大的目标,工具只是解决一部分的问题。很难从企业级层面解决整个部署过程,企业购买工具是为了减少成本,包括员工的时间成本和材料的成本,这些tool还是需要工程师很多的工作量,并且也很难节约成本,因此很难商品化,这个层次上赚钱,主要是通过support和提供服务。不过这是很难让利润扩大化的。

The management layer presents the most significant monetization opportunity as it presents a full solution for turning application code into a running application. The employee investment is significant in the implementation phase, but relatively minimal for upkeep. If the management level can get into material cost savings, such as reducing the size of server fleets, there will be tremendous opportunities for revenue.

管理层有巨大的盈利机会,因为它是一个完整的解决方案, 从而对于员工的投资更多的可以用于实现产品,更少的用于维护产品。如果管理层能节约成本,比如减少服务器的数量,那将是巨大的收入增长点。

DevOps companies are racing to the management layer; however, several tools are necessary to have a complete DevOps management offering.

DevOps的公司在管理层比赛,然后,很多工具对于完整的DevOps管理层还是必不可少的

Three Types of DevOps Companies: Infrastructure Providers, Configuration Management Companies, and Immutable Infrastructure Companies

Given that the management layer has the greatest revenue potential, the active players in the space are all battling to capture the opportunity. The interesting aspect of this battle is that the different types of companies in DevOps are approaching it from unique vantage points. These organizations can be categorized as either infrastructure providers, configuration management companies, or companies that favor immutable infrastructure. Amazon Web Services, Google Cloud Platform, OpenStack and VMware are the major players in the infrastructure provider space. Ansible, Chef, Puppet and Salt are the leaders in configuration management. HashiCorp, CoreOS, Docker and Mesosphere are the leaders in the nascent immutable infrastructure space.

三种DevOps的公司: 基础设施提供商, 配置管理公司和不变的基础设施公司

因为管理层有极大的盈利点,所以竞争激烈。有趣的是,不同类型的公司通过自己独有的优势来参与这场竞争,这些公司可以被分类为基础设施提供商,配置管理公司和提供不可变基础设施的。在基础设施提供商这层,主要有亚马逊AWS,Google Cloud平台,OpenStack和VMvare。配置管理方面,Ansible,Chef, Puppet和Salt是主要的领导者。在不可变基础设施方面,有HashiCorp, CoreOS, Docker和Mesosphere。

All of these companies must have solutions for infrastructure provisioning and application packaging or configuration in order to have a viable chance in winning the battle at the management layer. Historically, VMware is a great example of owning the entire tooling stack to win the datacenter virtualization market. If you look at the current product development across the companies, you can see that each is building tooling around these essentials. Chef has Chef Provisioning to provision infrastructure, and Chef configuration management to configure the application. HashiCorp has Terraform to provision infrastructure and Packer to package applications and build machine images. Docker has Docker Machine to provision infrastructure and Docker to package applications.

所有这些公司必须具备提供基础设施,程序打包或者配置管理才能在管理层有机会赢得这场战争,Vmare是个很好的例子,因为它具备具备完整的工具栈,从而赢得了数据中心虚拟化的市场。 如果看一看当前的这些公司产品的开发,你会发现开发tooling都是围绕这些要素. Chef有Chef Provision用来provision基础设施,chef configuration management来配置应用程序。HashiCorp有Terraform来提供基础设施,packer来打包程序,做成镜像,Docker有Docker Machine来provision基础设施,Dock来打包程序

These tools are then combined into a dashboard or common workflow to provide a management layer. For example, Mesosphere bundles Mesos, Marathon and Chronos to create the Mesosphere Datacenter Operating System. HashiCorp unites Packer, Terraform and Consul to create Atlas. CoreOS recently released Tectonic to bundle etc, rkt and flannel into a management layer. The infographic below shows the tooling portfolios for the major players in these categories and how those tools are starting to develop into a management layer.

这些tool会合并成一个dashboard或者通用的工作流,从而提供管理层。距离,Mesosphere整合了Mesos, Marathon and Chronos来创建Mesosphere数据中心操作系统。HashiCorp整合了Packer,Terraform和Consul来创建Atlas。 CoreOS最近发布了Tectonic来整合rkt和flannel到管理层。下面这幅图描绘了主要的竞争对手在不同类别中的各种tool,并且这些工具是怎么开始进入管理层的

Predictions for the Next 12 Months

未来12个月的预测

This summary identified infrastructure provisioning and application packaging or configuration as essential tools to build the management layer for DevOps. This conclusion leads to a few predictions:

通过这篇总结,得知为了建立一套DevOps的管理层,必须基础设施提供,应用程序打包或者配置的工具。以上结论引出下面的预测

All companies in the immutable infrastructure space will have tools to provision infrastructure, package applications, schedule applications and monitor applications.

不可变基础设施的公司将会有provision基础设施,打包应用程序,安排应用程序和监控应用程序

Configuration management companies will get the majority of enterprise budgets. It will take the immutable infrastructure companies more than 12 months to make significant progress with enterprises.

配置管理公司将会主要面向企业,它将比不可变基础设施公司在企业客户上取得巨大的进步。

AWS will grow by 50 percent plus and soak up a larger percentage of overall infrastructure budgets. The AWS tooling ecosystem is significantly more mature than competitors and more companies are moving away from on-premises datacenters.

AWS将会增长50%并且会占据更大的整个基础设施的市场份额。AWS的tooling生态系统明显比其他对手成熟太多,并且更多的公司放弃on-premises数据中心。

How to Choose a DevOps Management Layer

The purpose of this summary is to shed light on the crowded and opaque DevOps landscape. However, the obvious next question is, “How do I choose a DevOps management layer?” This question has many moving parts, and the best we can do is try to simplify some of the choices by answering a few questions:

如何选择DevOps管理层

这篇总结的目的是阐明拥挤和晦涩的DevOps生态。然后,明显的下一个问题是:“如何选择DevOps管理层呢”

Are two or more individuals working on your team’s infrastructure (part-time contributors are counted)?

  • If no, the two best options are either Amazon Web Services or Heroku. If no one has ops experience, Heroku is the best choice. If someone does have ops experience, AWS is the most full-featured option.
  • If yes, your team needs a way to manage the complexity of collaborating on infrastructure. Move on to the next question.

是否有两个或更多的工程师在你team里工作于基础设施(part-time的也算)?

  • 如果否,最佳的两个选择是AWS或者Heroku。 如果没人有经验,Heroku是最佳选择。如果有人有ops的经验,AWS是最全面的选择。
  • 如果是,你的团队需要一方方法来管理复杂的基础设施方面的协作,继续下一个问题

Do you want to do build-time or runtime configuration?

  • If you want to do runtime configuration, use a configuration management tool such as Ansible, Puppet, Chef or Salt. If you want agent-based configuration management, use Puppet or Chef. If you want ssh-based configuration management, use Ansible or Salt.
  • If you want to do build-time configuration, which means building images and immutable infrastructure, use Atlas by HashiCorp, Mesosphere, Tectonic by CoreOS, or Docker Hub. Move on to the next question to select between these options.

你是像用build-time还是实时的配置管理

  • 如果你想用实时的配置管理,用Ansible, Puppet, Chef或者Salt等配置管理工具。如果想用基于agent的方式,用Puppet或者Chef。如果想用基于ssh的,用Ansible或者Salt.
  • 如果你想用build-time的配置管理,创建镜像并且是不可变基础设施,用hashicorp的Atlas,Mesosphere, Tectonic by CoreOS, or Docker Hub. 对于这些选择,继续往一个问题。

Do you want to automate the infrastructure provisioning process?

  • If yes, Atlas by HashiCorp is the only option. Atlas uses Terraform to layout infrastructure as code and automate the provisioning process. Docker does have Docker Machine to provision Docker hosts; however, it is currently a command-line tool that only manages hosts, not a complete infrastructure.
  • If no, any of the options by HashiCorp, Mesosphere, Docker, and CoreOS can be considered. However it is difficult to deploy applications without a means to automate and reliably provision infrastructure.

是否想自动化构建基础设施的流程

  • 如果是,(这条不想翻译了,太软文了)
  • 如果不是,任何一项都可以。然后也是软文

注释和共享

Better to do something imperfectly than to do nothing flawlessly.
做事不完美,总比完美地不做事要好。

罗伯特·舒勒

介绍

首先大概介绍下powerline, 作为插件,可以用在bash,zsh,vim,tmux等等上,然后就会有很漂亮的状态栏

zsh里的效果

vim效果




安装使用

安装

1
sudo pip install powerline-status

使用

详情可以参与官方文档
https://powerline.readthedocs.org/en/master/

取到自己的repository_root,后面配置都要将repository_root替换成自己的Location

1
2
3
4
5
6
pip show powerline-status                                             
---
Name: powerline-status
Version: 2.2
Location: /Library/Python/2.7/site-packages
Requires:

vim

vim 有些需求:
https://powerline.readthedocs.org/en/master/usage.html#vim-plugin-requirements

在vimrc里加一行即可

1
set rtp+={repository_root}/powerline/bindings/vim

zsh

在zshrc里加一行

1
. {repository_root}/powerline/bindings/zsh/powerline.zsh

trouble shooting

如果遇到python locale的错误,把下面两行加到/etc/bashrc里
1
2
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
如果箭头显示不正常,需要安装一下powerline的font

请参考:
安装powerline的字体用于其他编程工具使用

注释和共享

介绍

今天在弄zsh皮肤的时候,接触了powerline,然后发现里面带的字体很适合编程使用,非常漂亮,虽然mac自带的字体已经够多了,而且很不错,不过用了这么久了难免审美疲劳,玩玩新字体很是爽。

了解powerline ->
美化自己的命令行环境,增加漂亮的状态行,安装使用powerline

这个帖子的主题主要是安装powerline的字体们,有兴趣了解更多powerline配置的,可以参阅文档:
https://powerline.readthedocs.org/en/latest/

演示

所有字体的演示参考下面:
https://github.com/powerline/fonts/blob/master/samples/All.md

安装使用

1
2
git clone https://github.com/powerline/fonts
./install.sh

安装log里会有安装的目录,到目录里点击安装字体即可

这是我使用了其中两个字体,pycharm的效果

有兴趣的同学可以试试

注释和共享

简介

大而全的入门书籍,

笔记

ansible的来历

最早来源于一部科幻小说,是一种超光速长距离的通讯设备,后来这个名字在《安德的游戏》中被借用,就是用来操作千军万马对抗外星生物的控制设备,这么看来这个名字还是很贴切的。

第一章

  • YAML is to JSON what Markdown is to HTML.
  • Ansible是push的,puppet是pull的。不过ansible也支持pull模式的,用ansible-pull,我在14年底前差不多用了2年多的puppet,我都没觉得pull模式有什么好,反而最后都做成了masterless的puppet用法。
  • 金句, Alan Kay’s maxim: “Simple things should be simple, complex things should be possible.”

注释和共享

简介

个人觉得在阅读这本书前,最好读一些基础的ansible书籍,看过一些例子,然后自己写过一些ansible的playbook,对playbook有初步的了解,同时问题也有一些。
这本书是着重阐述怎么去设计一个结构良好,功能完善的playbook,内容还是不错的,官方文档或者入门书籍着重介绍ansible的各个功能,但是对如果组织使用这些功能探讨的不会太深。
再没看这本书之前,也许你和我一样,写出的playbook的role都只有main.yml文件,这本书是指导我们应该怎么样正确的规划我们的infrastructure,从而然后写出可复用的,模块化的playbook

读后感

这本书从一个简单的例子,最直观的方式完成一个playbook,后续的章节,围绕这个例子做各种各样的重构。所以前后一贯,再看到后面的章节的时会不断的对之前的做法进行反思。 有些pragmatic的风格。
此外,例子中的output截图配上注释非常直观,便于理解。
最喜欢的是第九章,因为自己刚写了没多久的playbook,也一直考虑多环境的playbook该如何设计,并且dev和prod不会互相影响,又方便merge code,我觉得第二种方案实在太爽了,这里就不书透了,如果有相同问题,可以找来重点看看。

笔记

  • pre-tasks和post-tasks可以用来在执行之前关闭和打开nagios
  • delegate_to可以用来做从lb摘除web server之类的动作
  • 在playbook里指定serial参数用来限定每次执行的server个数
  • wait_for用来检查状态很用帮助
  • 将安装和配置分离,用main.yml import install.yml 和 configure.yml, 让task 模块化
  • 如果要用command/shell等模块,为了保持幂等性,可以使用creates和removes flag
    • 如果command会创建一个文件,可以用creates flag来测试这个文件,如果已经存在,则不再做
    • 如果command的用途不是创建文件,也需要创建一个flag用来保持幂等性。
  • 变量定义, ansible可以定义变量的地方实在是很多,书中有一节梳理的非常清晰
  • 多级变量需要merge的话,得打开hash_behaviour=merge,参见下面的例子

多级变量 merging hashes

比如在default里定义了

1
2
3
4
redis:
config:
port: 6379
url: xxxx.redis.xxxx.com

在 vars里定义了
1
2
3
redis:
config:
port: 4567

按照ansible default的行为,最终会用vars的replace default的,所以结果是vars的

1
2
3
redis:
config:
port: 4567

如果想得到merge的结果

1
2
3
4
redis:
config:
port: 4567
url: xxxx.redis.xxxx.com

需要把配置改成
1
2
# /etc/ansible/ansible.cfg
hash_behaviour=merge

jinja2的if else写法

1
2
3
4
5
6
7
{/% if condition %/}
do_some_thing
{/% elif condition2 /%}
do_another_thing
{/% else /%}
do_something_else
{/% endif /%}

看了书里的例子,这个写法可读性比较差,实在搞不定再考虑这种写法吧。

用ansible-galaxy 生成role的基本骨架,这样就省得自己去建role需要的各种目录了

1
ansible-galaxy init --init-path roles/ dynamod
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
dadeMacBook-Pro:zoom_xmpp darcy$ ansible-galaxy init --init-path roles/ dynamodb
- dynamodb was created successfully

dadeMacBook-Pro:zoom_xmpp darcy$ cd roles/dynamodb/
dadeMacBook-Pro:dynamodb darcy$ ll -R
total 8
-rw-r--r-- 1 darcy staff 1328 Sep 4 15:44 README.md
drwxr-xr-x 3 darcy staff 102 Sep 4 15:44 defaults
drwxr-xr-x 2 darcy staff 68 Sep 4 15:44 files
drwxr-xr-x 3 darcy staff 102 Sep 4 15:44 handlers
drwxr-xr-x 3 darcy staff 102 Sep 4 15:44 meta
drwxr-xr-x 3 darcy staff 102 Sep 4 15:44 tasks
drwxr-xr-x 2 darcy staff 68 Sep 4 15:44 templates
drwxr-xr-x 3 darcy staff 102 Sep 4 15:44 vars

./defaults:
total 8
-rw-r--r-- 1 darcy staff 33 Sep 4 15:44 main.yml

./files:

./handlers:
total 8
-rw-r--r-- 1 darcy staff 33 Sep 4 15:44 main.yml

./meta:
total 8
-rw-r--r-- 1 darcy staff 2373 Sep 4 15:44 main.yml

./tasks:
total 8
-rw-r--r-- 1 darcy staff 30 Sep 4 15:44 main.yml

./templates:

./vars:
total 8
-rw-r--r-- 1 darcy staff 29 Sep 4 15:44 main.yml

注释和共享

#####背完第一本单词书
纪念一下,虽然很慢,花了284天,但是shanbay的强制体验和不断的循环让背过的单词还是比较牢固的。

###背完的第一本是雅思高频词
first_word_book

###扇贝账号概况
shanbay_profile

###一共花了284天,今天的扇贝每日一句我也挺喜欢
284_days

#####我对扇贝的理解
我觉得扇贝很多地方像早期的豆瓣,不温不火,低调踏实。
扇贝的英语学习产品没啥花哨的功能,有的只是实用。
然而最别具一格的就是强制性用户体验,比如:
任务不完成就不可以打卡。
任务差一点没完成也无法补救。
而打不了卡很多相关的任务也就失败了,比如连续多少天打卡的勋章之类的。
再比如,花了钱买了灵格斯字典,你会发现背单词就变成英翻译英了,就!没!中!文!了!!WTF!!!
花了钱反而不爽了,一点都不迎合用户体验,这简直没法玩了,扇贝的解释就是,如果你都选择英文字典了,那你还要看中文解释干什么呢?你必须要全英文的单词环境才可以啊。

这点设定其实蛮有逼格的,假设说扇贝卖这字典,中文照显示,那么肯定会比现在买的人多。而扇贝似乎并不是优先考虑利润,按照这个逻辑,扇贝的意思大概是,你假如是个懒蛋,打卡完不成,又没决心脱离中文学英文,那你哪凉快哪呆着吧。
而真正努力好学的人呢?每天做任务基本钱又够花!!!WTF,扇贝看来压根就没想过赚勤奋努力好学生的钱。而懒蛋的钱又不惜的赚,这设定屌爆了!

因为各种强制的设定,导致扇贝众也是各种强硬,比如你加入扇贝小组,你会惊奇的发现,一天忘了被单词你就会被剔除出小组,之前的积分也拜拜了。

我不是自来水,花了近300天在这个平台上学习和体会他们的设计理念,让我不推荐也不行了,因为我确实很尊敬扇贝,在浮躁年代下一个很有逼格的学习网站。

注释和共享

vim养成计划

发布在 Tech for Fun

There will be many temptations in this new world. But as long as you remain brave, truthful and unselfish, you will not fail.

新的世界里会有许多诱惑,只要你一直勇敢、诚实、无私,你就不会失败。

——《童话镇》

开篇

如果参加过各种编程比赛的同学,肯定对全键盘编程这个限定条件会有记忆。这个条件是不允许在编程时使用键盘以外的输入设备,比如触摸板和鼠标都是禁止的。
这个时候熟练vim的同学就会如鱼得水了,那大家肯定会反问,熟悉vim就是为了这个?当然不仅仅是!但是我们可以反过来想,比如code retreat这样影响比较广泛的编程活动,为什么会有这样的限定条件呢?肯定不是闲着蛋疼,那么就自己而言,我可以大概说说玩vim的好处。

有兴趣的可以看看coderetreat关于no mouse的限定条件。
http://coderetreat.org/facilitating/activity-catalog

  • Geek精神,emacs和vim不熟练一个都说不过去。
  • 本身自己是个Devops工程师,每天ssh在各种机器上干活,以前有一阵不用vim,但是用一个自我感觉良好的方法,所有的文本编辑在本地各种狂帅霸裤的现代编辑器上搞定,然后到远程机,vi -> 9999999dd -> Cmd +V -> ZZ
  • 效率高,虽然学习曲线陡峭,但是越熟练越快,有些地方是现代编辑器无法比拟的,比如现代编辑器都是通过鼠标定位,鼠标键盘来回切换来工作,而vi一方面会省略掉这个RTT,另一方面一眼就能定位的一些位置用5k,6j, 3w, fk之类的跳转快捷很多。

缘由

完事皆有因,其实自己下决心用好vim还是因为一些触动,如前所述,2,3年以前,我很喜欢自己那套9999dd+ctrl v,那么运维的工作经常会share屏幕大家一起工作,我当时对自己这套做法还觉得不错。并且我并不是不会用,而是懒得用罢了。
有一日,和一个同事远程协作产品线上trouble shooting,看他用emacs无比娴熟,效率其高,真是无比羡慕,并且同时觉得自己很挫。
后来还下定决心也要把emaces练到他的程度,无奈试了一阵,觉得难度太大,放弃了,好在vi多少有些底子,起码正常编辑没问题,就专心把vim用好吧

养成

如果让我推荐怎么练好vim,我觉得简单可以概括成一句话,随处都用vim。

  • 比如我现在写这篇博客,虽然是在Idea编辑器里,但是用了vim的plugin,实际效果和vim没啥区别。
  • 我也是evernote用户,但是不在客户端里写note,有个替代方案叫geeknote,然后打开终端就可以用vi写evernote,有兴趣可以试试: http://www.geeknote.me/
  • 写邮件可以用Vmail或者mutt,https://linuxtoy.org/archives/vmail.html
  • 其他文件,如果需要云存储的,可以直接到网盘目录去vi

Tips

  • 首先丢掉上下左右键,移动词别忘了用w, b
  • 用Ctrl+c 替换Esc
  • 复杂选文件用:Sex

资源

下面这个链接可真是够宅的。。。
http://blog.jobbole.com/tag/vim/

vim的各种cheatsheet
http://pan.baidu.com/s/1sjE5bjR

注释和共享

Darcy Song

author.bio


author.job