Posts on WKLKEN THINKING

AI 重构的那些 bad case

Wed, 27 May 2026 23:00:00 +0800

以下 case 使用模型均为 gpt5.5 xhigh

TLDR

当前最厉害的模型之一

做事靠谱吗？大部分靠谱
会有幻觉吗？会
会偷懒取巧吗？会
会为了做而做吗？会
会生成屎山代码吗？会
会使得整体项目更复杂还是更简单？看你怎么用

所以

我们要 review 生成的代码吗？要
当前能做到交给 Agent 一个任务，之后看都不用看直接合并吗？暂时不能，大概率翻车
要为代码负责吗？废话，你的 PR，你的代码，你的锅

建议：

复杂任务尽量用最好的模型
Agent 说 job done 之后，用另一个模型交叉 review 【重点：交叉验证，不同模型能力、关注点不一样】
提交 PR 前后，人工 review 【重点：为自己的产出负责】
对于 review comment（不管是来自于 Agent，还是人），先阅读，反向读代码，理解后做判断【重点：不要让 Agent 直接去修 comments，修多了或修少了都有可能，没有自己的理解和判断，永远积累不到经验】

过度防御

某些模型（gpt) 或者某些场景下， Agent 总是过度防御

例子：命名 view 层有限制大于零，调用链上每一层都防御【大概率是没读到，没理解上下文】

代码能用是能用，可读性非常差

无意义到包装或转发

Proxy function or methods

@staticmethod
def wait_release_done(release_history_id: int, timeout: int = DEFAULT_WAIT_RELEASE_TIMEOUT) -> str:
    return wait_release_done(release_history_id, timeout=timeout)

这个更过分，先封装成对象 - 在 proxy method 中再转成id

Proxy constants

甚至，模块 export 代理

不会删掉没有调用的dead code

只要能解决问题，什么方法都行

lazy import to avoid cycle import

其实应该 break the cycle

丢失掉所有有用的注释

怎么写着写着，注释越来越少，干净又整洁

超级复杂的实现 vs 看似取巧的变通

你告诉它这个字段会导致一个注入，然后，它就去解决这个注入

增加一个非常复杂的 escape 方法 vs 舍弃掉这个字段

你告诉它这个 version 有个注入，它专心去解决注入，但是实际上这只是一个版本号，合法就不会出现注入问题

解决注入 vs 校验合法性

相对保守不改变函数的`协议`带来的复杂度

半吊子的封装

嗯，复杂的逻辑封装成函数了，但是，这两个 except 是怎么回事？

LockTimeout 和 ReleaseError 实际上也属于 release_to_stages 的上下文

看一个更典型的，你或许不会犯第二次错误，但是 Agent 会

小心 noqa

如果我的变更命中的你的规则，那么一定是你的规则有问题，改一下绕过去好了

规则存在的目的并不是为了被破坏

注：这是个proxy method，最终删掉了

下面这个就厉害了，为了解 import 顺序导致的循环引用，偷偷塞了一个（其实我第一轮都没注意到，review 其他 noqa 的时候搜到的）

应该去解决循环引用，而不是通过 import 顺序绕过循环引用，然后通过 noqa 绕过import order 检查

ai 编程实践

Mon, 11 May 2026 23:00:00 +0800

很久没有动笔写 blog 了，想不到再更新已经到了 AGENTS 时代了。

去年开始，经历过了疯狂vibe-coding 的时期（一堆玩具，都是没用过的技术栈），也养过小龙虾（现在还火吗？），然后研究过 MCP（我们的产品上加了这个能力），然后是现在的 cli + skills。

从 github copilot 第一批用户，到 cursor 自费订阅（tab-tab)，再到 sonnet 出来之后大跃进，经历了一个月左右的 AI 额度自由（想念opus），再到后面不自由自费订阅了 codex pro（稳重的 gpt 5.4/5.5）。

也焦虑过一段时期，疯狂刷推，看各种项目、文章，让小龙虾帮忙做各种汇总。

然后，到现在，形成了相对稳定的工作流和生产力。

5 天左右的 SDD，做完了一个生产级别的 cli，放原先手工时代至少半个月。 3 天左右的大规模重构，完成了之前接近一个月的重构工作量。这是以前想都不敢想的生产力提升。

虽然个人生产力提升很多，但是整体项目运作的摩擦还是很大的，毕竟沟通、基建等还有待改进。

下面就简单介绍下一些确定的实践经验。

1. 深度使用一个 agent

虽然我们最好不要绑死在某个 Agent、某个模型或某个工具上，但是提升生产力的大前提是，磨刀。

而最好的刀，一般是御三家几个头部。

推荐 claude 及 codex； claude 更爽，codex 更稳，个人偏好 codex。

建议走官方订阅。（不建议走中转，太黑盒）

目前主要是用 VSCode Codex 插件 + Codex app. 然后少量用 Cursor(开发体验最好，就是太贵)，一些简单执行类用的 claude+自定义模型；

不差钱的话， cursor 的体验胜过 VSCode Codex 插件（每次切回去用一段时间都得回来骂两句）

这里用好它，指的是深度阅读官方文档，阅读其他人的实践文章，了解各种配置，获取自己需要的配置，定制自己的配置。（让我想起了当初折腾vim）

2. 创建一个自己的 .agents 仓库

创建一个仓库，私有的，维护到 git 的，然后 clone 到你的所有机器

我们的目标

所有机器使用相同的配置，
并且通过makefile将仓库中差异化配置通过软链到各个 agent 目录，从而抹平所有 Agent 的使用体验。
配置是可以持续迭代的，某个机器上优化更新后，可以同步到其他所有的机器。

例如，.agents/skills目录，codex 是认的，但是claude 不认，那就做一个软链。个性化的 AGENTS.md，软链到 .codex下，以及软链成CLAUDE.md

目前市面上vibe-coding 出来各种管理工具，我觉得是没必要的，最原始的git，让 Agent 帮你去处理，是定制化最高的方式。

3. 创建自己的 AGENTS.md

如果不知道写什么内容，参考 https://github.com/forrestchang/andrej-karpathy-skills 这个项目，直接拷贝放进去。

如果使用 codex，软链到~/.codex/AGENTS.md

然后，你可以在使用过程中，持续优化这个 AGENTS.md，应该怎么沟通，用什么语气，翻过的错误等等

4. 选一个基础工作流

最底层原子skill

目前有很多工作流，我们现在需要安装上一批适合自己的、原子的 SKILL。

注意，不要装 SDD 这种核武器，要装瑞士军刀这种轻量并且相对全的

加入方式： git submodule 加进来，软链到skills 【这样能定时更新】

目前重度使用 superpowers，如果你觉得某个工作流触发比较烦，那么可以在 AGENTS.md 中优化它。（触发规则）

例如：如果是小的修改、bugfix，请不要调用 tdd

5. 挑选一批适合自己的skill

最底层原子 skill

市面上skills 非常多，例如code-review 你估计能找到几十上百个。

但是，符合自己工作方式、风格的 SKILL，才是最合适的。

目前比较火的集合

https://github.com/anthropics/skills
https://github.com/openai/skills
https://github.com/mattpocock/skills 【个人很推荐】

加入方式： git submodule 加进来，仅挑选想要的skill，软链到skills 【这样能定时更新】

6. 创建自己的skill

上层skill

使用 $skill-creator 可以创建自己的 SKILL

可以在基础工作流之上，定制自己的工作流（自己的 SKILL，依赖底层原子 SKILL）
1. 例如，small-steps-refactor可以依赖 superpowers 里面的writing-plans和executing-plans （我用这个 SKILL 重构了近三万行代码，单测+可 review 的小步重构使得巨大的重构变得可控）
2. 例如，fix-bug可以依赖 superpowers 里面的systematic-debugging 以及自己的git-commit
也可以是全新的 SKILL

可以导出自己所有同 AGENTS 的对话记录，让 Agent 分析那些重复的，反复出现的，形成模式的对话，然后创建成 SKILL。

你还可以考虑把那些繁琐的日常行为，转换成 SKILL。

特别是那些被动触发的 SKILL，效果非常好，例如auto-load-env 在 Agent 找到不到环境的时候自动触发，加载正确环境，那么意味着未来的所有遇到这种场景，Agent 都能自动解决，无需询问、打断。

7. 安装 cli + skill

个人偏好 cli + SKILL，厌恶MCP

那么，此时你可以通过各种各样的 CLI，扩展你的 Agent 能力

例如 playwright-cli

8. 持续迭代它

Agent 不好用，去优化 agent 配置
对话或各种交互、服从性不好，去优化 AGENT 配置
不断添加、优化、淘汰 SKILL
不断通过 cli 扩展 Agent 的能力，配合 SKILL 做更为复杂的事

慢慢的，我们的工作流变得非常高效，与 Agent 配合非常默契，甚至大部分时候能一波流完成目标。

那么，你有了一份适合自己的，可持续迭代的配置。

或者说，你有了一份 数字的你, 当你把他放入openclaw 或 hermes 的时候，他就能用你的行事风格以及标准，做你能做到的事情

（至于会不会被 ai 替代掉，我们后面再讨论）

9. 啰嗦两句：保证交付质量

不管是 Agent 还是我们自己写的，我们需要保证交付的质量

AI 带来的质量方面的好处：

写单测不再是负担，并且可以达到非常恐怖的覆盖率，给重构予信心
集成测试、自动化测试，都可以轻易地验证
debug 非常之快

但是：

AI 是有幻觉的（屎山也能给你写 100% 覆盖率单测，所以不能轻信）
模型差异是个的代码质量差异非常大
AI 无法一步到位解决存量项目中的复杂度

你需要

选好模型，写好prompt，把控好处理流程
review 自己的代码【不要超出你的掌控】
做好自测

写在最后

其实，由于这个浪潮来的太快，信息过载，进而导致人非常焦虑，漫天的工具、配置、最佳实践，一个又一个的热点，导致整个人非常浮躁。巨大的不确定性的情况下，我们需要去寻找确定性。

而以上，就能给你一份确定性，而且是越用越聪明，越用越有信心的积累。

或许未来有一天 Agent 强大到这些也变得没有意义，但是在当下，这个能给我们信心。

apisix 中的 lrucache

Sat, 28 Sep 2024 00:00:00 +2000

基于 3.10.0 版本

apisix 的 lrucache 封装了 resty-lrucache 及 resty-lock

机制

代码不多，逐行分析

先看下新建一个 lrucache时支持的选项 opts

type  类型， 如果是插件是 plugin
count 容量， 如果没有设置， 类型为 plugin 的默认 count=8，其他类型默认 count=1024
ttl   过期时间，如果没有设置，类型为 plugin 默认 ttl=5min， 其他类型默认 ttl=60min

release  缓存命中，但是val.version不是预期的，会调用hook函数, 做一些额外的行为
invalid_stale    是否允许获取已过期的值， key 对应value过期，但是val.version是一致的，是的话，会重新将这个已过期值设置到 lrucache中 （即，会命中缓存，不会调用 create_obj_fun
serial_creating  确保缓存对象是串行创建的，即创建流程中会上锁避免竟态场景下创建同一个对象

new_lru_fun

local function new_lru_fun(opts)
    -- 选项
    local item_count, item_ttl
    if opts and opts.type == 'plugin' then
        item_count = opts.count or PLUGIN_ITEMS_COUNT
        item_ttl = opts.ttl or PLUGIN_TTL
    else
        item_count = opts and opts.count or GLOBAL_ITEMS_COUNT
        item_ttl = opts and opts.ttl or GLOBAL_TTL
    end

    local item_release = opts and opts.release
    local invalid_stale = opts and opts.invalid_stale
    local serial_creating = opts and opts.serial_creating
  
    -- 创建一个 lrucache 对象， 大小为 item_count
    local lru_obj = lru_new(item_count)

    -- 返回一个fun， 其参数为 key, version, create_obj_fun, 以及 create_obj_fun 的参数
    return function (key, version, create_obj_fun, ...)
        -- 非 serial_creating ，或者 phase 不是 ssl_session_fetch、ssl_session_store、rewrite、access、content、timer 之一
        -- nginx.get_phase: https://github.com/openresty/lua-nginx-module#ngxget_phase
        if not serial_creating or not can_yield_phases[get_phase()] then
            -- 获取缓存
            local cache_obj = fetch_valid_cache(lru_obj, invalid_stale,
                                item_ttl, item_release, key, version)
            -- 命中直接返回
            if cache_obj then
                return cache_obj.val
            end
      
            -- 主意，这里没有上锁； 重复调用 create_obj_fun 以及 lru_obj:set 是允许的
            -- 没上锁的好处：1. 不必要的复杂度 2. 性能

            -- 未命中，获取数据，设置缓存，返回
            local obj, err = create_obj_fun(...)
            if obj ~= nil then
                -- 注意这里 set 的时候，值 = 对象+version
                lru_obj:set(key, {val = obj, ver = version}, item_ttl)
            end

            return obj, err
        end

        -- 获取缓存
        local cache_obj = fetch_valid_cache(lru_obj, invalid_stale, item_ttl,
                            item_release, key, version)
        -- 命中，直接返回
        if cache_obj then
            return cache_obj.val
        end

        -- 否则，进入 获取-设置流程
        -- 1. 获取 lock
        local lock, err = resty_lock:new(lock_shdict_name)
        if not lock then
            return nil, "failed to create lock: " .. err
        end

        -- 2. 上锁
        local key_s = tostring(key)
        log.info("try to lock with key ", key_s)

        local elapsed, err = lock:lock(key_s)
        if not elapsed then
            return nil, "failed to acquire the lock: " .. err
        end

        -- 3. 再次获取缓存： 避免从 获取缓存失败 到 上锁成功 这段时间内 其他地方已经获取缓存并成功
        cache_obj = fetch_valid_cache(lru_obj, invalid_stale, item_ttl,
                        nil, key, version)
        --- 3.1 命中则解锁，返回
        if cache_obj then
            lock:unlock()
            log.info("unlock with key ", key_s)
            return cache_obj.val
        end
       
        -- 4. 调用 create_obj_fun， 获取数据
        local obj, err = create_obj_fun(...)
        --- 4.1 获取成功，设置
        if obj ~= nil then
            lru_obj:set(key, {val = obj, ver = version}, item_ttl)
        end
        -- 如果获取成功， obj正确, err=nil； 如果获取失败，obj nil, err!=nil
    
        --- 5. 解锁
        lock:unlock()
        log.info("unlock with key ", key_s)
        
        -- 6. 返回
        return obj, err
    end
end

说明：

如果 opts.serial_creating = true，在lrucache流程中会上锁，如果 opts.serial_creating = false或者没有设置，则不会上锁
如果当前的 phase nginx.get_phase() 不是 ssl_session_fetch、ssl_session_store、rewrite、access、content、timer 之一（can_yield_phases，即属于不能 yield的 phase）, 例如 rewrite 阶段、log 阶段等，那么 lrucache流程也不会上锁；
1. 即，如果配置了 serial_creating = true, 当前 phase 也必须是 can_yield_phases: ssl_session_fetch、ssl_session_store、rewrite、access、content、timer，才会是附带上锁的逻辑
2. 如果phase被yield，那么必须上锁，不上锁的话，执行一半被yeild，当恢复执行时，获取的缓存对象可能不是最新，使用过程中会发现缓存被设置回旧的值。

大部分的使用场景，都只设置了 count/ttl/type，所以使用时几乎都没有上锁

fetch_valid_cache

local function fetch_valid_cache(lru_obj, invalid_stale, item_ttl,
                                 item_release, key, version)
    -- 从 lru 中获取 key 对应值
    --- 如果存在且未过期， obj非空是， 否则obj = nil
    --- 如果存在但过期了， obj=nil， stale_obj != nil
    local obj, stale_obj = lru_obj:get(key)
    -- 1. 命中，并且 version 一致，直接返回
    if obj and obj.ver == version then
        return obj
    end
    
    -- 2. 没有命中（如果有已过期的值， stale_obj非空），或者 version 不一致
  
    --- 2.1 如果配置允许使用陈旧的值， 并且缓存中存在过期的值，且 version 一致
    if not invalid_stale and stale_obj and stale_obj.ver == version then
        -- 重新设置为陈旧的值，并且返回
        lru_obj:set(key, stale_obj, item_ttl)
        return stale_obj
    end

    -- 没有命中
    --- a. key 对应 value 不存在, 此时 obj = nil
    --- b. key 对应 value 存在，但是已过期，没有配置 invalid_stale = true， 此时 obj = nil
    --- c. key 对应的 value 存在，但是 version不一致, 此时 obj != nil
  
    --- 2.2 如果配置了 item_release， 并且 obj 非空(value存在但是version不一致)，调用 item_release（是一个 hoook?)
    ---- 目的是，发现 version不一致，主动调用缓存主动刷新接口？
    ---- 目前项目中没有调用点
    if item_release and obj then
        item_release(obj.val)
    end

    --- 2.3 返回 nil
    return nil
end

接口

lrucache中提供了一个快捷创建插件 lrucache的函数

plugin_ctx

---
--  Cache some objects for plugins to avoid duplicate resources creation.
--
-- @function core.lrucache.plugin_ctx
-- @tparam table lrucache LRUCache object instance.
-- @tparam table api_ctx The request context.
-- @tparam string extra_key Additional parameters for generating the lrucache identification key.
-- @tparam function create_obj_func Functions for creating cache objects.
-- If the object does not exist in the lrucache, this function is
-- called to create it and cache it in the lrucache.
-- @treturn table The object cached in lrucache.
-- @usage
-- local function create_obj() {
-- --   create the object
-- --   return the object
-- }
-- local obj, err = core.lrucache.plugin_ctx(lrucache, ctx, nil, create_obj)
-- -- obj is the object cached in lrucache
local function plugin_ctx(lrucache, api_ctx, extra_key, create_obj_func, ...)
    local key, ver = plugin_ctx_key_and_ver(api_ctx, extra_key)
    return lrucache(key, ver, create_obj_func, ...)
end

-- 生成 key 和 version
-- key = api_ctx.conf_type .. "#" .. api_ctx.conf_id = route#123  每个路由唯一
-- version = api_ctx.conf_version  =  = route.modifiedIndex, 只要 route 配置不变，这个version 不变
local function plugin_ctx_key_and_ver(api_ctx, extra_key)
    local key = api_ctx.conf_type .. "#" .. api_ctx.conf_id

    if extra_key then
        key = key .. "#" .. extra_key
    end

    return key, api_ctx.conf_version
end

使用示例

local lrucache = core.lrucache.new({
    type = "plugin",
})

-- 这里创建一个携带 limit object 的 lrucache
-- 其中 
-- 1. lrucache
-- 2. 没有设置 extra_key
-- 3. ctx, conf 为 apisix plugin 机制中的 ctx, conf
-- 4. create_limit_obj 为创建函数
local lim, err = core.lrucache.plugin_ctx(lrucache, ctx, nil, create_limit_obj, conf)

注意，这里会存在一个非常容易导致 bug 的点：假设我在公共模块配置了一个lrucache，然后在多个插件中调用，那么你会发现不同插件 lrucache 获取到的对象串了， api_ctx.conf_type/api_ctx.conf_id 对于同一个资源是一致的，所以同一个资源如果没有指定 extra_key，那么多个插件调用生成的key是一样地！

解决：公共模块中如果使用 plugin_ctx，需要额外指定 extra_key = plugin_name

-- ratelimit/init.lua

local lrucache = core.lrucache.new(
    {
        type = "plugin",
        serial_creating = true,
    }
)

# bug here
function _M.rate_limit(conf, ctx, key, count, time_window)
      ......
      local lim, err = core.lrucache.plugin_ctx(lrucache, ctx, nil, create_limit_obj, plugin_name)

end

# ok here
function _M.rate_limit(conf, ctx, plugin_name, key, count, time_window)
      ......
      local lim, err = core.lrucache.plugin_ctx(lrucache, ctx, plugin_name, create_limit_obj, plugin_name)

end

其他同类库

Fast and automated layered caching for OpenResty.

GitHub - thibaultcha/lua-resty-mlcache: Layered caching library for OpenResty 两级缓存库

默认lrucache是 worker 维度的，这个库实现了两集缓存，二级缓存走的 lua_shared_dict, 进程维度，多个worker 共享

apisix 中的服务发现机制

Sat, 21 Sep 2024 00:00:00 +0800

基于 3.10.0 版本

机制

0. 入口

在 apisix 的ngx_tpl.lua中

    init_worker_by_lua_block {
        apisix.http_init_worker()
    }

apisix/init.lua

local router          = require("apisix.router")

function _M.http_init_worker()
    .....
    local discovery = require("apisix.discovery.init").discovery
    if discovery and discovery.init_worker then
        discovery.init_worker()
    end
    .....
end

1. discovery.init_worker

apisix/discovery/init.lua

local discovery_type = local_conf.discovery
local discovery = {}

if discovery_type then
    for discovery_name, _ in pairs(discovery_type) do
        log.info("use discovery: ", discovery_name)
        discovery[discovery_name] = require("apisix.discovery." .. discovery_name)
    end
end

function discovery.init_worker()
    if discovery_type then
        for discovery_name, _ in pairs(discovery_type) do
            discovery[discovery_name].init_worker()
        end
    end
end

根据配置文件中配置的服务发现类型，加载对应的模块，在 init_worker中调用对应模块的init_worker

假设配置文件 config.yaml 中我们配置的是 dns (最简单的实现，其他的实现原理上一一样的)

discovery:                      # Service Discovery
  dns:
    servers:
      - "127.0.0.1:8600"         # Replace with the address of your DNS server.
    resolv_conf: /etc/resolv.conf # Replace with the path to the local DNS resolv config. Configure either "servers" or "resolv_conf".
    order:                       # Resolve DNS records this order.
      - last                     # Try the latest successful type for a hostname.
      - SRV
      - A
      - AAAA
      - CNAME

2. apisix.discovery.dns

apisix/discovery/dns/init.lua

一共两个方法（实现其他类型服务发现同理需要实现这两个方法）

init_worker() 初始化，根据配置，构建一个 client
nodes(service_name) 根据 service_name，使用client做服务发现，返回 service_name 对应可用的 nodes

function _M.init_worker()
    ......
    local client, err = core.dns_client.new(opts)
    if not client then
        error("failed to init the dns client: ", err)
        return
    end

    dns_client = client
end

unction _M.nodes(service_name)
    local host, port = core.utils.parse_addr(service_name)
    core.log.info("discovery dns with host ", host, ", port ", port)

    local records, err = dns_client:resolve(host, core.dns_client.RETURN_ALL)
    if not records then
        return nil, err
    end

    local nodes = core.table.new(#records, 0)
    local index = 1
    for _, r in ipairs(records) do
        ......
    end

    return nodes
end

nodes示例

[
  {
    "host": "192.168.1.100",
    "port": 8761,
    "weight": 100,
    "metadata": {
      "management.port": "8761"
    }
  }
]

3. 调用点在哪里？

apisix/init.lua

local set_upstream    = apisix_upstream.set_by_route

-- from access phase
function _M.http_access_phase()
      ......
      _M.handle_upstream(api_ctx, route, enable_websocket)
end

function _M.handle_upstream(api_ctx, route, enable_websocket)
    ......
    local code, err = set_upstream(route, api_ctx)
    ......
end

apisix/upstream.lua

function _M.set_by_route(route, api_ctx)
    ......
    -- 如果 upstream 中有配置 service_name， 则需要服务发现
    if up_conf.service_name then
        ......
        -- 获取服务发现类型对应的实例
        local dis = discovery[up_conf.discovery_type]
        -- 根据service_name 获取 nodes
        local new_nodes, err = dis.nodes(up_conf.service_name, up_conf.discovery_args)
        -- 跟之前的比较是否一致
        local same = upstream_util.compare_upstream_node(up_conf, new_nodes)
        if not same then
            ......
            -- 这里设置了 新的节点
            up_conf.nodes = new_nodes
            up_conf.original_nodes = up_conf.nodes

            local new_up_conf = core.table.clone(up_conf)

            local parent = up_conf.parent
            if parent.value.upstream then
                -- the up_conf comes from route or service
                parent.value.upstream = new_up_conf
            else
                parent.value = new_up_conf
            end
            up_conf = new_up_conf
        end
    end

    local id = up_conf.parent.value.id
    local conf_version = up_conf.parent.modifiedIndex
    -- include the upstream object as part of the version, because the upstream will be changed
    -- by service discovery or dns resolver.
    set_directly(api_ctx, id, conf_version .. "#" .. tostring(up_conf), up_conf)

local function set_directly(ctx, key, ver, conf)
    ......
    -- 注意这里，更新了 api_ctx 的这几个字段
    ctx.upstream_conf = conf
    ctx.upstream_version = ver
    ctx.upstream_key = key
    return
end

apisix/balancer.lua

-- pick_server will be called:
-- 1. in the access phase so that we can set headers according to the picked server
-- 2. each time we need to retry upstream
local function pick_server(route, ctx)
    ......
    local version = ctx.upstream_version
    local key = ctx.upstream_key
    local checker = ctx.up_checker

    -- the same picker will be used in the whole request, especially during the retry
    local server_picker = ctx.server_picker
    if not server_picker then
        server_picker = lrucache_server_picker(key, version,
                                               create_server_picker, up_conf, checker)
    end
    ......

    local server, err = server_picker.get(ctx)

这里，如果服务发现导致 upstream_key/upstream_version 变化，那么意味着 server_picker 对应的 lrucache 会失效，进入 create_server_picker的逻辑

数据面服务发现的问题

如果服务发现获取上游的 node 数据变更非常频繁

会被对比出来，有差异
会多一些赋值
负载均衡lrucache会失效重建，重建时，如果配置有主动健康检查，还会触发主动健康检查获取健康的节点列表

这样会导致服务出现抖动。

基于控制面的服务发现

官方有一个基于控制面的服务发现项目 api7/apisix-seed: Do service discovery on the CP side

通过订阅 service_name的变更，获取服务发现的变更，写入到etcd

apisix 中的负载均衡

Sat, 21 Sep 2024 00:00:00 +2000

基于 3.10.0 版本

机制

0. 入口

在 apisix 的ngx_tpl.lua中

    -- 初始化
    init_worker_by_lua_block {
        apisix.http_init_worker()
    }

        -- balance
        balancer_by_lua_block {
            apisix.http_balancer_phase()
        }

1. 初始化

apisix/init.lua

local router          = require("apisix.router")

local load_balancer

function _M.http_init_worker()
    .....
    -- 这个什么都没做
    require("apisix.balancer").init_worker()
    -- 这个这个是核心逻辑
    load_balancer = require("apisix.balancer")
  

    .....
end

2. 执行入口

在 balance 阶段，进入http_balancer_phase

apisix/init.lua

function _M.http_balancer_phase()
    ......

    load_balancer.run(api_ctx.matched_route, api_ctx, common_phase)
end

进入

apisix/balancer.lua

function _M.run(route, ctx, plugin_funcs)
    local server, err

    if ctx.picked_server then
        -- use the server picked in the access phase
        server = ctx.picked_server
        ctx.picked_server = nil

        set_balancer_opts(route, ctx)

    else
        -- retry 相关，暂时忽略
        ......
    end

    local ok, err = set_current_peer(server, ctx)
    if not ok then
        return core.response.exit(502)
    end

    ctx.proxy_passed = true
end

3. api_ctx.picked_server

apisix/init.lua

实际上，在 http_access_phase 就已经做了 pick_server

function _M.http_access_phase()
      ......
      _M.handle_upstream(api_ctx, route, enable_websocket)
end

function _M.handle_upstream(api_ctx, route, enable_websocket)
    ......
    local server, err = load_balancer.pick_server(route, api_ctx)
    if not server then
        core.log.error("failed to pick server: ", err)
        return core.response.exit(502)
    end

    api_ctx.picked_server = server
    ......

4. load_balancer.pick_server

apisix/balancer.lua

-- pick_server will be called:
-- 1. in the access phase so that we can set headers according to the picked server
-- 2. each time we need to retry upstream
local function pick_server(route, ctx)
    local up_conf = ctx.upstream_conf
    
    local nodes_count = #up_conf.nodes
    -- 如果只有一个 node, 直接返回
    if nodes_count == 1 then
        local node = up_conf.nodes[1]
        ctx.balancer_ip = node.host
        ctx.balancer_port = node.port
        node.upstream_host = parse_server_for_upstream_host(node, ctx.upstream_scheme)
        return node
    end

    -- the same picker will be used in the whole request, especially during the retry
    local server_picker = ctx.server_picker
    if not server_picker then
        -- 从lrucache中获取，没有的话创建一个 create_server_picker
        server_picker = lrucache_server_picker(key, version,
                                               create_server_picker, up_conf, checker)
    end
    if not server_picker then
        return nil, "failed to fetch server picker"
    end

    -- 获取一个
    local server, err = server_picker.get(ctx)
    if not server then
        err = err or "no valid upstream node"
        return nil, "failed to find valid upstream server, " .. err
    end
    ctx.balancer_server = server

local function create_server_picker(upstream, checker)
    -- 根据配置加载对应的 负载均衡算法实现模块
    local picker = pickers[upstream.type]
    if not picker then
        pickers[upstream.type] = require("apisix.balancer." .. upstream.type)
        picker = pickers[upstream.type]
    end
  
    if picker then
        ......
        local server_picker = picker.new(up_nodes[up_nodes._priority_index[1]], upstream)

        return server_picker
    end

the balance algorithm chash/ewma/least_conn/priority/roundrobin

以 roundrobin 为例 apisix/balancer/roundrobin.lua


function _M.new(up_nodes, upstream)
    local safe_limit = 0
    for _, weight in pairs(up_nodes) do
        -- the weight can be zero
        safe_limit = safe_limit + weight + 1
    end

    local picker = roundrobin:new(up_nodes)
    local nodes_count = nkeys(up_nodes)
    return {
        upstream = upstream,
        get = function (ctx)
            if ctx.balancer_tried_servers and ctx.balancer_tried_servers_count == nodes_count then
                return nil, "all upstream servers tried"
            end

            local server, err
            for i = 1, safe_limit do
                server, err = picker:find()
                if not server then
                    return nil, err
                end
                if ctx.balancer_tried_servers then
                    if not ctx.balancer_tried_servers[server] then
                        break
                    end
                else
                    break
                end
            end

            return server
        end,
        after_balance = function (ctx, before_retry)
            if not before_retry then
                if ctx.balancer_tried_servers then
                    core.tablepool.release("balancer_tried_servers", ctx.balancer_tried_servers)
                    ctx.balancer_tried_servers = nil
                end

                return nil
            end

            if not ctx.balancer_tried_servers then
                ctx.balancer_tried_servers = core.tablepool.fetch("balancer_tried_servers", 0, 2)
            end
            -- 标记 及 计数
            ctx.balancer_tried_servers[ctx.balancer_server] = true
            ctx.balancer_tried_servers_count = (ctx.balancer_tried_servers_count or 0) + 1
        end,
        before_retry_next_priority = function (ctx)
            if ctx.balancer_tried_servers then
                core.tablepool.release("balancer_tried_servers", ctx.balancer_tried_servers)
                ctx.balancer_tried_servers = nil
            end

            ctx.balancer_tried_servers_count = 0
        end,
    }
end

这几个函数在哪里被调用的?

get: 在pick_server(route, ctx) new 得到一个实例后, 立马get, local server, err = server_picker.get(ctx)并且执行赋值ctx.balancer_server = server
after_balance: 在 http_log_phase 阶段, 请求结束后, 调用的api_ctx.server_picker.after_balance(api_ctx, false); 另外, pick_server的retry过程中, 也会ctx.server_picker.after_balance(ctx, true)
before_retry_next_priority: balancer/priority.lua 中调用的, priority.get(ctx) -> picker.before_retry_next_priority; 在逐一确认priority的过程中, 调用这个函数

apisix etcd机制

Tue, 17 Sep 2024 08:00:00 +0800

基于 3.10.0 版本

机制

0. 入口

在 apisix 的ngx_tpl.lua中

    init_worker_by_lua_block {
        apisix.http_init_worker()
    }

apisix/init.lua

local router          = require("apisix.router")

function _M.http_init_worker()
    .....
    router.http_init_worker()
    .....
end

1. http_init_worker

apisix/router.lua

function _M.http_init_worker()
    local conf = core.config.local_conf()
    local router_http_name = "radixtree_uri"

    if conf and conf.apisix and conf.apisix.router then
        router_http_name = conf.apisix.router.http or router_http_name
        ......
    end

    local router_http = require("apisix.http.router." .. router_http_name)
    attach_http_router_common_methods(router_http) -- 这里 attach 两个方法给到模块
    router_http.init_worker(filter) -- 这里调用 init_worker 完成初始化
    _M.router_http = router_http

    ......
end

其中 attach_http_router_common_methods

local function attach_http_router_common_methods(http_router)
    if http_router.routes == nil then
        http_router.routes = function ()
            if not http_router.user_routes then
                return nil, nil
            end
            -- 返回模块中的 user_routes 的值值和版本
            local user_routes = http_router.user_routes
            return user_routes.values, user_routes.conf_version
        end
    end

    if http_router.init_worker == nil then
        http_router.init_worker = function (filter)
            http_router.user_routes = http_route.init_worker(filter)
            -- 这里引用 local http_route = require("apisix.http.route") 的 init_worker
            -- 获取 routes， 赋值给模块中的 user_routes
        end
    end
end

apisix/http/route.lua

http_route.init_worker 从 core.config.new("/routes", {})

function _M.init_worker(filter)
    local user_routes, err = core.config.new("/routes", {
            automatic = true,
            item_schema = core.schema.route,
            checker = check_route,
            filter = filter,
        })
    if not user_routes then
        error("failed to create etcd instance for fetching /routes : " .. err)
    end

    return user_routes
end

2. 具体某个router.lua

apisix/http/router
├── radixtree_host_uri.lua
├── radixtree_uri.lua
└── radixtree_uri_with_parameter.lua

即，如果配置文件中有配置 apisix.router.http，那么将会使用配置文件中的，否则使用 radixtree_uri

假设我们配置了 apisix.router.http=radixtree_uri_with_parameter

local router_http = require("apisix.http.router.radixtree_uri_with_parameter")

对应代码

local require = require
local core = require("apisix.core")
local base_router = require("apisix.http.route")
local get_services = require("apisix.http.service").services
local cached_router_version
local cached_service_version

local _M = {}

local uri_routes = {}
local uri_router

function _M.match(api_ctx)
    local user_routes = _M.user_routes
    local _, service_version = get_services()
    if not cached_router_version or cached_router_version ~= user_routes.conf_version
        or not cached_service_version or cached_service_version ~= service_version
    then
        uri_router = base_router.create_radixtree_uri_router(user_routes.values,
                                                             uri_routes, true)
        cached_router_version = user_routes.conf_version
        cached_service_version = service_version
    end

    if not uri_router then
        core.log.error("failed to fetch valid `uri_with_parameter` router: ")
        return true
    end

    return _M.matching(api_ctx)
end


function _M.matching(api_ctx)
    core.log.info("route match mode: radixtree_uri_with_parameter")
    return base_router.match_uri(uri_router, api_ctx)
end


return _M

说明：

声明了 match(api_ctx) 和 matching(api_ctx)，并且前者调用后者
声明了模块变量 user_routes，在启动时，通过 http_route.init_worker(filter) 被初始化
声明了模块变量 cached_router_version/cached_service_version, 用于判断当前 router 是否最新，如果 etcd watch到变更，那么会导致这里判断版本不一致，进而调用 base_router.create_radixtree_uri_router(user_routes.values, uri_routes, true)重建radixtree
这个过程是在 match中，意味着，数据面在处理请求的时候，执行match，发现service或route有更新，此时会发生radixtree重建

这个可能会导致问题，见下面【特性跟踪-实时更新】

我们回到原点，关注 user_routes 的初始化

3. user_routes

apisix/http/route.lua

引用 local http_route = require("apisix.http.route") 的 init_worker

function _M.init_worker(filter)
    local user_routes, err = core.config.new("/routes", {
            automatic = true,  -- 注意这个标志
            item_schema = core.schema.route,
            checker = check_route,
            filter = filter,
        })
    if not user_routes then
        error("failed to create etcd instance for fetching /routes : " .. err)
    end

    return user_routes
end

apisix/core.lua

local config_provider = local_conf.deployment and local_conf.deployment.config_provider
                      or "etcd"
log.info("use config_provider: ", config_provider)
local config = require("apisix.core.config_" .. config_provider)
config.type = config_provider

return {
  config      = config,
}

配置的config_provider=etcd, 则

local config = require("apisix.core.config_etcd")

则调用的new方法是 apisix/core/config_etcd.lua

---
-- Create a new connection to communicate with the control plane.
-- This function should be used in the `init_worker_by_lua` phase.
--

function _M.new(key, opts)
    ......
    -- etcd 相关配置
    local etcd_conf = local_conf.etcd
    local prefix = etcd_conf.prefix
    local resync_delay = etcd_conf.resync_delay
    if not resync_delay or resync_delay < 0 then
        resync_delay = 5
    end
    local health_check_timeout = etcd_conf.health_check_timeout
    if not health_check_timeout or health_check_timeout < 0 then
        health_check_timeout = 10
    end

    local automatic = opts and opts.automatic
    -- 初始化对象
    local obj = setmetatable({
        etcd_cli = nil,
        key = key and prefix .. key,
        automatic = automatic,  -- true
        item_schema = item_schema,
        checker = checker,
        sync_times = 0,   -- 同步次数
        running = true,
        conf_version = 0,  -- 当前数据版本号，可以通过这个判断是否有更新
        values = nil,      -- 所有同步过来的数据
        need_reload = true,  -- 注意这里，首次 new 的时候，need_reload 是 true
        watching_stream = nil,
        routes_hash = nil,
        prev_index = 0,     -- 上一次执行同步etcd 返回的 modifiedIndex
        last_err = nil,
        last_err_time = nil,
        resync_delay = resync_delay,
        health_check_timeout = health_check_timeout,
        timeout = timeout,  -- 注意，这里没有设置timeout, 那么在连接的时候，http_waitdir 将使用代码中的默认值 ` local ok, err = self.watch_sema:wait(timeout or 60)`
        single_item = single_item,
        filter = filter_fun,
    }, mt)

    if automatic then
        ......
        -- 如果 之前加载过，直接拿上一次数据全量加载
        if loaded_configuration[key] then
            local res = loaded_configuration[key]
            loaded_configuration[key] = nil -- tried to load

            log.notice("use loaded configuration ", key)

            local dir_res, headers = res.body, res.headers
            load_full_data(obj, dir_res, headers)
        end
   
        -- 启动一个定时器， local ngx_timer_at = ngx.timer.at
        ngx_timer_at(0, _automatic_fetch, obj)

    else
        -- 初始化 etcd_cli
        local etcd_cli, err = get_etcd()
        if not etcd_cli then
            return nil, "failed to start an etcd instance: " .. err
        end
        obj.etcd_cli = etcd_cli
    end

    -- 将 `/routes` 放入 created_obj
    if key then
        created_obj[key] = obj
    end

    return obj
end

在 _automatic_fetch 中, 执行结束前判断如果还在运行时，启动下一个定时器，从而达到持续同步的目的，ngx.timer.at更多资料可以阅读 OpenResty最佳实践：定时任务

local function _automatic_fetch(premature, self)
            ......
            local ok, err = sync_data(self)
            ......
            
    if not exiting() and self.running then
        ngx_timer_at(0, _automatic_fetch, self)
    end
end

然后 sync_data 进行数据同步, 注意core.config.new("/routes, {})"的时候，首次调用 sync_data时， need_reload=true

所以这里会涉及两个关键函数

如果 need_reload=true，调用 readdir(self.etcd_cli, self.key)，全量拉取数据，最终调用 load_full_data(self, dir_res, headers)
否则，调用 waitdir(self) watch增量变更数据, 更新 self.values 以及更新版本 self.prev_index = new_ver
- 如果self.sync_times>100，会重建 self.values和self.values_hash
- self.conf_version = self.conf_version + 1 (外部可以通过这个判断是否存在更新）

local function sync_data(self)
    if not self.key then
        return nil, "missing 'key' arguments"
    end

    init_watch_ctx(self.key)

    if self.need_reload then
        local res, err = readdir(self.etcd_cli, self.key)
        if not res then
            return false, err
        end

        local dir_res, headers = res.body.list or res.body.node or {}, res.headers
        log.debug("readdir key: ", self.key, " res: ",
                  json.delay_encode(dir_res))

        if self.values then
            for i, val in ipairs(self.values) do
                config_util.fire_all_clean_handlers(val)
            end

            self.values = nil
            self.values_hash = nil
        end

        load_full_data(self, dir_res, headers)

        return true
    end

    local dir_res, err = waitdir(self)

    if not dir_res then
        if err == "compacted" then
            self.need_reload = true
            log.error("waitdir [", self.key, "] err: ", err,
                     ", will read the configuration again via readdir")
            return false
        end

        return false, err
    end

另外，如果 waitdir的时候，发现 etcd 发生了 compacted，将会设置 self.need_reload = true，触发全量同步, 可能会带来问题，见下面【问题】

问题

etcd compacted

apisix 同步 etcd, 如果 etcd 发生了 compact, 此时apisix watch 的revision 小于 etcd compact revision, apisix watch 到事件变更会直接触发全量同步, 具体机制参考文档

带来的问题:

apisix本身的性能抖动(全量同步后, 会重建radixtree)
- 会导致请求 499(相当于请求进来，在等待radixtree重建，客户端等不及或配置了timeout，主动关闭掉了连接)
etcd 读 IO 波峰 / 内存波峰(所有连接的 worker 都进行了全量拉取)

解决方案: 默认etcd的配置 --auto-compaction-mode=periodic --auto-compaction-retention=5m, 如果apisix实例很多, 无论怎么配置, apisix 全量同步的概率还是很大;

建议将配置改成 --auto-compaction-mode=revision --auto-compaction-retention=1000, 默认会保留 1000 个有效的revision

实时更新的问题

压测可以看到，如果持续变更，那么所有请求在同一个时间 rebuild radixtree

2023/10/09 12:10:26 [info] 38#38: *231868 [lua] radixtree.lua:355: pre_insert_route(): 
2023/10/09 12:10:26 [info] 40#40: *231883 [lua] radixtree.lua:355: pre_insert_route(): 
2023/10/09 12:10:26 [info] 37#37: *231820 [lua] radixtree.lua:355: pre_insert_route(): 
2023/10/09 12:10:26 [info] 39#39: *231882 [lua] radixtree.lua:355: pre_insert_route():

如果路由比较多，并且存在路由频繁更新，那么可能带来性能抖动。

因为 watch 变更后，下一次请求对比版本的时候发现不一致，会重建 radixtree，而请求需要等到重建之后才继续执行；

我提过一个issue help request: Is the radix tree rebuilt every time any route is updated? 讨论这个事情。

最终，我们暂时是通过将重建打散到一个时间范围内，确保所有线上实例不会在同一时间rebuild radixtree，有需要可以参考 patch

特性追踪

etcd http

在 APISIX’s V3 (2022) Roadmap 中提到 Connect to etcd via gRPC and reduce the number of etcd connection

最早使用 http api 连接 etcd，意味着每个worker中的每一种资源类型都会存在连接（实例数 * worker 数 * 资源类型数）。

在apisix 3.2.2 合入了一个 PRfeat(config_etcd): use a single long http connection to watch all resources, 使用一个 http connection 来watch 所有资源类型，这样能有效降低连接数（实例数*worker 数，当然还是可能很大）。但是，这个 PR 引入了一个bug bug: route 404 after upgrade to 3.2.2, 当 etcd prefix 中带了-会 watch 不到，这个在 3.5.0及以上的版本中被修复 fix: can’t sync etcd data if key has special character

etcd grpc

原先在配置 etcd 连接的时候是支持配置 use_grpc: true 通过 grpc 连接 etcd 的

后来 [DISCUSS] Proposal: APISIX: remove etcd grpc and conf server 的讨论中， this module has too many bugs ，最终在 PR:fix: remove etcd.use_grpc中移除了。

增量更新

社区曾经有个 pr feat: increment route update for radixtree host uri, radixtree uri and radi… ，但是最终被close 了（个人认为这个 PR 还是很重要的）。

PS：近期 apisix和 apisix-ingress-controller github 仓库的 issue 陆续被无差别close(机器人根据时间、活跃自动化执行的)，但是其中有一些是比较重要的 issue。并且比较影响用户的积极性和活跃度，再持续下去可能后续就没多少 issue 了。

依赖库

lua-resty-etcd Nonblocking Lua etcd driver library for OpenResty, this module supports etcd API v3.

涉及函数

readdir:

syntax: res, err = cli:readdir(dir:string [, opts:table])
opts
- timeout: (int) request timeout seconds. Set to 0 would use lua_socket_connect_timeout as timeout. (5 seconds)
- revision: (int) revision is the point-in-time of the key-value store to use for the range. If revision is less than or equal to zero, the range is over the newest key-value store. If the revision has been compacted, ErrCompacted is returned as a response.
- limit: (int) limit is a limit on the number of keys returned for the request. When limit is set to 0, it is treated as no limit.
- sort_order: (int [SortNone:0, SortAscend:1, SortDescend:2]) sort_order is the order for returned sorted results.
- sort_target: (int [SortByKey:0, SortByVersion:1, SortByCreateRevision:2, SortByModRevision:3, SortByValue:4]) sort_target is the key-value field to use for sorting.
- keys_only: (bool) keys_only when set returns only the keys and not the values.
- count_only: (bool) count_only when set returns only the count of the keys in the range.

特别注意，当revision被compacted，将会返回异常 ErrCompacted

watchdir

syntax: res, err = cli:watchdir(dir:string [, opts:table])
opts: optional options.
- timeout: (int) request timeout seconds. Set to 0 would use lua_socket_connect_timeout as timeout. (5 seconds)
- start_revision: (int) start_revision is an optional revision to watch from (inclusive). No start_revision is “now”.
- progress_notify: (bool) progress_notify is set so that the etcd server will periodically send a WatchResponse with no events to the new watcher if there are no recent events.
- filters: (slice of [enum FilterType {NOPUT = 0;NODELETE = 1;}]) filters filter the events at server side before it sends back to the watcher.
- prev_kv: (bool) If prev_kv is set, created watcher gets the previous KV before the event happens. If the previous KV is already compacted, nothing will be returned.
- watch_id: (int) If watch_id is provided and non-zero, it will be assigned to this watcher. Since creating a watcher in etcd is not a synchronous operation, this can be used to ensure that ordering is correct when creating multiple watchers on the same stream. Creating a watcher with an ID already in use on the stream will cause an error to be returned.
- fragment: (bool) fragment enables splitting large revisions into multiple watch responses.

注意， watchdir 默认如果超过 5s没有结束，会直接timeout异常

apisix 中的 DNS 解析

Mon, 16 Sep 2024 00:00:00 +0800

基于 3.10.0 版本

入口

在 apisix 的 ngx_tpl.lua 中相关的配置

            access_by_lua_block {
                apisix.http_access_phase()
            }

即，请求在 access phase，会走到 http_access_phase 函数

在 apisix/init.lua 的 http_access_phase 中确定匹配到的 route之后，调用了 _M.handle_upstream(api_ctx, route, enable_websocket)

主入口： handle_upstream

_M.handle_upstream

function _M.handle_upstream(api_ctx, route, enable_websocket)
    local up_id = route.value.upstream_id

    if up_id then
        local upstream = apisix_upstream.get_by_id(up_id)
        if not upstream then
            if is_http then
                return core.response.exit(502)
            end

            return ngx_exit(1)
        end

        api_ctx.matched_upstream = upstream

    else
        if route.has_domain then
            local err
            route, err = parse_domain_in_route(route)
            if err then
                core.log.error("failed to get resolved route: ", err)
                return core.response.exit(500)
            end


        end

        local route_val = route.value

        api_ctx.matched_upstream = (route.dns_value and
                                    route.dns_value.upstream)
                                   or route_val.upstream
    end

这里，如果有 upstream，走upstream，否则，走route； route包含域名，则 parse_domain_in_route(route)

调用链路:

if up_id:

  apisix/init.lua: apisix_upstream.get_by_id(up_id)
  ->
  apisix/upstream.lua: get_by_id(up_id) 
                       -> upstream_util.parse_domain_in_up(upstream)
  ->
  apisix/utils/upstream.lua: parse_domain_in_up(up) 
                           -> parse_domain_for_nodes(nodes) 
                           -> core.resolver.parse_domain(host)
                           
else:
  if route.has_domain:
  apisix/init.lua: parse_domain_in_route(route) 
                   -> upstream_util.parse_domain_for_nodes(nodes)
  ->
  apisix/utils/upstream.lua: parse_domain_for_nodes(nodes) 
                           -> core.resolver.parse_domain(host)

公共部分:

->
apisix/core/resolver.lua: parse_domain(host) -> utils.dns_parse(host)
-> 
apisix/core/utils.lua: dns_client.new(opts) ->  current_dns_client:resolve(domain, selector)
->
lib: resty.dns.client

1. parse_domain_for_nodes

parse_domain_for_nodes

local function parse_domain_for_nodes(nodes)
    local new_nodes = core.table.new(#nodes, 0)
    for _, node in ipairs(nodes) do
        local host = node.host
        if not ipmatcher.parse_ipv4(host) and
                not ipmatcher.parse_ipv6(host) then
            local ip, err = core.resolver.parse_domain(host)
            if ip then
                local new_node = core.table.clone(node)
                new_node.host = ip
                new_node.domain = host
                core.table.insert(new_nodes, new_node)
            end

            if err then
                core.log.error("dns resolver domain: ", host, " error: ", err)
            end
        else
            core.table.insert(new_nodes, node)
        end
    end
    return new_nodes
end
_M.parse_domain_for_nodes = parse_domain_for_nodes

注意，这里没有检测最终结果是否是空的，导致 new_nodes为空 table 返回， local new_nodes, err = parse_domain_for_nodes(nodes)

会带来一个问题，当dns server短时间不可用之后又恢复了，此时apisix中的dns解析并没有恢复，还是会持续失败，报

dns server 异常时

[lua] upstream.lua:79: parse_domain_for_nodes(): dns resolver domain: test.com error: failed to query the DNS server: dns client error: 101 empty record received
[lua] resolver.lua:80: parse_domain(): failed to parse domain: test.com, error: failed to query the DNS server: dns client error: 101 empty record received

并且，在dns server恢复后

[lua] init.lua:486: handle_upstream(): failed to set upstream: no valid upstream node

直到重启apisix，或者执行apisix reload

之前提过一个issue bug: dns resolution did not resume immediately after the dns server resume, 后来由于开发没有复现，该单据已经被关闭（实际上是可以复现的）；目前的修复方式是patch，在 return new_nodes前面加上判断，具体可以参考 fix(build/patches): add patch for parse_domain_for_nodes in apisix/utils/upstream.lua

2. parse_domain(host)

parse_domain

function _M.parse_domain(host)

    local ip_info, err = utils.dns_parse(host)
    if not ip_info then
        log.error("failed to parse domain: ", host, ", error: ",err) -- line 80
        return nil, err
    end

3. dns_parse(domain, selector)

dns_parse

local function dns_parse(domain, selector)
    ....
    return current_dns_client:resolve(domain, selector)

4. resolve(domain)

resolve

function _M.resolve(self, domain, selector)
    local client = self.client

    -- this function will dereference the CNAME records
    local answers, err = client.resolve(domain)
    if not answers then
        return nil, "failed to query the DNS server: " .. err
    end

    if answers.errcode then
        return nil, "server returned error code: " .. answers.errcode
                    .. ": " .. answers.errstr
    end

    if selector == _M.RETURN_ALL then
        log.info("dns resolve ", domain, ", result: ", json.delay_encode(answers))
        for _, answer in ipairs(answers) do
            if answer.type == client.TYPE_SRV then
                return resolve_srv(client, answers)
            end
        end
        return table.deepcopy(answers)
    end

    local idx = math_random(1, #answers)
    local answer = answers[idx]
    local dns_type = answer.type
    if dns_type == client.TYPE_A or dns_type == client.TYPE_AAAA then
        log.info("dns resolve ", domain, ", result: ", json.delay_encode(answer))
        return table.deepcopy(answer)
    end

    return nil, "unsupported DNS answer"
end

依赖库

api7/lua-resty-dns-client

从 https://github.com/Kong/lua-resty-dns-client fork 过来，改了什么：

feat: support run in stream subsystem https://github.com/api7/lua-resty-dns-client/pull/1

如何减少打断提升效率

Sun, 25 Aug 2024 18:00:00 +0800

去年接手一个上线小十年的系统，由于这个系统是出于上下游的中间环节（意味着会跟几乎所有系统打交道），并且存在着大量的历史包袱（意味着很多黑盒，一些奇怪的用法以及机制），导致这个系统的日常工作最为繁重。

我们面向的用户是所有的系统开发者，问题涉及各类调用问题，白名单，权限审批，机制，线上问题排查等等，其中很大一部分需要有实时反馈，这就意味着日常工作中的打断非常多，进而导致团队的效率下降，以及整体产出变少。

对此，经过近一年的优化和改进，我们已经成功地将打断减少了 90% 以上，并且确保服务质量。

以下分享一些过程中的经验

让每个人深切感受到`打断`

所有人都需要真切感受到被打断、拉群

轮值作为接口人，不能让某个人或某几个人单独作为这种打断的受害者，脏活累活得平摊开
项目的负责人不能例外
产品经理也不能例外，直接在一些接收用户的反馈

跟吃自己的狗粮类似，所有人参与到轮值中，就能覆盖到各类咨询问题的方方面面。

记录，记录，记录

轮值的助手需要记录：

用户咨询的问题
原因及解决方案
1. 如果是操作类，做了哪些操作，操作路径是什么
2. 如果是产品问题，应该怎么处理更好
耗时

有记录，才有统计，有统计，才能更高效直接地解决问题

我们的项目轮值经过 2 个月左右，基本已经清楚地知道所有打断的来源

统计和分类

分析所有的记录，将相同的问题汇聚计数，得到一张表格

分类：

咨询类：哪些问题，出现频次，如何解决
操作类：什么操作，操作的链路，出现频次

二八定律，先处理 20% 的核心问题，解决掉 80% 的打断

处理

1. 文档体系

我们发现，虽然这个系统已经存在了小十年，但是并没有太多的文档，并且文档非最新、含糊不清。

大量的咨询原因是没有文档，或者文档看不懂，所以我们决定重新构建文档体系，替代掉原先的文档站点。

注意：

文档的目的是让所有人可达，所以优先选择所有人员可见的方式
文档的编辑成本需要足够低，用户反馈-修改-生效，最好选择所见即所得的方案，例如wiki(而不是需要仓库管理-编辑-review-合并-发布才生效)，低成本，高频率地持续维护
文档不要啰嗦，不要歧义，信息量足
有目录，有锚点，方便分享
重要，容易误操作的地方一定要重点强调

之前有参考一些最佳实践，文档体系由 4 个部分组成

Tutorials 教程，学习相关，例如quick start/demo等
How-To Guides，问题相关，如何解决一个具体的文昌塔
Explanation，概念相关，用于深入理解某些概念
Reference，引用相关，用于提供更多的参考信息，例如 API 文档

而具体划分，可能还会涉及

产品介绍（能做什么，最新的动态，升级日志等等）
使用指南（产品页面功能相关的step-by-step使用指引，保姆式教学）
概念说明（概念维度的组织方式）
常见问题 FAQ （重点，所有常见问题的解答，包含一些列说明和相关文档的引用）
问题反馈

这样，文档就成了一张网，用户不管从什么页面进去，都能够找到相关的概念、背景、用法、DEMO、FAQ，足够清晰就将用户可能的问题全部在这个阶段解决掉。

并且，在面对咨询的时候，可以通过直接扔文档链接的方式解决，无须废话。

目前大模型已经足够聪明，能够辅助解决问题，所以我们将整个文档站点喂给了大模型，问题咨询的时候直接拉机器人进群，用户发问题的时候机器人协助解答，也拦截了很大一部分问题。

2. 操作的合理性、必要性

对于操作类，我们首先评估合理性，是否有存在的必要？

例如，有一个加调用方 IP 白名单的操作类，每一个调用方都需要找过来加白，而原先的老系统也做了一个快速加白的入口，用户找过来申请加白-打开系统-完成加白，这似乎没毛病，也存在了很多年一直是这么做的。

但是这样做有意义吗？无脑加白=没有白名单限制，后来才发现，是 N 年前的安全团队扫描推动加的，但是其实已经不需要了，形同虚设。后来直接给内网网段加白，废弃掉这个流程

同样，还有一些接口权限申请，最早可能有用，但是随着时间流逝，有些权限审批变得不再必要，所以系统上改变，非敏感的不需要审批直接通过，敏感的走自动审批流审批，而不是集中在系统开发这里进行人工审批

3. 自动化及分派

能自动化的绝不手工做，能别人做的绝不自己做

有一些操作是有其存在的合理性的，但是这类操作的操作链路特别长，涉及多套系统。

我们其实是有职能类的人工助手的，但是在这个阶段他们没法做任何协助。

后来我们做了一套系统（3 人、一周），将高频的十个操作整合在一起，配合权限控制、审计，然后将这类操作直接分派给了职能化助手。

这套系统直接在前置步骤拦截了几乎所有的操作类问题， 3 人一周的成本非常划算

4. 其他系统带来的成本

我们发现有几个高频操作是其他系统带来的，他们在文档上直接指引使用者，找到我们系统的开发做一些操作、配置。

实际上这样给我们带来了非常大的工作量，以及困扰。

所以我们最终：

写了相关明确的指引文档
在产品做了相应的快捷按钮

然后反向推这些系统的维护者改文档说明和入口，直接让用户自助解决问题。

5. FAQ

咨询中很大一部分是接口调用后的返回问题

我们直接在文档中，将所有报错返回进行枚举，并将每种报错的可能原因，排查方式明确，直接让用户通过关键字搜索就能自行排查问题

另外咨询中一部分是关于一些系统的限制配置，我们直接将代码中各类限制放到了文档中。

6. 热点问题置顶

我们发现，总是有一个问题：用户无法识别是自己的问题还是我们系统的问题，所以总是发起咨询。

后来我们将这个做成一个专题，并且置顶，放入用户排查问题的必经链路中。

控糖革命

Sun, 23 Jun 2024 08:00:00 +0800

上半年去了医院，空腹血糖偏高，虽然还没有超出阈值，但是医生建议减重+低糖饮食。

然后，开始有目的性地减少糖，例如早餐减少碳水摄入，不再喝可乐等含糖饮料，晚上戒掉夜宵等，三个月顺利减重 15斤，但是目前到了平台期，体重还有接近 10 斤要减，但是 app 提醒是基础代谢太低导致的，可能缺乏运动。

期间读了这本书，有些观点可以作为参考。

以下仅为简单的摘录总结

全书分为三部分，为什么要控糖，出现葡糖糖峰值的 10 个危害，轻松控糖的 10 个窍门。其中前两者可以快速过下，最后一部分可以看看，有些做法可以参考，例如先吃蔬菜和蛋白质，最后吃碳水。

引用了很多事例，但是缺乏一些支撑。

第一部分为什么要控糖

我们的身体需要葡萄糖，但是平稳的血糖曲线非常重要（果糖，胰岛素水平很难连续被监测，但是血糖可以）；
葡萄糖以不同的形式存在：淀粉，纤维，果糖和蔗糖；
碳水化合物=淀粉+纤维+糖类（葡萄糖、果糖、蔗糖）；
大自然希望我们能通过植物来摄入葡萄糖，但是食品加工过程中通常都会去除纤维，然后将淀粉和糖进行浓缩；
吃甜食（含有蔗糖，是一种双糖，由葡萄糖和果糖缩合脱水形成）会导致葡萄糖和果糖双峰值；

第二部分出现葡萄糖峰值有哪些危害

个人体会：突然摄入大量糖分，例如一块西瓜，一罐可乐，一杯奶茶，会真切感受到血糖上升，脑子有点懵懵的，做不了重脑力活；控糖之后就基本再也没有出现过了。

降低葡萄糖峰值可以预防炎症的产生，继而降低患炎症类疾病的风险。

葡萄糖的存储方式：糖元（在肝脏或者肌肉中），脂肪（在脂肪细胞中）；果糖的存储方式：脂肪（在脂肪细胞中）
当过多的葡萄糖进入，我们身体会尽最大努力将其储存起来。当葡萄糖水平升高，胰腺分泌胰岛素，胰岛素唯一的作用就是将多余的葡萄糖存储在身体的存储单元中，使其脱离身体的循环，保护我们不被伤害。
脂肪会导致我们的身体出现一些不好的情况；建议选择不含果糖的咸香美味的食物，而不是含有果糖的甜食；
葡萄糖峰值是如何让我们生病的？
- 短期影响 1：持续的饥饿感。原因：胰岛素水平较高
- 短期影响 2：食欲旺盛。
- 短期影响 3：慢性疲劳。太多的葡萄糖会使线粒体停止工作，然后能量的生产就会受到影响，结果就是我们会感到疲惫不堪。
- 短期影响 4：糟糕的睡眠。
- 短期影响 5：感冒和冠状病毒并发症。经历一次葡萄糖峰值后，免疫系统会出现短暂故障，更容易遭到病毒感染。
- 短期影响 6：更棘手的妊娠期糖尿病
- 短期影响 7：潮热和盗汗
- 短期影响 8：偏头痛
- 短期影响 9：记忆和认知功能问题。大脑变得迟钝。
- 短期影响 10：更难管理的 1 型糖尿病
- 长期危害 1：痤疮和其他皮肤问题
- 长期危害 2：衰老与关节炎。糖化、自由基过多以及随之而来的炎症会使我们的细胞功能缓慢退化，我们称之为衰老。保持血糖平稳，辅以锻炼和减少压力控制，才是抗衰老的有效方法。
- 长期危害 3：阿尔茨海默病与痴呆
- 长期危害 4：患癌症的风险加大
- 长期危害 5：精神障碍
- 长期危害 6：肠道问题
- 长期危害 7：心脏病
- 长期危害 8：不孕症和多囊卵巢综合症
- 长期危害 9：胰岛素抵抗综合症与 2 型糖尿病。如果胰岛素水平长期处于高位时，细胞就开始对胰岛素产生抵抗。胰岛素抵抗是 2 型糖尿病的根本原因。降低血糖水平的饮食方式有助于逆转 2 型糖尿病。
- 长期危害 10：非酒精性脂肪性肝病。原因：果糖，降低果糖水平，降低果糖峰值
- 长期危害 11：皱纹和白内障

第三部分：轻松控糖的10个小窍门

窍门 1：正确的饮食顺序

按照科学的顺序进食，不节食，不放弃自己喜欢的食物，可将葡萄糖峰值降低 73%、胰岛素降低 48%。

正确的顺序：先吃纤维，然后吃蛋白质和脂肪，最后吃淀粉和糖类。

PS: 亲测有点用，先吃蔬菜，再次肉，最后吃米饭。但是有个问题，中国人的饮食结构中，淀粉占比过大，蛋白质占比小，像面食这类几乎无解。所以选择吃什么很重要，然后是吃的顺序。应该提升蔬菜和蛋白质的占比，减少碳水，或者使用粗粮替代原先的精细米面。

窍门 2：在每餐前增加一到绿色开胃菜

在吃其他食物之前，先吃纤维。

窍门 3：停止计算热量

窍门 4：平稳早餐后的血糖曲线

早餐最不适合吃糖类和淀粉类食物，但是，大多数人早餐只吃糖类和淀粉类食物。

如果我们准备吃一些糖，一个完整的水果是最好的选择（而不是打碎，果汁，NFC 之类的）。

果汁本身并不健康，只是商家让你认为健康而已。

开启咸香美味早餐

只做自己的咸香美味早餐
确保自己的早餐含有蛋白质
添加脂肪
添加额外的纤维
选择性地添加一些淀粉或者完整的水果（也可以不加）

水果：最好的选择是讲过，柑橘类水果或者是又小又酸的苹果。不建议选择芒果、菠萝和其他热带水果

咖啡：要小心加糖的咖啡。

窍门 5：吃自己喜欢的糖，因为所有糖都一样

蜂蜜含有葡萄糖和果糖，和食用糖一样。

天然糖并没有更好，因为所有糖都一样。

水果干看似健康，其实不然。确实含有一些纤维，但是其大多数成分和食用糖一样

选择自己喜欢的糖
尽量选择水果作为甜品
人造甜味剂
- 对葡萄糖水平和胰岛素水平没有副作用的最佳甜味剂：阿洛酮糖、罗汉果、甜叶菊。赤藓糖醇
- 避免食用，会导致胰岛素水平升高：阿斯巴甜、麦芽糖醇、三氯蔗糖、木糖醇、安赛蜜

窍门 6：选择餐后甜点而不是甜甜的零食

不管是水果、奶昔、糖果棒还是饼干，如果你想吃的话，一定要在饭后吃。

PS：减少峰值出现的次数；另外饭后非空腹，会减缓吸收，避免掉必然出现的峰值。

窍门 7：吃饭之前喝点醋

一旦醋酸进入血液，会渗透到我们的肌肉中，刺激肌肉比原来更快的制造糖元，是葡萄糖以更高的效率被吸收。

窍门 8：饭后动起来

饭后散步。

餐后运动会让血糖曲线变得平稳，但是胰岛素水平不会增高。

窍门 9：如果一定要吃零食，就吃咸香风味的零食

窍门 10：为你摄入的碳水化合物“穿上外衣”

享用碳水化合物的时候，加点纤维、蛋白质或脂肪，并将这种做法变成习惯。

好的脂肪以饱和脂肪酸（来自动物、黄油、酥油和椰子油）或单不饱和脂肪酸（来自水果和坚果，如牛油果、夏威夷果和橄榄果）为主要成份。

做饭是，最好是用饱和脂肪酸含量高的有。（常温下通常呈固态）。

不好的脂肪，以多不饱和脂肪酸或反式脂肪酸为主要成份，存在于大豆油、玉米油、菜籽油、米糠油、油炸食品和快餐中。有一种稍微好一点的种子油是菜籽油。

聊聊项目架构调整

Sun, 16 Jun 2024 08:00:00 +0800

过度设计的反面是务实

去年接手了一套系统，花了近三个月做了一些调整才正式外发。

当时这套系统是为了满足一个时间点快速迭代发布的，接手后觉得其中有一些问题，聊聊其中做的一些决策。

模块存在的合理性

case1

A 项目和 B 项目都是 Django+DRF 提供的服务。

仔细阅读代码后发现

B 项目逻辑并不复杂，但是麻雀虽小五脏俱全，DB、缓存、配置、helm-charts，出包流水线等都得来一套
存在一些共同的逻辑，抽象出一个 SDK 来实现逻辑复用
A 项目需要调用 B 项目，此时封装一层独立的调用逻辑（B 项目加一个接口，需要同步改这里）
为同一套前端提供的服务（通过k8s svc将请求转发到不同项目）

同构的技术栈，强耦合的逻辑，却是两个独立的项目。

能否合并成一个项目？答案是可以。

花了几个小时，将 B 项目的差异化代码直接拷贝到 A 项目，去掉 SDK，独立调用层改成直接函数调用，去掉对应的helm-charts，出包流水线等等。

结果：

项目 -1
SDK -1
流水线 -1
helm-chart -1
A 项目中调用逻辑 -1

整体的维护成本，复杂度等都降低了。

一个服务是否拆分成多个，以及多个服务是否应该合并成一个，取决于很多因素，不一定说拆分一定不好，但是拆分带来的维护成本往往是大于单体的。

case2

A 项目启动时，会从一个静态文件服务器 B 拉取一些运行时文件，B 是可以动态更新这些文件的。这样做的好处，是为了方便用户侧动态更新一些文件，直接 rolling update A 就能使得线上接口刷新成新的。

当然，这样做时候代价的，需要维护服务 B，同时 A 需要嵌入拉取逻辑。

问，这个机制目前有使用场景吗？没有，但是可能有。

这个就有点臆测未来用户侧的使用场景了，这种更应该有真实用户反馈过来再去加上，而不是一开始就加上。

所以，选择了去掉静态文件服务器 B, 直接在 A 项目打镜像时将运行时依赖文件打进去，相当于强耦合。我们甚至留了口子，如果用户侧需要更新，基于 A 镜像再打一个镜像，问题是上线一年多一次也没遇到。

结果：

项目 -1
A 项目中的拉取更新逻辑 -1

case3

重构时，A 项目使用了最新的实现方案，去替代 B 项目，二者语言和技术栈完全不一样。

B 项目中有个频率控制逻辑，使用的漏桶算法，而 A 的生态中频率控制算法只有fixed window，由于觉得漏桶算法效果更好，并且时间很赶并没有多余的精力在 A 中实现漏桶算法。所以将 B 中的漏桶算法直接挪出来独立成一个模块 C，然后 A 项目实现对应逻辑依赖模块 C。

相当于异构的实现，通过 RPC 协议交互。

但是这样引入了额外的模块和复杂度。

那么， fixed window频率控制算法在实际用户使用中真的会有问题吗？是的，会有问题，但是最终的频率控制效果用户能接受吗？

捞了线上正在运行的 B 项目的频率控制触发的日志，发现实际上用户侧配置的值一般都比较高，并且很少有触发的频率控制的调用方。

最终，我们决定去掉这个模块 C，直接使用 A 生态中基于fixed window的频率控制。

上线后只出现了一两例触发极端情况的场景，但是这个也给我们在 A 项目中实现漏桶算法提供了充足的缓冲时间。

如果效果差不多，或者稍微差一点但是能接受，那么不一定需要引入一个新模块来解决问题。

模块实现的合理性

case1

A 项目需要用到外部鉴权，依赖于外部的权限数据。此时引入一个模块 B，B 使用 A 生态的多语言框架实现（不同的语言），内部通过 RPC 交互。B 通过 HTTP 调用Web做全量以及增量的权限数据同步。

相当于： A => RPC => B => HTTP => Web Server

由于这个全量、增量同步做得很复杂，并且做了一层cache，导致线上出现权限问题时并不好排查。并且 Web Server 是一个产品项目，发布频率高并且稳定性低于 A。

那么为什么使用多语言框架呢？可能刚好官方支持吧（坑比较多），这时候有点像是拿着锤子满世界都是钉子，往里面放也行。

感觉掉坑里了，能否去掉 B 模块呢？

最终经过评审，我们的实现非常简单A => HTTP => Core Server => DB，不存在全量、增量数据同步，直接依赖 DB，加了一层缓存，整体复杂度非常低。

有时候生态里面一些亮点、强力的 feature，并不一定是好事，平平无奇的机制能实现的话，不一定要用。

case2

A 项目生态中有一个白名单，历史 B 项目中也有个白名单逻辑，然后在从 B 项目升级到 A 项目的过程中，竟然在 A 项目也实现了 B 项目的白名单逻辑，即同时存在两个白名单逻辑。

两个白名单逻辑本质上是一致的。

决策：升级过程中做简单的数据迁移，只留一个白名单逻辑。

不合理的依赖

case1 反向依赖

上面模块合理性的case，底层对可用性要求更高的模块，依赖了上层可用性不那么高的Web Server模块，直接拉低了整体的可用性。

通过新起一个更底层的服务，只依赖于 DB，独立于Web Server，将之前的依赖链路抹掉，变成可靠性更高的链路。

case2 循环依赖

A 项目是一个业务网关，依赖了一个认证项目 B，实施的时候，发现这个 B 的地址竟然是 A 项目的子路径。

原来是因为这个认证逻辑本身没有流水日志用于问题排查，所以将 B 项目接入了 A 项目网管。

此时即循环依赖 A 的认证逻辑依赖了 A 自己的网关地址；

后来决策，依赖地址直接改成B 服务，流水日志 B 项目自行解决。

其他相关的

过于灵活的配置

项目的配置文件生成：原始helm chart中的template有一个configmap，并且有一批环境变量，在启动的shell脚本中，读取环境变量，并且用 envset、sed 等命令，将配置文件和镜像中的配置文件合并生成一个新的文件。相当于，配置有 3 个来源，configmap/镜像中的yaml/环境变量中的配置。

这样看起来非常灵活，一系列判断逻辑可以根据一些开关、环境变量，生成差异化的配置，然后启动；

但是带来的问题是，在 shell 脚本中维护这个逻辑可维护性无疑是非常差的，并且认知负担非常重。

后来做的决策是，去掉启动脚本中的逻辑，在configmap中由 helm 的语法、模板负责生成一个完备的配置，即所见即所得。

这样所有的差异化在模板阶段就处理掉了，而不是在运行时处理。

有时候，灵活的配置，强大的脚本，看起来很厉害，但是并不一定是好事，特别是来源多，条件复杂这种场景。这时候，唯一来源，并且看起来有些笨的方式，反而是最好维护的。

过于冗长的流水线

存在不一定合理

由于之前处于快速迭代期，交付期间出现过各个环节的问题，导致出包的流水线非常长，几乎要二三十分钟才能出一个包，一旦有问题重出又是二三十分钟。

流水线中很多环节，是为了 cover 掉之前快速迭代容易遗漏的一些点，例如依赖包遗漏不熟检查，例如打包后执行一次helm install部署测试。这些环节耗时都比较长，并且是同步的。

但是，当过来快速迭代期之后，依赖变更已经不频繁，并且出现了其他环节能够cover掉出包过程中的早期测试，那么原先有效的环节可能变得非常鸡肋。

不删只是慢了点，存在即合理，会导致很多时候不敢去改流水线，去掉这些鸡肋。

后来复盘，统一删除，将时间压缩到 5 分钟以内。

过多的测试用例、测试环境及流程

使用 A 项目替换掉之前的 B 项目，但是，没有重新去梳理 case，而是在 B 项目的 case 基础上又加了一批 case；并且也没有重新做差异化的梳理，导致出现了 4 套测试环境+300多个case；

每个环境的 case 都是提前造好的，接手后，正式发布前需要把 4 个环境升级上来，并且执行完所有 case，有失败的需要逐一去排查原因。

这样带来的问题是，出包后的测试成本也非常高，并且 4 套环境的维护，case 的更新代价也很高。

你不跑，怕有问题没覆盖到，去跑，又得更新四套环境逐一验证，没过的 case 还得逐一确认修复。

后来，我们决定进行测试左移，到开发阶段而不是出包后，重新梳理 case，变成原先三分之一，并且能够在任意环境，自动构建环境，执行覆盖所有case。

聊聊框架

Sat, 08 Jun 2024 08:00:00 +0800

很久没写了，感觉是要提高下更新频率了。

今天聊聊框架，线索是我的工作经历。

刚毕业那会

大学的时候，因为学的是软件工程，所以高级编程语言当时教的是 Java，当时所有教材都是英文版的大部头。

那时候选修课，学了 XML，学了设计模式，当然只是学，一知半解。

然后疯狂地用 Java 写东西，做项目，调试，学 Servlet/JSP（最近去了图书馆，发现2024了尽然还有JSP的新书，真是。。。。）所以毕业前，我一直认为自己未来会加入 Java 大军（想想那时候真的如日中天，想不到自己后来用的语言越来越小众）。

无脑学习 SSH，包括大四实习那会，只有我一个进入了 Java 组，当时花了很多时间折腾实习公司的自研框架，徒手搭建。

那时候对框架是无脑地崇拜，这里配配那里配配就 work 了，很神奇，但是如果一个 xml typo 就可能让你 debug 半天，这可能也是后来自己对框架的偏好会倾向于：不喜欢约定 过多的框架。

毕业了

我并没有如愿以偿加入 Java 大军，如果当时选了那条路，可能至今还在北漂。

后来面了阿里的 SDET，选择了杭州，然后南下了。

那时候工作，测试多余开发，常常加班，常常周末去公司，

工作的关系，接触了非常多的语言，Java/C++/Perl（现在应该很少人用了吧）/Python/Bash 等等，然后用 Python 实现了一些提升效率的测试工具。算是在繁忙的测试工作中寻找到一点开发的乐趣。

后来决定走，原因是因为想做回开发。算是遵从自己的内心吧。

那时候自己啃 Python 那本《Python 学习手册》，都快翻烂了。

然后网上投了简历，拿了个 Offer 之后，南下深圳。

第二份工作

测试转开发，并且是 Python 开发，准确来说是 Web 开发。

那时候对框架没啥概念，因为做测试工具的时候并没有机会接触太多，只懂一些皮毛。

那时候小组内重度使用 Tornado 以及 Flask。

目前 Tornado 应该很少人使用了吧？当时的感觉是写起来有点别扭，不过也还行。然后另一个就是 Flask。因为当时是 CS 架构，所以主要工作就是写 API。

对 Flask 也算情有独钟吧，轻量，简单直接，好用，产出效率杠杠的，是我喜欢的类型。

当时也自学了下 Django，第一印象，约定 有点多，有点重，额，不喜欢。

第三份工作

后来我司因为不可抗力，额，没了。

当时找工作，那时候是 2014 年左右，万众创业，满地的创业公司。根本没有找大厂，直接去了一家小创业公司，CEO 是国外回来的，用的 Python，后端开发加我一共三个。

那时候技术栈也是 Flask，原因是第一个招进来懂 Python 哥们（很厉害）的个人偏好。

做得还行吧，但是小公司管理后台的需求比较多，后来竟然需要一个专职开发做管理后台（Flask+Sqlalchemy+Flask-admin)。

第四份工作，至今

后来不到十个月，额，又没了。

Gap 了 100 天，找工作，面试进了大厂。

一二十个 Python 开发的一个中心（现在应该翻了几倍），做 Django。

从抗拒 Django，理解 Django，到选择 Django，也算是经历了完整历程。

后来上 DRF，也是抗拒，还行（但是还谈不上喜欢）。

内部也形成了比较好的分层/规范等。

后来技术栈加入 Golang, 一开始 Gin + GORM(v1) 感觉有点香，但是后来主导两个大项目的选型，一个用的 Chi + Sqlx（网关），另一个用的 Gin + Sqlx（权限中心）。

但是实际使用很多第三方框架，或者配合做一些开发，由于主导权不在自己手里，可以看到很多不是特别合理的配置。例如：巨无霸开发框架（应该用 Core+Contrib 的模式更为合理），为了微服务而微服务的框架（加个字段加 N 层 N 个项目），手搓的 ORM，手搓的 XXX。

那么框架怎么选？

用不用框架？特别是做 Golang 的时候，直接用标准库，也不是不行。

如果是简单或者小项目，用什么其实无所谓。但是，如果是多人协作/需求复杂这类项目，用个框架显然能事半功倍。因为不用框架，可能很多很细碎的业务无关的功能，都需要手搓，然后慢慢慢慢，你的项目中的框架其实跟社区的框架差不多。

框架对于生产力有一个非常大的提升，原因是，社区红利。一个好的框架，其生态非常完善，你遇到的 90% 以上的问题，都有现成的解法，即使没有现成的，也有可以参考的。

Go 当时的 Web 框架非常之多，各有特色，但是现在显然 Gin 胜出了。

Python 的同上，Django 目前应该算第一 (FastAPI 是后起之秀，用起来很强大，但是，我不喜欢约定过多的框架)

原则就是：除非某个框架的 feature 特别适用于你的业务场景 (或者排第一的框架不能满足某个硬性条件)，否则选社区最流行的，这样能少踩很多坑。

并且，不要因为协作开发中某个人特别熟悉某个相对小众的框架而选择它，最好还是客观评估。有时候宁愿选择大家都不怎么熟悉但是简单的，而不是某个人精通的（你擦几次这种项目的屁股就知道有多难受了）。

选择框架的标准，我觉得应该是：一个初级开发没有接触过，能在一周内通过阅读文档，搭建环境，写 Demo 的方式熟悉大体的框架，并且能在第二周开始修简单的 bug。

有哪些需要注意的？

尽量避免手搓轮子！尽量避免手搓轮子！尽量避免手搓轮子！（强调三遍，受过太多苦）

大部份通用的功能，框架或开源的实现中都有，应该先看框架中本身是否自带，如果没有，寻求第三方库，如果还没有，再考虑自己实现。

尽量避免：

框架一般已经做到极简，堆业务逻辑出现一些代码上的重复是正常的，不要为了少写几行代码，在框架之上又封装了一层，相当于在约定之上，又做了一层自定义约定（其他维护者会骂娘的，没有共识，而是在框架的认知负担之上，又要学习这一层约定，复杂度太高，百害无一利）– 写代码的人爽了，维护代码的人非常不爽（要是一个人的项目，当我没说）
不要炫技。写一个 DSL 和平铺几个实现，我更倾向于后者。
不要一开始就上可扩展性，大量的抽象加一两个具体实现。

记住，可维护性更重要。

框架该怎么用？

像 Django 和 DRF 这类框架非常强大，不同人可以写出不同风格的代码，例如我们最早的 FBV 和 CBV，使用 DRF 可以继承 N 种 View/Viewset 实现。

但是这样的代码是不利于多人协作维护的。

应该形成项目内，或者组内的统一规范（这种规范静态代码检查大部份是扫不出来的）。

例如：

纯 Django 项目应该使用 CBV，禁止用 FBV
使用 DRF 时，禁止直接继承 *ViewSet，只允许继承 *APIView
SLZ 只允许到 View，禁止下传，禁止在其他模块用到

相当于，需要去学习框架，了解框架，用起来，知道各种用法/风格的优缺点，然后，在组织内形成共识，并落地为规范，这个规范新人在接触项目的第一天就能看到，新人看到的代码不会出现意外的惊喜。

那么，代码是不是太无趣了？

这时候写代码，是不是有点无聊？

因为框架限制了你，或者内部的规范限制了你？

是的，可能或者大概率会有点无聊，但是，上面的选择，是多人协作下比较稳的一种选择，或者说效率比较高的选择。

你是否经历过，google 一个小众框架报错只有几条结果甚至没有结果，然后花几天时间一点点 debug 解决（很有成就感是吧？）；实现一个通用需求别的框架只需要一行配置而你用的这个需要自己手搓两天（可能搓出来也很有成就感是吧？）；接手一个项目发现里面有七八种用法，甚至没有分层，在各个地方访问数据库（骂娘）；接手一个项目发现用法跟标准框架不一样，而是多了一层封装，得去学习自定义的约定，问题是封装的不咋地老是得去擦屁股，然后查问题一查查一天（每天都来几个问题遇到过没？我遇到过）

自己写的爽，但是坑了未来的自己或者其他接手的开发，还是说，稍微不那么爽，效率高点少加班。

其实还是有一些有趣的。

你可以考虑分层，模块之间的依赖关系，数据的流转，做一些扩展，或者 dig 到更深的地方看看是怎么实现的。

其他

如果是 个人项目, 要用啥都行，手搓都行，开心就好。

如果是 一个人的项目，谨记客观选型不炫技，未来维护成本低，别人接手不骂。

如果是 多人协作的项目，复杂度越低越好，可维护性越高越好。

关于 k8s 的 zero downtime deployment 一些建议

Sun, 17 Dec 2023 22:00:00 +0800

问题

后端服务对接了 API 网关, 服务正常, 但是在滚动更新的时候, 会出现 502

滚动更新时, k8s会起新的pod, 同时删除老的pod

可能原因:

新的pod启动后, 标记为ready但实际服务并没有准备好
老的pod在删除时, 已经在处理的请求没有处理完就退出, 或者退出时还有流量进来

解决

需要通过一系列配置, 做到 zero downtime rolling update (可以google相关的关键字了解更多), 以下给到一些建议

1. 配置 liveness/rediness

liveness 判断一个pod是否正常启动, 进入Running状态
rediness 判断一个pod是否完成了所有必要的初始化动作, 可以开始提供服务, 进入Ready状态

pod 进入 Ready 状态意味着此时会有流量进来, 此时如果进程无法提供正常服务, 会导致 502

所以, 需要确保 rediness 的正确性, 使得进程可以提供服务之后, pod 才进入 Ready 状态

2. 配置 terminationGracePeriodSeconds

terminationGracePeriodSeconds, 最长的宽限期，是允许 Pod 在收到终止信号后优雅关闭的最大时间。如果 Pod 在这个时间结束之前已经自主成功退出，那么 Kubernetes 就会立即进行后续的清理回收步骤, 默认是 30s

如果pod被删除时, 后端服务有正在处理的请求, 并且请求需要超过 30s 才能处理完, 此时服务无法正常 graceful shutdown, 会被强杀, 导致 502.

所以这个值需要设置为 terminationGracePeriodSeconds > 服务承诺的最大的请求耗时时间 + 进程graceful shutdown耗时, 例如你的服务设置的处理请求最大超时时间是 60s, 那么 terminationGracePeriodSeconds 需要大于 60s

3. 程序要支持 graceful shutdown

确保正在处理的请求能被全部处理完之后再结束, 需要监听 SIGTERM 信号并且处理

例如 golang 1.18中支持 Server.Shutdown

Shutdown gracefully shuts down the server without interrupting any active connections. Shutdown works by first closing all open listeners, then closing all idle connections, and then waiting indefinitely for connections to return to idle and then shut down. If the provided context expires before the shutdown is complete, Shutdown returns the context’s error, otherwise it returns any error returned from closing the Server’s underlying Listener(s).

如何验证: 发送一个请求, 请求正在处理时, 发送SIGTERM信号给进程, 这个请求能被正常处理完

4. 主进程在容器中的 pid 必须为 1

这样才能正常接收到信号

某些应用编写了自定义脚本来启动服务, 但是pid=1的进程是这个脚本而不是服务, 这样会导致服务没法接收到信号并做graceful shutdown

例如:

/bin/bash -c app, 信号是shell收到的, app收不到
用exec

5. 配置 `preStop`

建议配置 preStop

配置后执行的顺序 preStop -> SIGTERM -> SIGKILL

先执行preStop脚本
之后给进程发送信号SIGTERM

另外一个502可能原因, 从service中摘除 pod endpoint和删除pod是同步进行的, 但是谁先谁后是不确定的(watch到变更, 独立的事件), 此时如果删除pod先执行并且程序很快退出, 此时可能endpoint还没有被摘除, 那么会出现 502

因为 preStop 之后 k8s会发送 SIGTERM, 所以如果进程pid=1并且处理了SIGTERM信号能很好地进行graceful shutdown, 那么只需要加一个sleep确保没有流量进来

        lifecycle:
          preStop:
            exec:
              command:
              - sleep
              - 30

注意: 这个sleep的 30s 只是一个示例, 各个后端服务要自行压测确定, 例如如果集群使用ipvs+nodeport暴露服务到外部, 那么经验值是 sleep 120s, 此时注意terminationGracePeriodSeconds 需要配置并且大于 sleep时间+进程graceful shutdown时间

preStop也可以执行一些等待/资源回收/主动触发hook之类的操作, 但是需要注意:

如果preStop执行时间+进程graceful shutdown在 terminationGracePeriodSeconds 时间之内执行结束, 容器正常删除;
如果超过了terminationGracePeriodSeconds, 容器会被kill;
如果 preStop 阻塞住了, 直到超过terminationGracePeriodSeconds, 容器会被kill
如果 preStop 异常了, 容器会被kill

6. maxUnavailable/maxSurge

这两个跟 zero downtime 无关, 但是能降低影响范围

.spec.strategy.rollingUpdate.maxUnavailable, 滚动更新过程中，允许 “不可用” 的最大 Pod 数量; 默认 25%, 可以是绝对值或百分比
- 确保在更新期间始终有足够多的 Pod 保持可用, 避免因为可用实例过少带来的问题(健康的pod负载过高导致不健康)
.spec.strategy.rollingUpdate.maxSurge, 滚动更新过程中，允许 “超过” Desired Replicas 数的最大 Pod 数量; 默认 25%;
- 控制在更新过程中可能会暂时承受的额外负载

需要根据自身集群的资源/每个服务的负载等确定

怎么验证

部署 deployment
启动压测
滚动pod kubectl rollout restart deployment xxxx
如果压测结果中没有状态码为 502 的, 那么代表生效了

其他

websocket 这类服务能做到zero downtime么?

通过rolling update的方式无法做到, 需要其他方式, 例如部署两套后通过接入层做切换

参考文档

k8s pod-lifecycle

apisix 遇到的一些问题

Sat, 16 Dec 2023 08:00:00 +0800

背景

大约十年前，部门内部有一套 ESB, 一套网关服务，当时网关服务用的 Python (Django 框架), 处理了一些基本的认证/流控逻辑，但是无法支持高并发并且经过网关的性能损耗很大

在 2019 年，我们使用 Golang 重写了网关服务，性能大约是原来的 34 倍

至于选择 Golang 的原因，主要是因为：

团队内部有 Golang 的开发经验，当时基于 Golang 的开源网关比较多，例如 janus, KrakenD, tyk 等等
相反，团队内部没有 OpenResty 的开发和运维经验 (当时 OpenResty 及 Kong 比较火，并且当时 Apisix 并不火)

(我们的网关上线一年多之后，Apisix 团队有到我们内部做过分享，当时切到其他项目救火了并没有去听)

当时技术选型没有使用 gin, 而是 chi (轻量，100% compatible with net/http ) + std reverse proxy + dbless 模型 (借鉴 Kong 的概念)

做了两个大版本：

第一个版本，底层数据不变，完全实现了原来的功能，发布上线 (此时新老版本都可以运行，灰度过去)
第二个版本，重新设计了底层数据结构，重做了管理端功能，数据迁移发布切换到新版本

(这个版本的一直非常稳定，并且性能比 apisix 版本还好。得益于 goroutines / channels 以及无处不在的缓存)

然后在 2022 年，我们又遇到下一个问题：扩展性，我们有越来越多的需求

但是

Golang 要实现插件的成本太高了，并且缺乏生态，很多很常见的特性都需要自己实现
无法支持自定义插件的场景
无法支持热更新 (在内存中全量重建 radixtree 之后替换掉旧的)

在 2019 我切换去做权限系统，搞完之后又去接用户系统，到了 2023 四月份，由于某些原因，切回来接手新版的基于 apisix 的网关

接近八个月时间，很大部分时间在做架构调整以及重构，并且花费了很长一段时间验证新版本的稳定性，遇到了蛮多问题

最近在整理工作文档，汇总一下

简单梳理总结一下

架构调整和代码重构

原先的项目拆分的非常细碎，通过 SDK 共享代码，通过 API 做数据交互

合并管理端的项目到一个单体项目，去掉 SDK 及交互 API
删除过度设计的模块，使用更直接/务实的方式实现
去除基于 apisix-go-plugin-runner 实现的权限数据同步/鉴权模块，使用 HTTP + lrucache 方式实现 (简单，不用考虑数据一致性)
去除基于 apisix-go-plugin-runner 实现的基于漏桶算法的频率控制，使用原生插件实现 (fixed-windows, 务实，虽然效果不如漏桶)
去反向依赖
对代码进行重构，模块及分层，提升可读性; 同时增加单元测试，引入 test-nginx
集成测试左移
对 dockerfile, helm-charts, 各种运维脚本进行优化，优化出包流水线
增加多套环境用于不同场景的测试
……

(这块花了很多时间，才做到 production ready, 主要是又得在开飞机的时候换引擎)

Apisix 相关的问题

升级：2.15 升级到 3.2.1

基本按照 Upgrade Guide 阅读，评估后直接升级到 3.2.1

主要的变更还是配置文件，顺带还把原先配置文件的生成方式重写，直接 helm 生成最终用的文件，抹掉了在容器启动时各种 sed/subst 之类的操作

其实后来还尝试升级到 3.2.2, 当时以为是一个小版本，结果合入了一个 pr #9456 feat(config_etcd): use a single long http connection to watch all resources, 导致了 bug: route 404 after upgrade to 3.2.2, 原因是etcd prefix中带了-, 在这个 fix: can’t sync etcd data if key has special character 中修复了

带了 9456 这个特性的版本都需要关注下这个 PR 后面带的一批 bugfix (应该有四五个了，并且都比较重要，所以建议用最新版)

prometheus 的问题

apisix 3.2.1 已经合入 #8434 feat(prometheus): support collect metrics works in the priviledged agent, 所以理论上由于 prometheus 带来的性能问题应该已经解决了。(相关文章从 1 秒到 10 毫秒！在 APISIX 中减少 Prometheus 请求阻塞)
踩坑 1: 最早我们网关的 prometheus 自定义指标中，使用了 path 而不是 matched_uri作为 label, 这样会导致/metrics中记录数爆炸式增长，带来性能问题
踩坑 2: 由于我们的 route 数量很多，官方的 local DEFAULT_BUCKETS = {1, 2, 5, 10, 20, 50, 100, 200, 500, 1000, 2000, 5000, 10000, 30000, 60000} 是写死的，非常大导致记录数很大。所以我们提了个 issue feat: The Prometheus plugin can now allow users to configure the DEFAULT_BUCKETS, 后来在 #9673 实现
- 解决：我们在构建镜像时自己 patch 了这个修复
踩坑 3: 某一天线上某个环境的 apisix 被 KILL 了，影响到业务，后来定位到是 CPU 超过了 limits 被 k8s 杀掉; 而这个环境的请求量并不大，通过分析我们发现是 prometheus 特权进程在处理/healthz时把 CPU 给打满了，bug: high cpu usage after prometheus.lua report ’no memory’, 原因还是官方的 metrics 记录数过多
- 解决：patch 一堆开关，支持从配置文件中关闭掉所有的官方 metrics, 只留下自定义 metrics
踩坑 4: 目前我们还遇到一个疑似内存泄露问题，看着也是跟 prometheus 插件有关系 help request: 3.2.1 memory leak, 暂时没有解决，生产环境分配比较大的内存 (涨到一定大小之后就趋于稳定了)

radixtree 最长路径匹配问题

发布后，有业务反馈其原先正常的路由目前被匹配到了另一个路由上

apisix:
  router:
    http: radixtree_uri_with_parameter

在这种类型的 radixtree 中，最长路径匹配实际上并不是确定的，跟路径被加入树中的顺序有关，bug: Adding routes to a Radix Tree in a different order can lead to the same URL matching the first added route instead of the longest path match

这个问题目前官方还没定位修复，我们目前是通过写入路由配置时，计算 priority，使得其看起来像最长路径匹配通过 priority 解决最长路径匹配失败：calculateMatchSubPathRoutePriority

DNS 服务出问题，恢复后，apisix 无法从解析失败中恢复

DNS 解析失败之后，有报错日志; 然后 DNS 服务恢复了，apisix 也一直无法将请求进行转发

报错：

2023/04/20 09:08:02 [error] 68#68: *151026556 [lua] resolver.lua:47: parse_domain(): failed to parse domain: aaa.com, error: failed to query the DNS serve
r: dns server error: 2 server failure, client: 1.1.1.1, server: _, request: "POST /api/v1/xxxxx HTTP/1.0", host: "aaa.com"
2023/04/20 09:08:02 [error] 68#68: *151026556 [lua] upstream.lua:79: parse_domain_for_nodes(): dns resolver domain: aaa.com error: failed to query the DNS
 server: dns server error: 2 server failure, client: 1.1.1.1, server: _, request: "POST /api/v1/xxxxx  HTTP/1.0", host: "aaa.com"
2023/04/20 09:08:02 [error] 68#68: *151026556 [lua] init.lua:540: http_access_phase(): failed to set upstream: no valid upstream node, client: 1.1.1.1, server: _, req
uest: "POST /api/v1/xxxxx HTTP/1.0", host: "aaa.com"

触发条件：route 有 upstream(upstream 中是域名), 并且 router 关联到了 service, 并且 service 中有 upstream

这个问题官方暂时没有定位修复，解决方法：自行 patch parse_domain_for_nodes

并且切换到更为稳定的 DNS 服务

管理端频繁变更带来的性能抖动

我们有几万个 route, 变更非常频繁，我们发现在管理端变更时，会导致 apisix 的性能抖动 help request: Is the radix tree rebuilt every time any route is updated?

后来通过阅读源码发现，每次 watch 到变更，都会导致 radixtree 重建，并且这个重建是同步的，会导致性能抖动

官方后来有个 feat: increment route update for radixtree host uri, radixtree uri and radi… 做增量更新优化

我们暂时的解决办法：如果有变更，定期重建 radixtree(而不是实时), 并且打散到一定范围的时间内，避免整体服务性能抖动，具体参考 radixtree_uri_with_parameter_rebuild_with_interval

url 路径参数中带中文会导致 404

apisix 上下文中使用的路径是decode过的，但是下层 radixtree 使用的是encode过的，会导致这类路径匹配 404

目前我们暂时用 10561 这种方式修复，但是这样做看着比较低效 (我们压测完发现差别不大，线上直接先 patch 了)

zero downtime deployment

发布时，正在处理的请求会受到影响 Is the apisix support preStop hook? for graceful shutdown

除了这个，还遇到 ipvs+linux 内核版本会导致滚动更新时，还会有持续的流量进入到正在 terminate 的 pod 中

etcd compacted 导致 apisix 全量拉取

生产环境上线后，etcd 会定期出现内存使用量告警，突然飙升，伴随着大量的 read 行为

查看 etcd 配置以及阅读 apisix 源码发现，etcd 当前配置 5 分钟定时 compacted 一次，存在发布变更的话，apisix watch 到 event 发现 err=compacted, 会导致 apisix 全量拉取数据，此时会导致大量的 read 行为，导致 etcd 内存飙升

所以建议 apisix 依赖的 etcd 配置 compaction mode 改成 revision, 相关文档

变更 etcd 配置：

auto-compaction-mode: revision
auto-compaction-retention: "1000"

file-logger 的性能问题

自定义插件，通过增加 batch-processor 解决 (本质上就是将 json encode 转移到了 nginx timer 里)

queryString 中使用分号作为分隔符

灰度过程中，有用户反馈拼接的参数没有生效，而在原来 Golang 版本网关中是正常的

排查发现，我们使用的是 Golang 1.6, 这个版本中，支持同时使用&和;作为 QueryString 的分隔符，然后这个特性在 Golang 1.7 中被去除了 Go 1.17 Release Notes: URL query parsing

所以，存量的请求中，原先有一些请求使用的是;作为分隔符，灰度到 Apisix 后就失效了

最后我们通过一个自定义插件，向前兼容了这批路由，原理很简单，把 ; 换成 & 再放回去解析

local new_args = string_replace(ctx.var.args, ";", "&")
core.request.set_uri_args(ctx, new_args)

偶发 502

有应用反应原先使用 nginx 作为反向代理的时候正常，接入 apisix 之后偶发 502

nginx 默认的配置 proxy_http_version 是 HTTP/1.0;

即没有配置的情况下，默认是 HTTP/1.0

但是 apisix 的默认配置

proxy_http_version 1.1;
keepalive_timeout 60s;

这就意味着，如果后端服务开启了 keepalive, 但是配置的 timeout 小于 60s, 那么就会出现偶发 502

实际验证中，对于 gunicorn 以 gevent/gthread 方式启动的服务，将默认的2s改成65s也不能规避这个问题，只能通过 --keep-alive 0 关闭 keepalive; 相关文档

关于在除夕前一天换了一个洗衣机的故事

Mon, 23 Jan 2023 00:15:00 +0800

先讲讲这件事情的经过:

六年前入住的时候, 买了倍科洗烘套装, 没有买洗烘一体以及为啥买了一个比较小众的品牌是源于 SMZDM 上一个评测(小众算是一个坑点), 洗衣机价值 2500 左右, 然后只有一个地漏所以买了个三通(第二个坑点)

去年洗衣机坏过一次, 不排水导致衣服没法洗, 无法甩干, 然后电话客服, 已经过了质保, 只有电机是保十年的. 然后安排了一个不知道什么第三方的维修师傅过来.

师傅捣鼓半天, 结论是排水泵坏了, 换个新的, 410 CNY, 加上上门费用快 500 了, 修完也的确好了(坑, 第三方, 无任何价目表, 换的也非原装不知道什么牌子的)

然后, 现在快除夕了, 又出现了衣服无法甩干, 总是在最后剩一分钟洗几个小时, 怀疑是排水泵又又又坏了.

考虑到大过年的估计师傅没法及时过来修, 并且按照上一次经验, 肯定给换个排水泵, 又是四五百, 急用的话, 换一个.

并且考虑到未来的售后, 买的小天鹅, 京东下单, 第二天送到, 顺带旧的洗衣机回收了 150, 自己安装(过年师傅没法上门), 然后第一次桶自洁洗就报故障码了, 看说明书, 确认是排水管堵塞, 把三通拆开确定是里面堵死了. 这说明上一台洗衣机是好的, 甚至是上上次维修其实也是没必要的(估计当时师傅清理了三通然后给换了排水泵). 心里 wtf.

老婆说你原先不是做过测试吗? 为啥没排查出来>_<

我想了想, 一部分在产品, 一部分在个人

1. 故障码

如果新买的洗衣机也没有故障码, 估计就得继续叫售后(这跟我上次空调杂音美的的师傅上门几次没修好退货买格力安装之后师傅发现是楼上空调滴水导致的, 这是另一个故事了)

旧的洗衣机没有任何故障码, 然后出错了也一直洗下去, 让你难以确认问题, 到底是哪坏了, 主板有没有问题(可能是比较老? 还是中国的洗衣机更懂中国?)

所以:

一报错旧停止, 不要无视报错继续执行后面的事情, 或者假装无事发生(吞掉异常)
要有错误码/错误信息, 产品给出提示, 说明书给出解决方案(小天鹅的故障码列表直接贴操作面板上了)

2. 你是否检查了所有地方?

因为洗衣机维修那次全程围观了修理师傅的修理手段, 跟debug很像, 无非是切换各种模式, 验证整个洗衣的过程环节是否都正常(当然, 我没有注意到他清理了三通….)

所以我一样地通过切换模式, 验证各个环节, 最后的结论是: 排水泵又坏了

但是, 无法洗衣甩干是现象, 排水泵坏了只是其中的原因, 应该还有其他几种可能(因为有过一次维修的记录相当然了)

是否确认了所有可能的原因? (如果我当时检查了过滤口/三通, 应该能省去一笔)

3. 经验

我基于上次维修的现象和结论, 对当前的现象和结论形成了定向的思维. 这 100% 是排水泵的问题

只是基于过于小众/时效性, 决定换一台更符合当前的迫切需求.

那么, 原先的经验真的是有帮助的吗?

我们都知道, bug都会相对集中在某几个地方, 那么当现象和上次一样的时候, 凭借过往的经验, 我们很容易下结论(很笃定的那种), 这个过程中相当于全新去排查一个问题, 会少了很多步骤, 以至于无法判断是否是其他问题导致的.

另一方面, 我觉得那个维修洗衣机的师傅的经验对他肯定是有帮助的, 虽然我现在我很大程度上确定当时排水泵是没问题的, 但是当时那个师傅是不是已经确认是三通的问题然后多换掉一个本来完好的东西呢?

4. 小众与大众

买家电, 空调/冰箱/洗衣机这种大家电, 售后很重要, 毕竟维修和更换的成本太大, 所以建议选 top2, 并且我的选择原则是噱头越少越好, 买热销的型号, 功能少但是非常实用的这种(可靠性更高). 售后很重要, 又让我想起了六年前倍科洗衣机安装师傅过来安装, 连运输固定滚筒的泡沫都没取出来(这就很离谱了), 维修师傅上门穿的是第三方品牌的衣服.

买小家电, 微波炉/空气炸锅之类的, 成本比较低, 坏了也不心疼, 建议也选top的, 某些产品可以尝试小众的.

那么我们平时在做技术选型, 同样会基于这些因素去考虑.

例如第三方库, star数/最近的版本/最近的issue/bug比例/个人项目还是某个组织的项目等等, 都需要纳入考虑

5. 说明书

新洗衣机的安装, 安装师傅电话说过节了没法来, 让我自己装装看.

也很简单, 有工具就行, 安装说明书写得很清楚.(虽然我看半天没看懂隔音条应该装在哪个位置/边缘还是内侧横杠)

当然, 宜家的说明书我觉得体验会更好一些, 从图中很多细节可以确认正反/方向之类的.

所以, 文档很重要, 好的文档可以节省双方很多时间.

后记: 对新买的洗衣机比较满意, 差了 6 年整体体验还是差异比较大的, 自动投放功能大大减轻洗衣负担, 容量比之前多了 2kg 但是更安静, 洗的速度也更快, 最重要的是, 价格比之前便宜:)

Django DRF 性能优化

Wed, 19 Oct 2022 01:00:00 +0800

1. DB 查询分析

步骤:

通过日志/监控等, 统计top 10的接口(URL及请求参数)
通过 APM 等, 统计慢接口top 10, 以及得到慢查询 SQL
开发环境, 开启SQL打印django.db.backends, 可以参考Logging raw SQL to the console in Django
构造 1/2步中收集的请求, 在开发环境复现
获取执行的 SQL
分析

分析:

SQL 的查询条件是否命中索引, 是否有全表扫描(mysql explain)
SQL 中查询返回字段是否可以减少
是否某些 SQL 不应该执行, 但是执行了(误用)
是否某些 SQL 可以合并成一次查询
是否可以不执行/只执行一次, 例如通过加入缓存

重点: 高频查询, 增加索引能解决很大一部分问题; 尽量避免全表扫描的存在.

2. serializer 优化

2.1 property or SerializerMethodField

N+1 selects problem

这两种, 在里面做了一些特殊操作, 例如执行一次db查询

class Foo(models.Model):
    @property
    def last_check_time(self):
        # property 放大
        cr = CheckRecords.objects.filter(is_success=True).latest()
        return cr.check_time if cr or None

class FooOutputSLZ(serializers.ModelSerializer):
    last_check_time = serializers.DateTimeField()
    bar = serializers.SerializerMethodField()

    def get_bar(self, obj):
        return Bar.objects.filter(foo_type=obj.type).first()

此时, 列表查询, page_size=100, 会产生 1+100+100=201 次 db 查询

优化:

不返回
加缓存, 例如增加外部一个方法get_bar_from_cache(foo_type: str)
通过serializer context在上层提前查好, 适合所有items公共的数据, 例如用户职位名称

class UserListApi(generics.ListAPIView):
    def get_serializer_context(self):
        # set into context, for slz to_representation
        return {"position_name_map": get_position_name_map_from_db()}

class UserOutputSLZ(serializers.ModelSerializer):
    position_name = serializers.SerializerMethodField()
    def get_position_name(self, obj):
        m =  self.context.get("position_name_map")
        return m.get(obj.position_id)

2.2 Serializer本身的性能问题

可以参考: Improve Serialization Performance in Django Rest Framework: How we reduced serialization time by 99%!

小改:

read_only=True
自己构建数据, 不使用serializer

class UserOutputSLZ(serializers.ModelSerializer):
    position = serializers.CharField(read_only=True)

data = []
for u in users:
    data.append({
        "id": user.id,
        "name": user.name,
    })
return Response(data=data, status=status.HTTP_200_OK)

3. queryset 优化

3.1 defer / only 等, 只查询想要的字段

如果模型中存在一些本次逻辑用不上的字段, 那么不要查询出来, 或者声明只查询想要的字段

例如create_time/update_time
description/content/extras等 TextField or JsonField

使用 django queryset only() 只获取指定字段

Department.objects.only("id", "name")

使用 django queryset defer() 延迟获取某些字段

Department.objects.defer("description", "extras", "create_time")

可以在打印的 SQL 中看到 SELECT 字段列表的变化.

3.2 values()/values_list()

以dict/tuple的形式获取结果列表, 避免对象创建

# got List[Dict]
Department.objects.values("id", "name")

# got List[Tuple]
Department.objects.values_list("id", "name")

values_list()如果只获取一个字段, 那么可以加上flat=True, 直接获取返回列表

Department.objects.values_list('id', flat=True)

3.3 prefetch_related / selected_related

N+1 selects problem

这两个的目的都是将可能的多次查询合并, 减少 DB 查询次数, 可以参考这篇文章 Django的 select_related 和 prefetch_related 函数对 QuerySet 查询的优化

select_related(): “follow” foreign-key relationships, selecting additional related-object data when it executes its query. (SQL JOIN)
prefetch_related(): automatically retrieve, in a single batch, related objects for each of the specified lookups.(ANOTHER SQL)

注意, select_related/prefetch_related 的表如果数据量特别大(百万), 或者单页page_size特别大(几千/上万), 可能导致查询直接卡死

3.4 其他

use count()

# bad
len(User.objects.all())


# good
User.objects.count()

use exists()

# bad
if User.objects.filter(username=x):
    dosomething

# good
if  User.objects.filter(username=x).exists():
    dosomething

use bulk_create()/bulk_update()

Entry.objects.bulk_create(objs, 1000)
Entry.objects.bulk_update(objs, ['headline'], 1000)

specific the updated fields

product.name = 'Name changed again'
product.save(update_fields=['name'])

use F

Reporter.objects.update(stories_filed=F('stories_filed') + 1)

4. 缓存: local memory or redis

没有加一层缓存解决不了的问题, 如果有, 加两层……

有些数据库查询, 每次请求都会触发; 有些请求会触发 N 次相同的重复查询;

这些不一定能通过上面列举的方法优化

可以根据业务场景, 考虑是否能加缓存

细粒度:

from django.core.cache import caches

def get_default_department_id_from_cache() -> int:
    cache = caches["locmem"]
    id = cache.get(DEFAULT_DEPT_ID)
    if id is not None:
        return id

    id = Department.objects.get_default().id
    cache.set(DEFAULT_DEPT_ID, category_id, 1 * 60)
    return id

粗粒度: cache_page: The per-view cache

DRF 的一些实践 Part1: Serializer

Sun, 09 Oct 2022 01:00:00 +0800

SLZ 只做输入/输出相关的逻辑, 尽量避免处理具体的业务逻辑

命名建议

写全 xxSerializers
也可以用缩写xxSLZ(注意全大写, 不要用xxSlz)

两种风格

1. 全部serializer放在一起

同一个application的全部serializer放在一起

application
    |- serializers.py

如果都放在一起, 建议区分 input 和 output

class LoginLogInputSLZ(serializers.Serializer):
    pass

class LoginLogOutputSLZ(serializers.Serializer):
    pass

class LoginLogListApi(generics.ListAPIView):
    serializer_class = LoginLogOutputSLZ

2. 直接放在view中

放在api定义中(Serializer should be nested in the API and be named either InputSerializer or OutputSerializer)

class UserListApi(APIView):
    class OutputSerializer(serializers.Serializer):
        pass

    class InputSerializer(serializers.Serializer):
        pass

    def get(self, request):
        users = user_list()

        data = self.OutputSerializer(users, many=True).data

        return Response(data)

InputSLZ

只做校验相关的逻辑, 避免放入业务逻辑

1. method: validate_{field}

校验某个字段: validate_{field}

from rest_framework import serializers

class BlogPostSerializer(serializers.Serializer):
    title = serializers.CharField(max_length=100)
    content = serializers.CharField()

    def validate_title(self, value):
        """
        Check that the blog post is about Django.
        """
        if 'django' not in value.lower():
            raise serializers.ValidationError("Blog post is not about Django")
        return value

2. method: validate

整体校验(对象级别): validate

from rest_framework import serializers

class EventSerializer(serializers.Serializer):
    description = serializers.CharField(max_length=100)
    start = serializers.DateTimeField()
    finish = serializers.DateTimeField()

    def validate(self, data):
        """
        Check that the start is before the stop.
        """
        if data['start'] > data['finish']:
            raise serializers.ValidationError("finish must occur after start")
        return data

3. validators

官方文档: Validators

复用 validate 方法

def multiple_of_ten(value):
    if value % 10 != 0:
        raise serializers.ValidationError('Not a multiple of ten')

class GameRecord(serializers.Serializer):
    score = IntegerField(validators=[multiple_of_ten])
    ...

4. to_internal_value

官方文档: Overriding serialization and deserialization behavior

如果输入的表单和业务模型数据结构差异很大, 需要做全局转换, 可以使用 to_internal_value 统一处理

class DynamicFieldUpdateInputSLZ(serializers.Serializer):
    def to_internal_value(self, data):
        field_a = data.get("field_a")
        # do something with field_a
        return {
            "x": field_a
        }

OutputSLZ

只做展示拼装相关的逻辑

1. SerializerMethodField

使用 SerializerMethodField 做一些转换/格式化/映射之类的逻辑

class LoginLogOutputSLZ(serializers.Serializer):
    datetime = serializers.SerializerMethodField(help_text=_("登录时间"), required=False)

    def get_datetime(self, obj):
        return obj.create_time

注意: 尽量避免在 SerializerMethodField或者model的@property中做一些独立的查询工作, 这样会带来查询放大, 一次请求查 1000 条数据, 可能会有 1001 次数据库查询

class Profile(models.Model):
    @property
    def last_login_time(self) -> Optional[datetime.datetime]:
        """获取用户最近一次登录时间"""
        latest_login = self.login_set.filter(is_success=True).latest()

        if latest_login:
            return latest_login.create_time

        return None

如果在多个SLZ中反复出现同一个SerializerMethodField

处理逻辑跟展示层关系不大, 可下沉到model的@property
处理逻辑跟展示层有关系, 可以抽象成mixin

2. to_representation

官方文档: Overriding serialization and deserialization behavior

如果需要做较大的转换, 例如得到的模型数据相对返回的数据结构差异很大, 需要做大量的转换/映射/内嵌/判断等, 此时可以直接定义to_representation(self, obj)简化

class GeneralLogOutputSLZ(serializers.Serializer):
    id = serializers.IntegerField(help_text=_("ID"))
    extra_value = serializers.JSONField(help_text=_("额外信息"))

    def to_representation(self, obj):
        instance = super().to_representation(obj)
        extra_value = instance["extra_value"]

        field_a = extra_value.get("field_a")
        return {
            "field_a": field_a,
            "filed_b": field_b,
        }

3. serializer_context

通过get_serializer_context设置context变量, 之后在渲染时可以通过self.context.get("{KEY}")获取

class LoginLogListApi(generics.ListAPIView):
    serializer_class = LoginLogOutputSLZ

    def get_serializer_context(self):
        # request/format/view
        ctx = super().get_serializer_context(self)
        ctx["category_name_map"] =  get_category_display_name_map()
        return ctx

class LoginLogOutputSLZ(serializers.Serializer):
    category_display_name = serializers.SerializerMethodField(help_text=_("所属目录"), required=False)

    def get_category_display_name(self, obj) -> str:
        """get category display name from log extra value"""
        category_id = obj.profile.id
        category_name_map = self.context.get("category_name_map")
        category_display_name = category_name_map.get(category_id, PLACE_HOLDER)
        return category_display_name

坑: 如果自己实例化slz, 需要显式传递context, 否则在slz中是拿不到的

context = self.get_serializer_context()
xxOutputSLZ(results, many=True, context=context)

SLZ 传递的参数

input slz 可能传递一些查询相关的参数, 例如 order_by=create_time
output slz可能传递一些返回结果相关的参数, 例如fields=a,b,c

逻辑上是需要支持的, 但是, 要严格控制字段白名单

例如, order_by只允许传递主键或有建立相关索引的字段名, 而不是任意字段, 避免 order_by=enabled这类查询无法命中索引带来的慢查询

同样, fileds应该避免允许传递重的property字段(存在额外查询). 如果调用方不传递, 应该默认使用最小化集合, 而不是全部;

ModelSerializer 尽量使用最小化集合

如果使用了serializers.ModelSerializer, Meta.fields尽量使用枚举, 或者配置exclude, 而不是fields = "__all__"

class CategorySettingOutputSLZ(serializers.ModelSerializer):
    class Meta:
        model = Setting
        fields = ["key", "namespace", "region", "value", "enabled"]
        # 尽量避免
        # fields = "__all__"

        # 可以用这个, 但是后续加新字段可能会忘记加exclude
        # exclude = ("create_time", "update_time")

避免:

暴露不必要的字段出去, (场景: 未来字段变更想去掉, 如果原来没有暴露, 那么直接去, 否则需要找调用方逐一确认)
不小心暴露不能更新的字段出去, 例如create_time/update_time

单一职责

单一职责原则: 一个slz只给一个view使用, 尽量避免多个view共用一个slz

不一定需要继承: 复用 vs 不复用

极端处理: 每个 slz 都是独立的, 及时存在公共字段, 也不抽父类出来;

带来的后果: 字段的变更/校验逻辑变更等, 需要改动涉及的所有 slz

使用继承: 变更只需要改一个地方, 但是存在风险, 改一个地方可能动到意想不到的其他接口校验/返回

倾向的做法:

刚开始开发, 完全不考虑继承, 完全独立
主体逻辑和接口开发完之后, 可以根据需要加入部分继承, 例如公共的create_time/update_time等字段
如果使用继承, 尽量减少继承的层级(不大于 3 层), 并且需要考虑隔离: 输入/输出的 slz 父类进行隔离, 或者核心模块slz和非核心模块slz隔离, 即使它们有相同的字段;(缩小未来变更的影响范围)

DRF继承关系图

Fri, 07 Oct 2022 22:00:00 +0800

最佳实践:

业务逻辑类, 尽量继承于右下角的这批基类, 以保持简单(所有开发有共同的框架背景认识)
尽量不要在业务逻辑类与 DRF 基类之间增加一层 公共基类(避免引入意大利面式的调用链, 阅读困难, 带来认知负担)
只实现最小的扩展, 做到望名知意, 切忌实现大而全的扩展
使用 DRF 的大多数情况下, 代码越多越好维护

Better Code: 关于接口的灵活性

Fri, 08 Jul 2022 23:00:00 +0800

在实际需求开发中，我们会面对复杂多变的需求。所以在给外部提供API的时候，经常会面临接口协议的变更：例如增加一个查询字段，支持按照某个字段升降序，或者多返回某个字段。

此时你也许会想，不如直接支持graphql或者类似的语法，将整个模型暴露出来，想要什么字段，根据什么排序，查询多少数据量，按照什么升降序自己决定好了。这样能做到一次开发，多次使用，一劳永逸。

但是，这往往是过于理想化的考虑，特别是对于大部分项目，或者被非常多外部系统依赖的服务（这也是为什么需求变更比较多的原因）

在实际开发中，我们都知道，一个接口一旦上线生产，那么协议变更就变得非常难，至少要非常谨慎。因为有众多的依赖方。并且下线一个接口也尤为困难，因为势必要推动所有系统切换新接口。

所以，如果暴露整个模型由调用方自行选择，那么结果就是，将主动权交给了调用方，把自己变得被动。因为你很难感知到调用方是如何组合那些条件的，用了哪些参数，是否合理。模型层面的变更将变得困难，字段的增删，类型变更，格式变更等等都需要考虑诸多调用方。

相当于拿一时的便利，换取了未来维护的不确定性。但是，确定的是，维护成本是成倍地上升。

假设模型数据变得庞大，从几千增长为十万级，百万级，那么原先很多无关紧要条件变得棘手，例如按照一个不确定的字段排序，或者一个不在索引中的字段排序。此时原先的查询变得很慢，数据库压力变大，机器负载上升。

那么，这时候要保证系统正常，就会付出更大的代价。

这个可不是提供一个/api/v2那么简单，大部分系统一旦使用，除非特别的原因，否则是不会考虑迁移新接口的，此时，可能由于某几个很小的系统调用吃掉系统绝大部份的资源。举步维艰。

所以，在接口协议设计和提供的时候，需要花更多的时间去思考，始终保持谨慎，克制。

比如，需要一个字段，绝不提供两个。协议中可选的内容，都是已确认可控的内容。消除不确定性。

这或许看起来接口不够灵活，不够强大。但是，消除了不确定性。

应该在内部实现保持灵活，但暴露出去的保持克制。例如某些地方可以变成可配置的，需求变更只需要改配置而不是代码。

即，灵活性始终把握在自己手中。应对需求变更的时候，付出少量的时间。相对原先绝对灵活的方式会多出一些确认及开发的时间，但是对于未来的维护时间，这已经是非常划算的了。

内部支持，谨慎提供。 make everything under control

如果调用方可控，例如前后分离自己的前端或者同一个系统内的上层服务，那么用graphql 或者类似灵活的方式提供接口问题不大，毕竟变更或升级的成本不高，比较可控。

否则，提供接口不要那么奔放。

另外，最近遇到一个问题得到一个小的tip，如果一个接口需要提供两种或两种以上有差异的返回（协议有差别，但是不是特别大），建议提供多个接口而不是在一个接口通过参数动态确定返回。即使差异非常小。差异小只在当下，随着时间推移需求变化，耦合在一起的代码将会维护困难，改一个逻辑可能动到不相关的返回。宁可多写一些代码，尽量保持逻辑独立性。

新的仓库: wklken/naming

Sun, 03 Jul 2022 11:30:00 +0800

上一次开新项目, 还是 wklken/httptest, 还有很多功能没有完善

后来, 又fork了gorequest来了一回大修 wklken/gorequest

这次本来在写一片关于命名的文章, 然后花了几个小时通过bash+python+nltk, 写了一个项目

https://github.com/wklken/naming

目前完成了基本的结构, 分析了k8s整个仓库的命名

后续会花时间继续完善:

增加各种语言top10项目的分析
加入github action自动化
做一个主页, 关键字搜索关联的词/分类等
中文支持

希望这个项目, 能够在给接口/类/函数命名时, 给到提示, 节省时间, 提高效率.

缓存使用的一些经验

Sun, 26 Jun 2022 10:00:00 +0800

在一个大的项目中, 使用了全缓存模型, 即, 所有数据都会经过cache.

简单分层: 应用->内存缓存->redis缓存->数据库

是一个典型的多读写少的场景, 并且数据量, 请求量非常大.

总结了一些使用经验, 供参考

1. 更新缓存的Design Pattern: 使用Cache aside

简洁优雅

关于缓存更新, 可以阅读这篇文章: CoolShell: 缓存更新的套路

为什么选择Cache Aside Pattern, 因为这个模式足够简单, 出现不一致的概率非常低, 对于大多数项目来说够用了.

而其他几种模式, 复杂度会高很多.

2. 并发很高时, 需要防缓存击穿

当并发很高的时候, 一个热点key失效, 会触发回数据库重查的逻辑, 此时会有大量请求落到数据库

需要做防缓存击穿的处理.

一般各种语言的库, 都有考虑到这一点, 例如 go-redis/cache

如果是golang并且自定义了cache, 可以使用 singleflight, 其他语言也可以找类似机制的库.

这个库很轻量

# define
type Cache struct {
	name              string
	keyPrefix         string
	codec             *cache.Cache
	cli               *redis.Client
	defaultExpiration time.Duration
	G                 singleflight.Group
}

# usage
// if missing, call retrieveFunc
data, err, _ := c.G.Do(key.Key(), func() (interface{}, error) {
		return retrieveFunc(key)
	})

3. 缓存空值, 需要防缓存穿透

如果一个key不存在, 在缓存中查不到, 在数据库中也查不到, 那么这个key的请求每次都会穿透到数据库

此时, 可以引入 bloomfilter 或者 cuckoofilter;

但是, 更简单的做法是, 缓存空值; 当成一个普通的key处理(缓存失效/数据一致性处理等)

4. 总是设置过期时间, 并且带随机数避免缓存雪崩

大部分场景下, 给每一个缓存key设置 TTL是一个很好的习惯. 可以避免无用数据占用资源, 及时淘汰掉使用较少的数据.

但是, 设置TTL的时候, 建议加上一个范围内容的随机数, 避免缓存在同一时间失效, 造成缓存雪崩.

TTL = 900s + randint(0,10)

5. key 中使用namespace+version前缀

key = {namespace}:{version}:{type}:{uniqueKey}

在实际应用部署中, 由于可能跟其他应用共用一套缓存, 所以建议缓存的key加入前缀, 防止冲突(如果冲突, 非常难以debug)

另外, 需要加入一个version, 在版本发布必要时变更, 以弃用缓存中已有的数据

由于不断迭代开发, 同一个key对应的value可能会变更, 例如value对应的数据结构新增了一个字段, 那么此时缓存中存量的缓存数据是没有这个字段的, 可能会造成一些bug.
还有另外一个需要特别小心的是, 升级缓存第三方库的时候, 某些版本可能是breaking change, 例如改变了压缩算法, 此时存量数据将无法正确被获取.一个例子: Can’t upgrade from v7 to v8 directly?

6. 缓存结构体, 使用msgpack替代json

MessagePack: It’s like JSON.but fast and small

优点:

缺点:

在redis等服务端debug获取时不是明文, 不是很利于调试

所以, 缓存数据量比较大, 并且对性能有要求的, 可以使用msgpack

7. value比较大, 可以考虑启用压缩

如果value比较大, 那么在放入缓存前, 可以进行一次压缩, 获取后再解压

当然, 这个会产生额外的资源消耗(CPU), 以及会多一些耗时.

但是, 这个有利于减少网络传输中的包大小. 如果读取是非常高频的话, 那么代价还是值得的.

可以参考 go-redis/cache, 当值超过一定大小时使用 s2 compression 进行压缩

8. 批量操作, 使用pipeline

以redis为例, 批量操作

代码for循环, 一个个获取
可以考虑使用mget/mhget之类的多个key
使用pipeline

可以根据key-value特征, 批量key的数量等, 简单压测下性能, 决定使用哪种方式. 正常情况下, key数量较大的时候, pipeline性能最好.

甚至, 代码实现可以根据key的数量, 自行决定使用mget还是pipeline

9. 内存缓存 vs Redis

大部分情况, 项目中会混用两种缓存.

如果对数据一致性要求比较高, 可以全部使用 Redis.

但是, 其实每一次 Redis 操作代价大于内存操作

某些数据, 例如模型, 主键之类的, 一旦确定, 是不会变更的.

此时, 可以考虑使用内存缓存替代.

如果是golang, 推荐使用 go-cache. 没有其他实现那么强大, 但是胜在不需要序列化/反序列化.

10. 多级缓存 and client-side-cache

如果使用的 Redis6, 并且程序的driver支持, 那么可以直接利用 client-side-caching 特性获取最大的性能. 这个对程序透明, 无需在额外的逻辑处理.

但是, 当前(2022)有很多时候, 部署基建还是老版本Redis, 很多语言的driver也还没有支持, 可能复用不了

那么, 此时如果使用了内存->redis两级缓存, 如何确保数据一致性.

可以做的额外操作:

实现类似redis6 client-side-cache机制, 通过发布订阅等方式实现
可以使用一个sorted-set存储5分钟内变更的key, 内存缓存TTL设置5分钟; 每次先获取变更key列表, 本地缓存进行时间戳对比(这个方案对于批量key操作性能提升很大, 相当于把 N 次redis操作, 变成本地缓存+ 1 次 changedkeylist获取+M次redis操作)

11. 配置建议: 同时支持standalone和sentinel配置

让运维根据实际应用场景, 自行切换使用.

成本不高的话, 也可以支持下redis-cluster配置

注意, 开启pool以获取更好的性能

另外, 也需要关注下如何开启prometheus/otel相关的配置, 以便某些情况下, 监测相关的指标

12. 设置开关, 支持withCache/withoutCache调试

引入缓存后, 在进行问题调试的时候非常不变.

建议加入相关的调试标志, 例如?force=true

加上, 全链路数据获取走数据库
没加, 全链路走缓存

此时, 可以通过对比两次请求的差异, 确定是否是缓存问题

甚至, 可以加入?debug=true以获取各个环节的上下文信息, 快速调试

Better Code: 抽象: 可扩展性与可维护性的抉择

Tue, 21 Jun 2022 23:00:00 +0800

抽象程度

抽象程度高, 往往意味着: 灵活, 可扩展性高但是, 这也同时意味着: 复杂, 可维护性低

而可维护性在一个项目的生命周期中又是非常重要的, 一次开发编写的代码, 可能有几十倍的阅读/变更/debug等等

所以, 需要取得平衡, 但是这个度应该如何平衡?

至下而上: 够用+保留一定可扩展

务实的做法:

实现功能, 简单/粗暴/丑陋, but it works!
明确分层/已知的概念, 然后进行抽象, 第一次重构; (分层/模块切分/类切分/方法挪动)
明确什么是当前的需求, 以及可见范围内的需求(要长远, 但是不能过远, 正常, 2-3年的量, 支持当前十倍作用的上层业务考虑)
明确变更点, 开闭原则, 变更点意味着未来的可扩展性; 抽出概念, 适当使用相关的设计模式, 进行第二次重构; 此时, 可能会多几个概念, 多一些模式.(但是不会多很多)
重新组织代码, 测试功能, 加单测等, 交付
每一次新需求或需求变更, 再来重新审视设计, 概念以及层的合并/拆分, 然后重构代码, 加新需求逻辑

特征: 代码中, 具体需求逻辑代码占比很大, 只包含少量必要的抽象/分层等

至上而下: 可能会过度设计

没有必要为不变的点抽出太多的概念/太多层, 没有必要为了未来几年都不会扩展的点增加某个设计模式;

注意: 是可能

容易过度设计的做法:

想要一步到位, 或者完美主义, 或者看得很远, 所以基于需求直接拆分出一堆层次和概念
基于概念, 通过组合/继承或者设计模式, 完成一堆父模块/基类/调用框架(此时没有具体代码)
实现一两个子类, 完成需求, 测试功能, 加单测, 交付

特征: 代码中, 抽象的代码占比很大, 大量的概念/抽象等, 只在几个具体实现类中包含实现代码

问题: 概念抽象真的有那么重要吗?

看场景

大型项目, 很重要
需求多变/变更频繁, 很重要
生命周期很长的项目, 很重要
其他, 不是那么重要

如果是一次性的任务, 那么quick and dirty搞完即可, 很少或根本没有抽象

如果是一个小型项目, 或者项目本身需求明确变更不频繁, 或者需求实现之后不怎么变半年一年一种实现. 那么, 概念抽象以及可扩展性并没有想象中那么重要, 而应该把可读性/可维护性放在前面, 保持适当的可扩展性, 某些极端场景, 甚至不考虑可扩展性

如果是中大型项目, 生命周期长, 需求复杂且多, 那么此时概念抽象就很重要了

怎么抉择?

看到这里, 并不是说, 一定要至下而上, 或者一定不能至上而下

而是需要根据很多因素决策: 看项目, 看需求, 看场景…..

项目大小
项目的生命周期
具体需求的复杂度
需求变更是否频繁? 新需求加入是否频繁? 是否有可见的需求?
……

例子: 一个需求及实现

需求: 从两个不同的服务, 同步数据到同一个表; 这两个服务的协议不一样, 获取的数据字段映射到数据库表字段也不一样, 并且不同字段有不同的处理规则

几种实现:

写两个脚本或者celery任务, 执行同步
- 加字段/字段变更需要两边都改
写一个dataclass+两个client, client负责转换为统一格式
- 加字段/变更字段, 改两个client即可
写一个dataclass+两个client+两个mapper, mapper 负责数据转换
- 加字段/变更字段, 改两个mapper即可, 甚至mapper变更纯配置
抽象概念: syncer/fetcher/client/mapper/hook/helper/loader

一次性的任务, 选 1(quick and dirty), 如果时间空余, 做到 2
偶尔有字段变更, 选 2
频繁字段变更, 选 3, 最好变成配置
大型项目, N 个服务, N 种协议, N 种映射转换, 且不断有新逻辑, 初期还是最多做到 3, 逐步抽象, 最终可能演变成 4; 但是, 并不是一开始就那么多概念(至上而下), 而是不断迭代中演化出来的

所以, 以务实的方式来设计方案, 逐步随着项目迭代演化出最终的形态.

务实

从零开始学架构, 提到了三个原则: 合适/简单/演化

以务实的角度去思考

合适, 但也不能太简陋/落后
简单, 但是要能满足现在及未来可见范围内的需求
演化, 但是底子要好, 避免无法演化只能重写

Better Code: 异常时, 该提示用户哪些信息?

Tue, 24 May 2022 23:00:00 +0800

接前一篇 Better Code: 更好的异常日志打印

做 toB 一个非常高的成本是, 用户的环境/网络/数据等, 可能跟你预期的差异很大, 再加上沟通相对困难(涉及三方/四方, 无法便捷地登机器排查问题, 无法便捷地获取日志, 接口人业务或技术水平参差不齐).

而这时候, 你会面临一个问题, 如何在信息不足/沟通不畅的场景下, 尽量提升效率, 降低成本(大部分情况下, 逢单必结, 你必须解决问题, 没有选择的余地)

TLDR:

如果有工具, 尽量用工具解决问题, sentry/otel等等
日志, 该打的地方, 一定要打, 并且尽量包含上下文; 并且能通过日志级别配置动态调整打印明细.
页面报错提示, 尽量详尽, 用户不一定能看懂, 但是配合文档或者截图给你, 你能秒懂(如果不方便展示给用户, 可以通过request_id或者隐藏在页面等方式)
尽量减少排查链路(例如, 尽量汇总日志, 尽量在一个地方能看到, 或者通过一个request_id能汇总相关日志等等)

场景 1: 代码逻辑报错

有个代码初始化数据到数据库的逻辑报错了, 不管是什么原因引起的, 你需要解决!

实现v1

Setting.objects.create(
    key=k, value=v, defaults=x
)

此时, 新装环境没问题, 升级环境会报错,

通过异常信息知道创建由于唯一性限制报错了, 是由于用户手动插入了数据导致报错

此时, 用户问你, 数据有几百条, 哪条数据引起的? 我该怎么修复(成本: 小时级)

实现v2

打印上下文!

try:
    Setting.objects.create(
        key=k, value=v, default=x
    )
except Exception as e:
    logger.exception("create setting fail, k=%s, v=%s, default=%s", k, v, x)
    raise e

此时, 通过异常信息上下文可以看到哪条数据有问题!(成本: 分钟级)

实现v3

代码考虑兼容性, 已发的版本/存量的系统, 最好能顺滑升级!

例如, 这里的create, 可以考虑用get_or_create替代(当然, 前提是符合需求)

场景 2: 用户输入报错了

有个功能是支持用户配置ldap相关地址, 拉取用户数据, 用户点击: 测试连接.

实现v1

try: 
   test_connection(**params)
except Exception as e:
   raise Exception("测试连接失败, 请检查配置")

此时, 用户坚信自己的配置是对的, 你如何帮他定位呢? (成本: 几个小时甚至一两天)

实现v2

try: 
   test_connection(**params)
except Exception as e:
   # 注意, 这里一定要logger.exception, 用error意义不大!
   logger.exception("测试连接失败, 请检查配置")
   raise Exception("测试连接失败, 请检查配置")

这时候的调试方式, 用户找你, 你告诉用户去哪里看日志!(成本: 分钟到几个小时)

实现v3

try: 
   test_connection(**params)
except Exception as e:
   # 注意, 这里一定要logger.exception, 用error意义不大!
   logger.exception("测试连接失败, 请检查配置")
   error_detail = f" ({type(e).__module__}.{type(e).__name__}: {str(e)})"
   raise Exception("测试连接失败, 请检查配置" + error_detail)

这时候, 在页面上, 用户就能看到 报错的类型及错误信息

报错类型: 能定位到是第三方库还是自己程序哪个模块报的, 如果出现标准库KeyError/ValueError等, 大概率是自己哪里代码逻辑处理不正确.
报错信息: 例如 invalid server address, socket connection error while opening: [Errno 111] Connection refused之类的;

此时, 用户绝大多数可以在前端提示中看到, 无需支持!

实现v4

有必要的话

如果你能准确根据 Exception 或message区分详情, 可以进一步处理, 返回更精确的提示. 例如invalid server address, 可以翻译成不合法的地址, 请检查xxxx字段, 必须是一个合法的域名, 建议同时带上一个error code方便快速确定问题/文档中检索关键字
如果有必要, 可以在错误中带上上下文, 但是需要注意脱敏

场景 3: 用户输入, 报错了, 但是不能直接提示给对方

用户登录, 输入的用户名/密码有问题或者账号本身有问题时;由于安全原因, 不能明确告诉对方具体是哪里有问题. 在用户看来, 无论怎么尝试, 报错总是一样的.

那么, 如果用户坚持自己输入是对的, 账号是正常的, 如何帮助其排查问题?

实现v1

if user not exists:
    raise PasswordWrongException()
if user.status in [DISABLED, LOCKED]:
    raise PasswordWrongException()
if user login hit secure policies:
    raise PasswordWrongException()

这种实现, 你只能看代码, 逐个同用户沟通检查(成本: 小时/天)

实现v2

if user not exists:
    logger.error("login fail, user<%s> not exists", user)
    raise PasswordWrongException()
if user.status in [DISABLED, LOCKED]:
    logger.error("login fail, user<%s> status is %s", user, user.status)
    raise PasswordWrongException()
if user login hit secure policies:
    # 这里有必要的话, 甚至需要明确到具体哪个policy
    logger.error("login fail, user<%s> hit xxx secure policies", user)
    raise PasswordWrongException()

这种实现, 让用户捞下日志就能明确具体问题(成本: 分钟)

场景 4:强依赖于一个第三方库, 如何 debug?

如果应用本身依赖于一个第三方库, 且第三方库默认是有logger的.

此时, 调用第三方库报错, 可能返回的异常信息不足以帮助用户定位问题;

例如依赖ldap3同步用户数据

此时数据链路: 应用 -> ldap3 -> 网络 -> ldap服务器

由于网络/ldap服务器类型及配置差异较大, 导致非常容易出现异常
ldap服务器往往由另一个团队维护, 具体的服务端配置对于配置用户并不透明
ldap3库本身不同版本也存在bug

此时, 用户配置了ldap相关参数, 但是点击报错, 并且, 用户坚信自己的配置是对的; 如何帮助用户调试?

我们是否可以支持, 开启ldap3的debug模式?

首先, 需要确认库是否支持logger配置, 常用的第三方库一般都支持, 例如requests, ldap3是支持的, ldap3 logging
其次, 通过配置/环境变量, 支持用户可以开启

上面的例子, 我们的应用实现上支持

from ldap3.utils import log as ldap3log

if settings.ENABLE_LDAP3_DEBUG:
    ldap3log.set_library_log_detail_level(ldap3log.EXTENDED)
    ldap3log.set_library_log_activation_level(logging.DEBUG)

那么, 在用户遇到问题无法解决的时候, 可以通过配置开启, 进入debug模式; 在日志中可以看到详细的 ldap3 -> 网络 -> ldap服务器 的数据细节.

其他

tip: 如果有可能, 接入sentry/otel

如果基建有otel, 建议接入; 如果基建有日志采集汇聚, 建议接入!

能极大提升问题排查效率

所以, 尽量整合相应的SDK, 并且提供可插拔的配置方式, 让有条件的使用方开启.

tip: 日志链路需要串起来

如果:

调用链路长, 用户 -> A -> B -> C -> D
服务请求量非常大

此时, 某个用户一个请求报错(前端或 API), 如何定位问题?

首先明确一个原则, A -> B 如果出现调用失败, 一定要记录日志, 包括url/request detail(header/body/credentials)/response detail(status/header/body)等等(如果什么都不记, 让用户或运维去 B 看日志, 这是不合理的!)

此时, 如果请求量很大, 调用链路长, 其实很难逐层定位每一层的处理/报错, 光去捞日志就已经非常费劲了(大部分时候, url或请求中并没有明显的特征)

如果整个调用链路接入了 OTEL, 那么问题相对简单; 但是如果没有接入, 如何处理?

我们可以通过 HTTP HEADER中带一个request_id来解决!

约定一个统一的header, 例如x-request-id
在 网关/ESB/nginx等地方, 需要显示配置透传
程序处理逻辑, 需要在接收请求时, 获取request_id, 如果有向下一级调用的请求, 需要传递该request_id
日志,异常上报等场景, 使用统一的request_id

tip: 当开启debug的时候, 确保能看到足够多的信息

logging.DEBUG主要目的是, 开启后, 可以准确定位问题!

所以, 在一些关键的逻辑中

加上debug日志, 覆盖所有关键的处理逻辑和返回
debug需要带上足够多的上下文

例如, 当关键一个函数, 中间有超过 5 个return, 开启debug之后, 需要能明确知道, 在哪里return的, 为什么会被return

tip: 输入尽量做好`防御`

不管是用户的输入, 还是从某些 API 拉取到的返回值, 尽量在获取到数据的入口处做好防御和检查, 例如, 类型/格式/非空等等

而不是, 层层传递后, 在某个地方异常报错, 这个时候排查的代价会大很多.

tip: 当问题排查陷入僵局

1. 如果是第三方库, 可以考虑升级试试?

场景: 依赖于ldap3, 能确认用户的配置是正确的, 网络是联通的, 此时无论如何都连不上, 开debug模式也没看出问题

解决: 确定库版本, 2.6.1, 在官方github issue的bug report中查找相关报错信息, 然后升级了一个版本就成功了

常见的, 例如requests/加密相关库/ssl相关库等等

2. 重启, 本机重新部署或在另一台机器部署, 也是可以尝试的方式

场景: 在一台机器部署, 连接另外一个服务始终连不上, 运维确定网络是没问题的; 后来在另一台机器部署后正常.

场景: 有一台机器reuqests库一直会报错, 换一台机器部署正常.(openssl相关)

3. 重新检查配置/负载/io/网络/依赖库/依赖包版本等, 重新排查调用链路, 追踪请求流转过程, 重新获取日志

场景: 对方上了网络策略, 存量机器没有处理导致原先正常的环境突然有问题了

很多时候, 你被拉去排查问题, 并不是因为你负责的服务有问题, 而是更底层的环境问题, 只是因为环境出问题你的服务刚好打了异常, 对方看到了而已.

Better Code: 更好的异常日志打印

Sun, 16 Jan 2022 00:04:00 +0800

维护一个 N 年前的Python项目, 协助排查问题时发现, 原先的日志打印真真一言难尽

导致了一个问题, 同负责的运维 A 沟通, A 与其对接的甲方沟通……日志的缺失导致本来简单的问题变得复杂

如果日志打得更完备一点, 排查问题的难度不是一个的级别的

bad case

try:
    # got a data here
    # a lot of codes here
    # x = data["key"]
    # call_another_func(id, type)
    # call_another_func2(id, type, name)
except Exception:
    logger.error("error while do something")

这时候, 异常触发的时候, 日志只有

error while do something

相对于没打日志,只好了一点点, 知道有异常出现了, 问题是, 具体错误是什么?

第一次改进

try:
    # got a data here
    # a lot of codes here
    # x = data["key"]
    # call_another_func(id, type)
    # call_another_func2(id, type, name)
except Exception as error:
    logger.error("error while do something, error=%s", error)

此时报错时, 会打印

error while do something, error=App matching query does not exist

但是, 这里相对原始版本只好了一点点, 多了error message, 但是这行message并没有包含多少有利于问题排查的信息, 甚至连类型都没有, 看到了一脸懵

再次改进1

try:
    # got a data here
    # a lot of codes here
    # x = data["key"]
    # call_another_func(id, type)
    # call_another_func2(id, type, name)
except Exception as error:
    logger.exception("error while do something")

将logger.error改成logger.exception, 此时错误日志

error while do something
Traceback (most recent call last) :
  File "a.py", line 674 in call_another_func
    app = get_app(id)
  File "b.py", line 18 in get_app
    app = App.objects.get(id)
DoesNotExist: App matching query does not exist.

这时候, 有详细的错误堆栈, 可以用于追溯错误原因.

但是, 某些场景下, 看到错误堆栈并不一定能确定问题, 根据堆栈信息回去看代码, 这代码不可能有问题……

此时, 可能是数据问题(各种原因的脏数据), 或者数据被人工改动(例如直接改表数据).

如果只有以上信息, 排查问题依旧要花很多时间.

再次改进2

增加数据/业务信息等上下文, 注意不好打敏感信息

try:
    # got a data here
    # a lot of codes here
    # x = data["key"]
    # call_another_func(id, type)
    # call_another_func2(id, type, name)
except Exception as error:
    logger.exception("error while do something [id=%s, type=%s, name=%s]", id, type, name)

错误信息

error while do something[id=1, type=test, name=abc]
Traceback (most recent call last) :
  File "a.py", line 674 in call_another_func
    app = get_app(id)
  File "b.py", line 18 in get_app
    app = App.objects.get(id)
DoesNotExist: App matching query does not exist.

更好的做法

使用自定义异常, 带code/message

class BaseException(Exception):
    def __init__(self, code, message):
        self.code = code
        self.message = message
        super().__init__(f"{self.code} {self.message}")
    def __str__(self):
        return f"{self.code}:({self.message})>"

class XXException(BaseException):
    .....

使用raise Error/CustomException替代try-except
在统一的地方处理错误, 例如middleware或统一调用入口, try-except依次捕获所有已知的Error和CustomException, 最后捕获通用的Exception(未知异常)

好处:

底层代码逻辑更简单, 少一层嵌套, 可读性更好
统一的错误声明及处理, 对于开发者及使用者都更为友好, 例如可以将错误码作为协议的一部分, 使用者根据错误码可以快速定位问题

Golang的error wrap

Go 的error wrap更为优雅, Working with Errors in Go 1.13

_, err := dosomething(type)
return fmt.Errorf("dosomething fail, type=`%s`, err=%w", type, err)

也可以看下之前 go 项目的实践: Go: 一种error wrap调用链处理方式

其他

不要用print替代logging
打很多日志等于没打
谨慎确定当前要打日志的level
尽量只在必要的地方打日志, 信息是有用的, 也是完备的, 有利于定位问题的
一定不要吞掉异常
如果使用try-except, Exception尽量精确, 打印日志尽量完备
如果使用try-except, 捕获的代码块尽量小, 不会出现异常的语句不要放进去. 反例: 整个函数的所有代码都在一个try-except中
logger 本身尽量按功能/模块/业务等切分多个, 反例: 全打标准输出

Go: some libs

Wed, 04 Aug 2021 08:00:00 +0800

I have finished 3 web projects in the past 16 months, about 100000 lines.

The libs below are my recommended.

Last Updated: 2021-08-04

framework

recommend gin
chi

layout

golang-standards/project-layout

database

sqlx
gorm

cache

memory: go-cache
redis: go-redis/redis
- cache go-redis/cache
- distribute lock redislock
- ratelimit: go-redis/redis_rate

http client

gorequest

test

logger

doc

swaggo/swag
gin swaggo/gin-swaggo

error

uber-go/multierr

config & cli

viper
cobra

json

json-iterator/go

observability

validate

go-playground/validator

worker pool

panjf2000/ants

others

Go: go-redis/cache升级的坑

Fri, 05 Mar 2021 08:00:00 +0800

这是在做 Golang 项目中的一些实践

在做一个项目, 使用了 go-redis/redis 及 go-redis/cache

某个节点, 做了所有依赖包的升级.

在做缓存依赖包的升级时, 必须十分注意, 新版本的第三方包做了哪些变更, 阅读CHANGE LOG和相关的源码;

主要风险:

breaking changes
对象/方法/参数等协议变更
存储格式(是否向前兼容)

即, 一旦做了升级, 原先正常的代码, 可能会有问题

所以需要确认:

新老版本存储格式是否一致?
代码中涉及读和写的地方是否使用同样的操作?

1. v7升级v8

issue: Can’t upgrade from v7 to v8 directly?

package main

import (
	"context"
	"fmt"

	cv7 "github.com/go-redis/cache/v7"
	cv8 "github.com/go-redis/cache/v8"
	rdsv7 "github.com/go-redis/redis/v7"
	rdsv8 "github.com/go-redis/redis/v8"
	msgpackv4 "github.com/vmihailenco/msgpack/v4"
)

func main() {
	// TODO: 测试放入redis用另一个取
	d := map[string]interface{}{
		"hello": 1,
		"world": "ok",
	}

	// 使用两个版本的cli进行测试, v7/v8
	// 1. 使用v7, marshal 放入db
	// 2. use v8, 获取

	v7 := &cv7.Codec{
		Redis:     rdsv7.NewClient(&rdsv7.Options{}),
		Marshal:   msgpackv4.Marshal,
		Unmarshal: msgpackv4.Unmarshal,
	}

	err := v7.Set(&cv7.Item{
		Key:    "aaa",
		Object: d,
	})
	fmt.Println("set err:", err)

	v8 := cv8.New(&cv8.Options{
		Redis: rdsv8.NewClient(&rdsv8.Options{}),
	})

	var result map[string]interface{}
	err = v8.Get(context.TODO(), "aaa", &result)
	fmt.Println("get err:", err)
	fmt.Println(result)
}

执行结果:

set err: 
get err: unknown compression method: 6b
map[]

原因, go-redis/cache v8引入的压缩 v8/cache.go, 没有做向前兼容的逻辑

解决方案: 在基础类中, 更换掉key的namespace, 增加版本号; 例如 project:hello 变成 project:v8:hello

2. 升级v8后的msgpack 与 pipeline的处理

由于 go-redis/cache 主要用于单个对象的 set/get

某些业务场景下, 我们使用pipeline进行批量操作

此时, pipeline拿回回来的是 raw string, 原先v7由于set算法用的msgpack.Marshal, 自定义pipeline处理结果直接用msgpack.Unmarshal没有问题.

但是, 升级到v8后, 由于compession逻辑的存在, 此时使用原生的msgpack.Unmarshal将会报错(无法识别被压缩的字符串)

解决: 需要切换为 go-redis/cache 对象的Unmarshal

Go: logrus性能提升

Tue, 09 Feb 2021 20:00:00 +0800

在Go项目中, logrus是一个相对完备的第三方日志库

用起来非常顺手, 特别是WithField/WithFields/WithError

我们开发一些对性能要求非常高的应用, 例如API网关/权限服务等, 需要记录流水日志, 此时日志库的性能直接会影响整体接口性能.

所以针对性地做了一些优化

log.WithFields(fields).Info("-")

json formatter

logrus的默认json formatter json_formatter 使用的是标准库

众所周知, 性能比第三方库差很多

我们可以自定义一个json formatter, 使用例如 json-iterator/go来提升序列化性能

	// ! change here: use jsnoiter to do marshal. but ignore the entry.Buffer

	// var b *bytes.Buffer
	// if entry.Buffer != nil {
	// 	b = entry.Buffer
	// } else {
	// 	b = &bytes.Buffer{}
	// }

	// encoder := json.NewEncoder(b)
	// if f.PrettyPrint {
	// 	encoder.SetIndent("", "  ")
	// }
	// if err := encoder.Encode(data); err != nil {
	// 	return nil, fmt.Errorf("failed to marshal fields to JSON, %v", err)
	// }
	// return b.Bytes(), nil

	buf, err := jsoniter.Marshal(data)
	if err != nil {
		return nil, fmt.Errorf("failed to marshal fields to JSON, %v", err)
	}
	buf = append(buf, '\n')
	return buf, nil

null formatter 和 hooks

如果不指定, 默认的formatter是TextFormatter

func New() *Logger {
	return &Logger{
		Out:          os.Stderr,
		Formatter:    new(TextFormatter),
		Hooks:        make(LevelHooks),
		Level:        InfoLevel,
		ExitFunc:     os.Exit,
		ReportCaller: false,
	}
}

如果我们使用了 hooks (hooks.go)将日志转到文件/redis或其他渠道; 此时, 默认的Output和Formatter还是会被调用到;

其实我们配置了hooks, 那么原entry理论上是不需要的

func (entry Entry) log(level Level, msg string) {
    entry.fireHooks()
    ....
    entry.write()
}

func (entry *Entry) write() {
	entry.Logger.mu.Lock()
	defer entry.Logger.mu.Unlock()
	serialized, err := entry.Logger.Formatter.Format(entry)
	if err != nil {
		fmt.Fprintf(os.Stderr, "Failed to obtain reader, %v\n", err)
		return
	}
	if _, err = entry.Logger.Out.Write(serialized); err != nil {
		fmt.Fprintf(os.Stderr, "Failed to write to log, %v\n", err)
	}
}

所以, 此时可以配置一个 NullFormatter, 将默认的链路关闭(do nothing), 日志只会走hooks

package formatter

import (
	"github.com/sirupsen/logrus"
)

// NullFormatter formats logs into text
type NullFormatter struct {
}

// Format renders a single log entry
func (f *NullFormatter) Format(entry *logrus.Entry) ([]byte, error) {
	return []byte(""), nil
}

重新设置log的配置

logger.SetOutput(ioutil.Discard)
logger.SetFormatter(&formatter.NullFormatter{})

logger.AddHook(NewRedisHook())

log entry pool

package logging

import (
	"sync"

	log "github.com/sirupsen/logrus"
)

type logEntryPool struct {
	pool sync.Pool
}

func newLogEntryPool() *logEntryPool {
	return &logEntryPool{
		pool: sync.Pool{
			New: func() interface{} {
				return &log.Entry{
					// Logger: logger,
					// Default is three fields, plus one optional.  Give a little extra room.
					Data: make(log.Fields, 6),
				}
			},
		},
	}
}

func (p *logEntryPool) Get(logger *log.Logger) *log.Entry {
	entry := p.pool.Get().(*log.Entry)
	entry.Logger = logger
	return entry
}

func (p *logEntryPool) Put(e *log.Entry) {
	// TODO: clean, should make?
	// reference: https://github.com/sirupsen/logrus/pull/796/files
	// e.Data = make(log.Fields, 6)
	e.Data = map[string]interface{}{}

	p.pool.Put(e)
}

使用

entry := logging.LogEntryPool.Get(logger)
defer logging.LogEntryPool.Put(entry)

异步日志

使用一个专门处理日志的goroutine

func (f *FileLogHook) makeAsync() {
	f.fireChannel = make(chan *logrus.Entry, f.asyncBufferSize)
	fmt.Printf("file hook will use a async buffer with size %d\n", f.asyncBufferSize)
	go func() {
		for entry := range f.fireChannel {
			if err := f.send(entry); err != nil {
				fmt.Println("Error during sending message to file:", err)
			}
		}
	}()
}

// Fire is called when a log event is fired.
func (f *FileLogHook) Fire(entry *logrus.Entry) error {
	if f.fireChannel != nil { // Async mode.
		select {
		case f.fireChannel <- entry: // try and put into chan, if fail will to default
		default:
			if f.asyncBlock {
				fmt.Println("the log buffered chan is full! will block")
				f.fireChannel <- entry // Blocks the goroutine because buffer is full.
				return nil
			}
			fmt.Println("the log buffered chan is full! will drop")
			// Drop message by default.
		}
		return nil
	}

  // Sync mode.
	return f.send(entry)
}

func (f *FileLogHook) send(entry *logrus.Entry) error {
	return f.loghook.Fire(entry)
}

Async write to redis 
with buffersize=10000
(block)

7700 -> 18000

Async write to redis
With buffersize=10000
(none block, drop if full)

60000+

Go: gin validation

Thu, 04 Feb 2021 08:00:00 +0800

这是在做 Golang 项目中的一些实践

传统的校验方式

需要在获取数据后, 写很多if判断语句, 无法复用且非常罗嗦

if a != "" {

}
if len(a) < 10 {

}

gin 的参数校验

gin 使用了 go-playground/validator库, 使用tag声明的方式, 支持http请求request中的各类校验

几种常用参数校验

1. get 参数

gin: Only Bind Query String

curl -X GET “localhost:8085/testing?name=eason&address=xyz”

type Person struct {
	Name    string `form:"name"`
	Address string `form:"address"`
}

var person Person
if c.ShouldBindQuery(&person) == nil {
		log.Println("====== Only Bind By Query String ======")
		log.Println(person.Name)
		log.Println(person.Address)
}

2. 路径参数

gin: Bind Uri

curl -v localhost:8088/thinkerou/987fbc97-4bed-5078-9f07-9141ba07c9f3

package main

import "github.com/gin-gonic/gin"

type Person struct {
	ID string `uri:"id" binding:"required,uuid"`
	Name string `uri:"name" binding:"required"`
}

func main() {
	route := gin.Default()
	route.GET("/:name/:id", func(c *gin.Context) {
		var person Person
		if err := c.ShouldBindUri(&person); err != nil {
			c.JSON(400, gin.H{"msg": err})
			return
		}
		c.JSON(200, gin.H{"name": person.Name, "uuid": person.ID})
	})
	route.Run(":8088")
}

3. json body

gin: Model binding and validation

type Login struct {
	User     string `json:"user" binding:"required"`
	Password string `json:"password" binding:"required"`
}

var json Login
if err := c.ShouldBindJSON(&json); err != nil {
    c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
    return
}

4. header

gin: Bind Header

curl -H “rate:300” -H “domain:music” 127.0.0.1:8080/

package main

import (
	"fmt"
	"github.com/gin-gonic/gin"
)

type testHeader struct {
	Rate   int    `header:"Rate"`
	Domain string `header:"Domain"`
}

func main() {
	r := gin.Default()
	r.GET("/", func(c *gin.Context) {
		h := testHeader{}

		if err := c.ShouldBindHeader(&h); err != nil {
			c.JSON(200, err)
		}

		fmt.Printf("%#v\n", h)
		c.JSON(200, gin.H{"Rate": h.Rate, "Domain": h.Domain})
	})

	r.Run()
}

json body是一个对象数组

ShouldBindJSON并不会校验对象数组中的每个对象是否符合要求, 需要自行调用方法处理

可以抽象出一个通用的函数

var ErrNotArray = errors.New("validate array fail, only support array")

func ToSlice(array interface{}) ([]interface{}, error) {
	v := reflect.ValueOf(array)
	if v.Kind() != reflect.Slice {
		return nil, ErrNotArray
	}
	l := v.Len()
	ret := make([]interface{}, l)
	for i := 0; i < l; i++ {
		ret[i] = v.Index(i).Interface()
	}
	return ret, nil
}


func ValidateArray(data interface{}) (bool, string) {
	array, err := ToSlice(data)
	if err != nil {
		return false, err.Error()
	}

	if len(array) == 0 {
		return false, "the array should contain at least 1 item"
	}
	for index, item := range array {
		if err := binding.Validator.ValidateStruct(item); err != nil {
			message := fmt.Sprintf("data in array[%d], %s", index, ValidationErrorMessage(err))
			return false, message
		}
	}
	return true, "valid"
}

使用时

var body []action
if err := c.ShouldBindJSON(&body); err != nil {
	// bad request
	return
}

if valid, message := common.ValidateArray(body); !valid {
    // bad request: message
    return
}

更友好的错误提示

当validation报错的时候, 我们期望得到一个更友好的提示信息, 便于使用者确认问题

reference:

以下是一种实现, 处理的常用的 validation 规则的错误展示

package util

import (
	"fmt"
	"io"

	"github.com/go-playground/validator/v10"
	log "github.com/sirupsen/logrus"
)

// 这里是通用的 FieldError 处理, 如果需要针对某些字段或struct做定制, 需要自行定义一个
type ValidationFieldError struct {
	Err validator.FieldError
}

func (v ValidationFieldError) String() string {
	e := v.Err

	switch e.Tag() {
	case "required":
		return fmt.Sprintf("%s is required", e.Field())
	case "max":
		return fmt.Sprintf("%s cannot be longer than %s", e.Field(), e.Param())
	case "min":
		return fmt.Sprintf("%s must be longer than %s", e.Field(), e.Param())
	case "email":
		return "Invalid email format"
	case "len":
		return fmt.Sprintf("%s must be %s characters long", e.Field(), e.Param())
	case "gt":
		return fmt.Sprintf("%s must greater than %s", e.Field(), e.Param())
	case "gte":
		return fmt.Sprintf("%s must greater or equals to %s", e.Field(), e.Param())
	case "lt":
		return fmt.Sprintf("%s must less than %s", e.Field(), e.Param())
	case "lte":
		return fmt.Sprintf("%s must less or equals to %s", e.Field(), e.Param())
	case "oneof":
		return fmt.Sprintf("%s must be one of '%s'", e.Field(), e.Param())
	}

	return fmt.Sprintf("%s is not valid, condition: %s", e.Field(), e.ActualTag())
}

func ValidationErrorMessage(err error) string {
	if err == io.EOF {
		return "EOF, json decode fail"
	}

	validationErrs, ok := err.(validator.ValidationErrors)
	if !ok {
		message := fmt.Sprintf("json decode or validate fail, err=%s", err)
		log.Info(message)
		return message
	}

	// currently, only return the first error
	for _, fieldErr := range validationErrs {
		return ValidationFieldError{fieldErr}.String()
	}

	return "validationErrs with no error message"
}

判断: 空值还是没有传递

有些场景, 如果一个json对象中, 某个字段可以为空, 但是非空的时候, 要执行某些特殊的逻辑

此时, 使用默认的validation是无法判断, 请求中没有这个字段, 还是传了空值;

// validate
var body action
err := c.ShouldBindBodyWith(&body, binding.JSON)
if err != nil {
	// bad request, ValidationErrorMessage(err)
	return
}
var data map[string]interface{}
err = c.ShouldBindBodyWith(&data, binding.JSON)
if err != nil {
	// bad request, ValidationErrorMessage(err)
	return
}

if _, ok := data["name"]; !ok {
	// do something
}

远程办公的一点总结

Mon, 01 Feb 2021 08:00:00 +0800

这是去年疫情期间, 公司实施了接近两个月的远程, 当时写下的一些小结

不好的地方

人都有惰性, 另外个人远程办公环境没搞好, 容易被打扰/分心;
协作人数<3人, 远程效果正比于个人的自觉性/自律
如果没有定期晨会/例会过进度, 远程效果会大大降低
如果没有目标感, 会迷失, 导致效率下降, 产出降低

好的实践

远程在做规划时, 需要让整体项目组的目标一致, 然后细化到每个人, 每个人每天都有目标感; (迭代用OKR)
需要有定期的review/检查机制, 保持节奏, 即使纠正偏差
具体issue有截止时间
协作人数>=3人, 每天晨会, 互相进行code review, 每个迭代初有详细规划, 每个迭代结束有总结review

主观感受

会议会少很多, 相对原先办公室的场景, 少了很多临时拉的会/被动旁听的会; 整体会议由定期的例会/晨会, 临时的讨论会组成;
- 整体会议时间降低30%-50%; 效率提升的主要原因是, 异步处理+同步会议的收益,
- 会议之前, 相关议题都同步到, 各自在参会前都做了思考/评论;
编码效率高; 如果项目在快速迭代/产出阶段, 远程可能非常合适, 此时编码效率提升30%, 主要是少打断, 时间块相对完整
时间多了很多, 时间块多带来的效率提升, 少了每日来回通勤2个小时
要注意过劳, 有时候长时间沉浸在编码中, 导致最终筋疲力尽

Go: 开发过程中的一些bug

Thu, 28 Jan 2021 08:00:00 +0800

1. make slice

很容易漏掉中间参数, 引入 bug并且很难排查

package main

import "fmt"

func doCopy(a []string) []string {
	b := make([]string, len(a))
	for _, i := range a {
		b = append(b, i)
	}
	return b
}

func main() {
	a := []string{"hello"}
	b := doCopy(a)
	fmt.Println(b, len(b))
}

得到结果

[ hello] 2

实际上

a := make([]int, 5)  // len(a)=5
a := make([]int, 0, 5)  // len(a)=0 cap(b)=5

2. shadow

本来应该使用=赋值, 错误地使用了:= (这个govet可以扫出来)

var form url.Values
if checkForm {
  form := make(url.Values)
  util.CopyValues(form, r.PostForm)
}

3. err == or !=

容易敲错, 且不好排查

if err == nil {

}

if err != nil {

}

4. 漏掉了return

在本该return的地方漏掉了, 导致逻辑继续往后走, 这种在gin的handler和middleware特别容易漏

if err != nil {
  render.JSON(w, err.Status, err)
  // 这里漏掉了 return
}

next.ServeHTTP(w, r)

5. scopelint

scopelint

package main

import "fmt"

func main() {
	values := []string{"a", "b", "c"}
	var copies []*string
	for _, val := range values {
		copies = append(copies, &val)
	}
	fmt.Println(copies)
}

此时得到

[0xc000010200 0xc000010200 0xc000010200]

预期的应该是

package main

import "fmt"

func main() {
	values := []string{"a", "b", "c"}
	var copies []*string
	for _, val := range values {
    // add := here
		val := val
		copies = append(copies, &val)
	}
	fmt.Println(copies)

}

6. error.Is放错了位置

if err != nil {
  return err
}

...


if error.Is(err, DEMOError) {
    // will never execute
}

7. close the connection

// the connection is not close
_, err := sqlx.Connect("mysql", db.dataSource)

// should be
conn, err := sqlx.Connect("mysql", db.dataSource)
if err != nil {
	return
}

conn.Close()

项目管理实践: 风险驱动开发

Wed, 27 Jan 2021 20:00:00 +0800

风险驱动开发

快速迭代过程中的问题

在一个项目从0到1快速迭代开发的过程中, 除了常规的需求开发, 还会面临很多问题, 来自于deadline, 线上bug, 用户咨询的问题等等

多人开发过程中, 除了上下游项目依赖, 还存在协作

我们无法完全按照既定的规划注意处理问题, 但是也不能切换到紧急的事情上.

我们应当将目标focus在 重要紧急和重要不紧急的事情上, 而实际迭代过程往往会受到紧急的事情打断, 导致真正重要的事情延期.

那么, 我们应该如何应对这种情况?

风险驱动模型是什么?

«恰如其分的软件架构»的第一部分就是讲述风险驱动模型的.

运用最小的架构技术集合去降低最紧迫的风险, 以求事半功倍

步骤

识别风险, 并排定优先级(从需求出发)
选择并运用一组技术
评估风险降低的程度

实践

首先, 我们采用了OKR的方式管理每个迭代的目标和关键结果
在每个迭代开始之初, 先将近期所有事项加入一个池子, 这其中会包含最近加入的issue, 也会包含既定规划好的issue, 以及上个迭代delay的issue.
然后逐一review, 评论, 这个过程需要issue相关的所有人员进行review, 补充信息. 补充信息包括, 涉及的人员/上下游状态, 交付时间, 风险点等等.
然后, 使用风险驱动开发的模式, 对池子里面的所有issue进行风险评估, 从而确定最重要的事情(注意不一定是最紧急的事情), 最终排定优先级及时间
对于紧急而不重要的事情, 采用类似GTD中的二分钟法则(如果一件事情两分钟内能搞定那么马上处理), 如果工作量不大, 那么适当优先处理, 已减少干扰项, 有更大块的时间处理重要的事情

问题

为什么每个迭代都需要对issue`补充信息`?

这是因为, 一切都是变化的, 相关的需求/人员/上下游等等都可能存在变化, 这样就导致一个issue的重要程度变化, 同时也关系到这个issue的风险.

这样做的好处?

在项目的不同阶段, 或者在同一个阶段的不同迭代, 整个项目的风险是动态变化的, 你必须评估项目当前时刻的每一个风险, 最大程度地降低失败的风险

Go: 一种error wrap调用链处理方式

Tue, 26 Jan 2021 14:38:00 +0800

这是在做 Golang 项目中的一些实践

背景

在做一套内部公共服务, 提供后台API调用的时候, 某些情况下, 会返回500错误, 此时有两种做法

在后台记录详细的500日志, 返回给调用方一个request_id, 调用方拿request_id查询日志定位问题
直接在response body中返回错误信息

选择了问题排查路径短一些的 2, 错误信息中, 需要包含调用链路以及根因错误的详细信息, 提升问题排查的效率

这样, 开发者在看到报错response body的同时, 可以直接知道调用链, 不需要使用请求重新复现问题, 节约了大量的复现/沟通的时间

最终效果

system error[request_id=0838c4090cfa4f4f9dceea5fd8c7b029]: [Handler:validateSystemSuperUser] impls.ListSubjectRoleSystemID subjectType=`user`, subjectID=`test1` fail%!(EXTRA string=test1) => [Cache:GetSubjectRole] SubjectRoleCache.Get subjectType=`user`, subjectID=`test1` fail => [Cache:GetSubjectPK] SubjectPKCache.Get _type=`user`, id=`test1` fail => [SubjectSVC:GetPK] GetPK _type=`user`, id=`test1` fail => [Raw:Error] sql: no rows in result set

处理机制

使用error wrap, 一层层抛出

1. 定义pkg/errorx

注意, package name使用errorx, 可以规避同标准库命名的冲突; 同时import的时候不需要alias

type Error struct {
	message string
	err     error
}

func (e Error) Error() string {
	return e.message
}

func (e Error) Is(target error) bool {
	if target == nil || e.err == nil {
		return e.err == target
	}

	return errors.Is(e.err, target)
}

func (e *Error) Unwrap() error {
	u, ok := e.err.(interface {
		Unwrap() error
	})
	if !ok {
		return e.err
	}

	return u.Unwrap()
}

2. 封装wrapfunc helper

注意,

这里如果是最原始的err(即wrap前的err), 会使用[Raw:Error]标注
如果是中间层的, 会附加layer(哪一层)和function(哪个函数)这两个信息
这里定义了一个 helper 方法, 用于在

func makeMessage(err error, layer, function, msg string) string {
	var message string
	var e Error
	if errors.As(err, &e) {
		message = fmt.Sprintf("[%s:%s] %s => %s", layer, function, msg, err.Error())
	} else {
		message = fmt.Sprintf("[%s:%s] %s => [Raw:Error] %v", layer, function, msg, err.Error())
	}

	return message
}

func Wrapf(err error, layer string, function string, format string, args ...interface{}) error {
	if err == nil {
		return nil
	}

	msg := fmt.Sprintf(format, args...)

	return Error{
		message: makeMessage(err, layer, function, msg),
		err:     err,
	}
}

type WrapfFuncWithLayerFunction func(err error, format string, args ...interface{}) error

func NewLayerFunctionErrorWrapf(layer string, function string) WrapfFuncWithLayerFunction {
	return func(err error, format string, args ...interface{}) error {
		return Wrapf(err, layer, function, format, args...)
	}
}

3. 使用

在某个函数体内, 涉及到需要return err或中间层

errorWrapf := errorx.NewLayerFunctionErrorWrapf("Handler", "ListSubject")

_, err := svc.ListPaging(body.Type, body.Limit, body.Offset)
if err != nil {
    err = errorWrapf(err, "svc.ListPaging type=`%s` limit=`%d` offset=`%d` fail!",
			body.Type, body.Limit, body.Offset)
		return err
}

注意, wrap时包含关键的调用参数/返回值等等, 但是不能包含敏感数据

漫谈技术选型

Mon, 25 Jan 2021 18:00:00 +0800

去年八月份的一次小组分享, 去掉了敏感信息和示例

Go: 基于 apitest 做handler层单元测试

Fri, 22 Jan 2021 14:35:00 +0800

apitest

A simple and extensible behavioural testing library. Supports mocking external http calls and renders sequence diagrams on completion. Credit to testify which is this libraries’ only dependency

老的方案: postman/newman

原先使用 postman + newman 的方式做的 API 功能测试;

这种方式不完全是API层的单元测试, 预先配置好数据库/初始化好数据后, 直接通过API调用, 判定响应值

是介于单元测试 + 集成测试之间的一种测试, 但是既不是完备的单元测试, 也不是完整的集成测试;

好处:

简单方便, 在本地开发调试API时, 就能将调试请求直接转为测试用例

缺点:

难以维护: 更新API/增加API时, 未实时同步更新测试用例; 变更上层协议时, 例如middleware, 所有case需要改
违背Isolate原则: 无法独立, 每个case运行时, 前面执行的数据会影响后面执行的数据; 每个case都需要考虑规避之前case的数据影响
缺乏完备性: 一个API一般只构造一个失败, 一个成功两个Case

新的方案

Golang 使用 apitest 做handler层的单元测试
当前只覆盖核心逻辑
重新去寻找集成测试的方案

1. 入门示例

func TestApi(t *testing.T) {
	apitest.New().
		Handler(handler).
		Get("/user/1234").
		Expect(t).
		Body(`{"id": "1234", "name": "Tate"}`).
		Status(http.StatusCreated).
		End()
}

2. 传统httptest vs apitest

使用httptest

func TestPong(t *testing.T) {
	r := util.SetupRouter()
	r.GET("/test", Pong)

	req, _ := http.NewRequest("GET", "/test", nil)
	w := httptest.NewRecorder()
	r.ServeHTTP(w, req)

	assert.Equal(t, 200, w.Code)

	body, err := ioutil.ReadAll(w.Body)
	assert.NoError(t, err)
	assert.True(t, strings.Contains(string(body), "pong"))
}

使用apitest

func TestPong(t *testing.T) {
	r := util.SetupRouter()
	r.GET("/ping", Pong)

	apitest.New().
		Handler(r).
		Get("/ping").
		Expect(t).
		Body(`{"message":"pong"}`).
		Status(http.StatusOK).
		End()
}

3. why not JSONpath?

我们决定禁止在测试中使用JSONpath, 虽然这是apitest提供的一个强大的特性

官方示例: {"a": 12345, "b": [{"key": "c", "value": "result"}]}

func TestApi(t *testing.T) {
	apitest.New().
		Handler(handler).
		Get("/hello").
		Expect(t).
		Assert(jsonpath.Contains(`$.b[? @.key=="c"].value`, "result")).
		End()
}

问题点: 可维护性并不好(多一层学习和理解成本, JSONPath本身是一套很强大的语法, 但也就意味着其复杂度很高); 而单元测试最重要的就是后续的可维护性

4. JSONAssert: 封装 json 解析成map[string]interface

注意力集中在json body, 而不是解析

type JSONAssertFunc func(map[string]interface{}) error

func NewJSONAssertFunc(t *testing.T, assertFunc JSONAssertFunc) func(res *http.Response, req *http.Request) error {
	return func(res *http.Response, req *http.Request) error {
		body, err := ioutil.ReadAll(res.Body)
		assert.NoError(t, err, "read body from response fail")

		defer res.Body.Close()

		var data map[string]interface{}
		//var data Response

		err = json.Unmarshal(body, &data)
		assert.NoError(t, err, "unmarshal string to json fail")

		return assertFunc(data)
	}
}

使用

func TestVersion(t *testing.T) {
	r := util.SetupRouter()
	r.GET("/version", Version)

	apitest.New().
		Handler(r).
		Get("/version").
		Expect(t).
		Assert(util.NewJSONAssertFunc(t, func(m map[string]interface{}) error {
			assert.Contains(t, m, "version")
			assert.Contains(t, m, "commit")
			assert.Contains(t, m, "buildTime")
			assert.Contains(t, m, "goVersion")
			assert.Contains(t, m, "env")
			return nil
		})).
		Status(http.StatusOK).
		End()
}

5. ResponseAssert: 封装成后台返回协议(Response)

type Response struct {
	Code    int         `json:"code"`
	Message string      `json:"message"`
	Data    interface{} `json:"data"`
}

type ResponseAssertFunc func(Response) error

func NewResponseAssertFunc(
	t *testing.T,
	responseFunc ResponseAssertFunc,
) func(res *http.Response, req *http.Request) error {
	return func(res *http.Response, req *http.Request) error {
		body, err := ioutil.ReadAll(res.Body)
		assert.NoError(t, err, "read body from response fail")

		defer res.Body.Close()

		var data Response

		err = json.Unmarshal(body, &data)
		assert.NoError(t, err, "unmarshal string to response fail")

		return responseFunc(data)
	}
}

使用

func TestCreateSystemBadRequestInvalidJson(t *testing.T) {
	r := util.SetupRouter()
	url := "/api/v1/systems"
	r.POST(url, CreateSystem)
	// validate fail
	apitest.New().
		Handler(r).
		Post(url).
		JSON(map[string]interface{}{
			"hello": "123",
		}).
		Expect(t).
		Assert(util.NewResponseAssertFunc(t, func(resp util.Response) error {
			assert.Equal(t, resp.Code, util.BadRequestError)
			assert.Equal(t, resp.Message, "bad request:ID is required")
			return nil
		})).
		Status(http.StatusOK).
		End()
}

6. 能不能整合 ginkgo?

apitst的Expect方法接收的是 *testing.T, 对应interface是testing.TB

// Expect marks the request spec as complete and following code will define the expected response
func (r *Request) Expect(t *testing.T) *Response {
	r.apiTest.t = t
	return r.apiTest.response
}

并不兼容于 ginkgo 的GinkgoT()

7. 再抽象一层? No

不要再试图抽象成一个函数, 为了足够的灵活性, 势必导致函数参数数量增多, 导致使用困难;

最终完备的函数封装跟链式调用已经没有区别了

问题复杂化了. 再次封装的意义不大

func assertRequestResponse(
	t *testing.T,
	r http.Handler,
	url string,
	appCode, appSecret string,
	jsonData map[string]interface{},
	assertFunc func(res *http.Response, req *http.Request) error) {

	// 问题:
	// 1. post/get/put/delete
	// 2. headers
	// 3. query参数等等

	apitest.New().
		Handler(r).
		Post(url).
		Header("X-App-Code", appCode).
		Header("X-App-Secret", appSecret).
		JSON(
			jsonData,
		).
		Expect(t).
		Assert(
			assertFunc,
		).
		Status(http.StatusOK).
		End()

}

Go: go-sql-driver interpolateparams参数优化

Fri, 22 Jan 2021 12:00:00 +0800

这是在做 Golang 项目中的一些实践

interpolateparams

性能差异

interpolateparams=false

interpolateparams=true

10261 -> 12117, 18%

带占位符SQL执行流程

prepared -> execute -> close

正常带占位符的sql执行过程:

客户端将该语句和参数发给mysql服务器
mysql服务器编译成一个prepared语句，这个语句可以根据不同的参数多次调用

好处:

避免通过引号组装拼接sql语句。避免sql注入带来的安全风险
可以多次执行的sql语句

这个参数做了什么?

execute -> close

interpolateparams=true执行流程: execute -> close

好处:

减少了prepared网络请求
会防止SQL注入, 在驱动中通过转义特殊字符实现的

源码

    prepared, err := mc.interpolateParams(query, args)
		if err != nil {
			return nil, err
		}
		query = prepared

		如果query替换成功, 直接执行 writeCommandPacketStr, 并且读取返回值, return (rows, err)

mc.interpolateParams中, 对string/[]byte等做了转义, prepared是插值后的sql

Go: 基于 Ginkgo 框架进行单元测试实践

Fri, 22 Jan 2021 11:00:00 +0800

这是在做 Golang 项目中的一些实践

ginkgo 基于BDD的测试框架; 开始前, 需要花半个小时阅读官方文档

reference

github: https://github.com/onsi/ginkgo
文档: https://onsi.github.io/ginkgo/

table-driven

一个函数

// TruncateString truncate string to specific length
func TruncateString(s string, n int) string {
	if n > len(s) {
		return s
	}
	return s[:n]
}

使用table-driven方式生成测试代码

func TestTruncateString(t *testing.T) {
	type args struct {
		s string
		n int
	}
	tests := []struct {
		name string
		args args
		want string
	}{
		// TODO: Add test cases.
	}
	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			if got := util.TruncateString(tt.args.s, tt.args.n); got != tt.want {
				t.Errorf("TruncateString() = %v, want %v", got, tt.want)
			}
		})
	}
}

如果是简单的util函数, 用例比较简单并且用例数量较少, 此时单元测试可读性和可维护性没有问题

table-driven的问题

当涉及业务相关的单元测试, 此时

用例复杂, 输入可能是多层嵌套的struct, 某一层的某个变量的值影响输出
用例数量多, 某个函数可能有5个以上的用例

由于table-driven的表达能力有限:

如何复用输入结构体? (当前情况开发会复制粘贴过去改)
name过于简单不被重视, 导致单元测试失败时难以快速阅读

最终带来的问题是:

单个用例构造复杂, 可能是十几行甚至是几十行;
用例和用例之间没有复用, 基本基于复制粘贴;
难以区分用例之间的差异
用例过多导致难以维护, 不能明确知道每个用例的目的, 用例和用例之间的差别;
单个测试集过大, 可能有几百行测试代码;

难以阅读/难以理解/难以维护

Ginkgo解决什么问题?

优势:

丰富的表达能力
复用: 减少了大量重复代码, 复用
让注意力更集中, 只关注每个用例的差异点
减少了认知负担, 每个case有明确的描述/上下文/差异
更好维护

注意, 实践中:

使用 Describe和Context描述/表示行为和逻辑, 以及层次结构
使用 It 描述及放置每一个用例
利用BeforeEach构建每个用例(It)用到的公共内容(setup); 利用AfterEach执行回收动作(teardown). 此时BeforeEach用到闭包, 构建闭包变量/类型声明等, 在每个It中可以复用到
使用testify 替换ginkgo的Matcher Using Other Matcher Libraries
- 1. 减少目前迁移切换的工作量
- 1. testify语法更加简洁直接, ginkgo matcher语法略啰嗦多敲好多字

请先阅读官方文档之后, 再开始阅读以下内容

1. 基于ginkgo的table-driven

使用场景: util类的简单测试, input和expect都比较简单

使用

package util_test

import (
	"fmt"
	"strconv"
	"testing"

	. "github.com/onsi/ginkgo"
	. "github.com/onsi/ginkgo/extensions/table"
	"github.com/stretchr/testify/assert"

	"example/pkg/util"
)

var _ = Describe("String", func() {

	Describe("TruncateBytes", func() {
		var s = []byte("helloworld")

		DescribeTable("TruncateBytes cases", func(expected []byte, truncatedSize int) {
			assert.Equal(GinkgoT(), expected, util.TruncateBytes(s, truncatedSize))
		},
			Entry("truncated size less than real size", []byte("he"), 2),
			Entry("truncated size equals to real size", s, 10),
			Entry("truncated size greater than real size", s, 20),
		)
	})
})

2. 基于闭包/BeforeEach/It的复用

使用场景: 复杂的输入

Extracting Common Setup: BeforeEach

简单复用

		Describe("WithoutResourceType", func() {
			var a types.Action
			BeforeEach(func() {
				a = types.NewAction()
			})

			It("true", func() {
				assert.True(GinkgoT(), a.WithoutResourceType())
			})

			It("true, empty ResourceType", func() {
				a.Attribute.SetResourceTypes([]types.ActionResourceType{})
				assert.True(GinkgoT(), a.WithoutResourceType())
			})

			It("false", func() {
				a.Attribute.SetResourceTypes([]types.ActionResourceType{
					{
						System: "test",
						Type:   "test",
					},
				})
				assert.False(GinkgoT(), a.WithoutResourceType())
			})

		}

复杂的复用

	Describe("GetPolicesAttrKeys", func() {
		var resource *types.Resource
		var policies []types.AuthPolicy
		BeforeEach(func() {
			resource = &types.Resource{
				System:    "test",
				Type:      "host",
				ID:        "1",
				Attribute: nil,
			}
			policies = []types.AuthPolicy{}
		})

		It("fail", func() {
			errExpr := `[{"system": "test", "type": "host", "expression":
{"OR": {"content": [{"NotExists": {"id": []}}]}}}]`
			policies = []types.AuthPolicy{
				{
					Expression: errExpr,
				},
			}
			_, err := GetPolicesAttrKeys(resource, policies)
			assert.Error(GinkgoT(), err)
		})
})

with patch

	Describe("FillSubjectDetail", func() {
		var r *request.Request
		var ctl *gomock.Controller
		var patches *gomonkey.Patches
		BeforeEach(func() {
			ctl = gomock.NewController(GinkgoT())
			r = request.NewRequest()
		})
		AfterEach(func() {
			ctl.Finish()
			if patches != nil {
				patches.Reset()
			}
		})

		It("pip.GetSubjectPK fail", func() {
			patches = gomonkey.ApplyFunc(pip.GetSubjectPK, func(_type, id string) (pk int64, err error) {
				return -1, errors.New("get subject_pk fail")
			})
			err := r.FillSubjectDetail()
			assert.Error(GinkgoT(), err)
			assert.Contains(GinkgoT(), err.Error(), "get subject_pk fail")

		})
})

ginkgo cli

ginkgo cli文档

bootstrap & generate

# 进入模块
$ cd pkg/util

# 生成一个模块的 {module_name}_suite_test.go
$ ginkgo bootstrap

# 生成模块下某个文件 {file_name}_test.go
$ ginkgo generate set

run

# 运行当前目录下的
$ ginkgo

# 带tags和gcflags (如果做了mock)
$ ginkgo -tags=jsoniter -gcflags=all=-l

# 递归执行当前目录及所有子目录下的
$ ginkgo -r -v -cover

# 只执行某几个目录
$ ginkgo  -r pkg/util pkg/cache

确认覆盖率 make test && make cov

# in Makefile
test:
	go test -mod=vendor -gcflags=all=-l $(shell go list ./... | grep -v mock | grep -v docs) -covermode=count -coverprofile .coverage.cov

cov:
	go tool cover -html=.coverage.cov

Better Code: 使用property

Mon, 07 Oct 2019 08:00:00 +0800

introduction

@property 是Python的一个内置函数, 通过property, 我们可以获得更好的可读性/可维护性

屏蔽细节, 对于外部使用者, 不需要知道更多的细节!
可读性更好, 调用方只有简单直接的逻辑, 而对象实体中包含了具体处理逻辑
可维护性更好, 细节不会被扩散到其他地方, 后续变更修改更容易

refactor

代码坏味道:

当你发现调用处, 每个地方获取到返回值后, 都做了一模一样的处理;
变更属性的格式/分隔符等细节, 发现需要修改多个地方代码
调用者需要感知到属性的当前值[1, 2, 3](type: list) 以及原始值1,2,3(type: str)

使用property之后:

所有调用处, 没有重复代码
变更属性的格式/分隔符等细节, 只需要修改一个地方
调用者只知道属性的当前值[1, 2, 3]

usage

思路: 将属性通用的处理内化, fat model对外屏蔽细节, 避免了使用者的冗余代码以及过多的认知负担;

side effect: 可以在set/get/delete 操作时, 额外进行一些处理, 例如校验, 做一些额外变更等(存在副作用)
adapter: 也可以作为类似adapter, 组合或者拼装出对调用者更为友好的做法
封装/facade: 对于类/对象实例, 更多的是起到facade 模式的作用, 将更多的细节封装, 对外屏蔽, 只暴露有限的内容

1. 属性校验

class Student(object):

    @property
    def score(self):
        return self._score

    @score.setter
    def score(self, value):
        if not isinstance(value, int):
            raise ValueError('score must be an integer!')
        if value < 0 or value > 100:
            raise ValueError('score must between 0 ~ 100!')
        self._score = value

2. 限制只读

class Student(object):

    @property
    def birth(self):
        return self._birth

3. 拼装组合出额外的属性

class Staff:
    @property
    def email(self):
        return f'{self.username}@{self.domain}'

4. 类型/格式转换

下面示例是django 中的一种用法, 在db中字段名为maintainers, 是一个字符串, 但是对于模型使用者, maintainers是一个列表, 通过property, 屏蔽了字段类型/分隔符等细节

class API(models.Model):
      _maintainers = models.CharField(db_column='maintainers', max_length=1024)
      @property
      def maintainers(self) -> List[str]:
          if not self._maintainers:
              return []
          return self._maintainers.split(";")

      @maintainers.setter
      def maintainers(self, data: List[str]):
          self._maintainers = ";".join(data)

或者:

class A():
    @property
    def data(self):
        return json.loads(self._data)
    @data.setter
    def data(self, d):
        self._data = json.dumps(d)

摘录-架构整洁之道

Mon, 07 Oct 2019 08:00:00 +0800

P1: 概述

好的架构 => 降低 项目构建与维护的人力成本
复杂度 => 成本
大部分程序员的误区: 他们的工作是且仅是按照需求文档编写代码, 并且修复任何bug. 这是行为价值, 紧急而不重要; 架构价值, 重要不紧急.

P2: 从基础构件开始: 编程范式

结构化: 模块降解拆分
面向对象: 封装(可见/不可见), 继承, 多台(IoC依赖反转)
函数式: 隔离可变, 不可变

P3: 设计原则

solid原则: 告诉我们如何将数据和函数组织成类, 以及如何将这些类链接起来成为程序

构建中层结构的主要目标:

使软件可容忍被改动
使软件更容易被理解
构建可在多个软件系统中复用的组件

1. SRP 单一职责原则

康威定律的一个推论: 一个软件系统的最佳结构高度依赖于开发这个系统的组织的内部结构. 每个软件模块都有且仅有一个需要被改变的理由

面向底层实现细节: 每个模块都应该只做一件事; 确保一个函数只完成一个功能
任何一个软件模块都应该只对某一类行为者负责

不同行为者所依赖的代码必须要分开; 需要将服务不同行为者的代码进行切分;

2. OCP 开闭原则

如果软件系统想要更容易被改变, 那么其设计就必须允许新增代码来修改系统的行为, 而非只能拷修改原来的代码

设计良好的计算机软件应该易于扩展, 同时抗拒修改; 应该在不需要修改的前提下就可以轻易被扩展

设计原则: 如果A组件不想被B组件上发生的修改所影响, 那么就应该让B组件依赖于A组件
软件系统不应该依赖于其不直接使用的组件

3. LSP 里氏替换原则

如果想用可替换的组件来构建软件系统, 那么这些组件就必须遵循同一个约定, 以便让这些组件可以相互替换

LSP 可以且应该被应用于软件架构层面, 因为一旦违背了可替换性, 该系统架构就不得不为此增添大量复杂的应对机制

4. ISP 接口隔离原则

在设计中避免不必要的依赖

在一般情况下, 任何层次的软件设计如果依赖于不需要的东西, 都会是有害的.

5. DIP 依赖反转原则

高层策略性的代码不应该依赖于底层细节的代码. 应该反过来

如果想要设计一个灵活的系统, 在源代码层次的依赖关系就应该多引用抽象类型, 而非具体实现
稳定的抽象层: 接口比实现更稳定

该设计原则具体的编码守则:

应在代码中多使用抽象接口, 尽量避免使用哪些多变的具体实现类. 适用于所有编程语言; 对象的创建过程也应该受到严格限制, 通常会使用抽象工厂模式
不要在具体实现类上创建衍生类.
不要覆盖(override)包含具体实现的函数
应避免在代码中写入任何具体实现相关的名字, 或者其他容易变动的事物的名字

P4: 组件构建原则

组件是软件的部署单元, 是整个软件系统在部署过程中可以独立完成部署的最小实体.

4.1 组件聚合原则

1. REP: 复用/发布等同原则

软件复用的最小粒度应等同于其发布的最小粒度

2. CCP: 共同闭包原则

我们应该将那些会同时修改, 并且为相同目的而修改的类放到同一个组件中, 而将不会同时修改, 并且不会为了相同目的而修改的那些类放到不同的组件中
一个组件不应该同时存在多个变更原因
对于大部分程序来说, 可维护性的重要性要远远高于可复用性
我们应该将变更原因不同的类放入不同的组件中

3. CRP: 共同复用原则

不要强迫一个组件的用户依赖他们不需要的东西
帮助决策类和模块归属于哪一个组件的原则;
将经常共同复用的类和模块放到同一个组件中

4.2 组件耦合

无依赖环原则: 组件依赖关系图中不应该出现环; (也不应该出现反向依赖)
自下而上的设计: 组件结构图是不可能自上而下被设计出来的. 必须随着软件系统的变化而变化和扩张, 而不可能在系统构建的最初就被完美设计出来
稳定依赖原则: 依赖关系必须要指向更稳定的方向. 预期会经常变更的组件都不应该被一个难以修改的组件所依赖, 否则这个多变的组件也将会变得难以被修改. 稳定性指标=出依赖/(出依赖+入依赖)
稳定性依赖原则SDP: 让每个组件的I指标都必须大于其所依赖组件的I指标. 按依赖方向递减.
稳定抽象原则SAP: 一个组件的抽象化程度应该预期稳定性保持i一致.
稳定抽象原则: 为组件的稳定性于它的抽象性程度建立了一种关联. 1) 要求稳定的组件同时应该是抽象的, 这样它的稳定性就不会影响到扩展性. 2)一个不稳定的组件应该包含具体的实现代码, 这样它的不稳定性就可以通过具体的代码被轻易修改. 如果一个组件要成为稳定组件, 那么它就应该由接口和抽象类组成, 以便将来做扩展

抽象与稳定
痛苦区: 稳定, 难以被修改和扩展, 这个组件不是抽象的(典型案例: 数据库表结构schema, 工具型类库)
无用区: 无限抽象, 没有被其他组件依赖, 往往无法被使用;(典型案例: 历史原因前人写的没有实现的抽象类)
避开这两个区域, 让组件落在主序列线

P5: 软件架构

软件架构师自身需要是程序员, 并且必须一直坚持i做一线程序员, 绝对不要听从那些说应该让软件架构师从代码中解放出来以专心解决高阶问题的伪建议

如果不亲身承受因系统设计而带来的麻烦, 就体会不到设计不佳所带来的痛苦, 接着就会逐渐迷失正确的设计方向
如果想设计一个便于推进各项工作的系统, 其策略就是要在设计中尽可能长时间地保留尽可能多的选项
软件架构设计的主要目标是支撑软件系统的全生命周期, 设计良好的架构可以让系统便于理解, 易于修改, 方便维护, 并且能轻松部署. 软件架构的终极目标就是最大化程序员的生产力, 同时最小化系统的总运营成本.
用例: 一个系统的架构必须能支持其自身的设计意图. 非常直观地支持这类应用可能会涉及的所有用例
我们无法预知全部的用例: 好在架构师应该还是之道整个系统的基本设计意图的
软件架构设计本身就是一门划分边界的艺术.
边界的作用就是将软件分隔成各种元素, 一遍约束边界两侧之间的依赖关系
一个系统中最消耗人力资源的是什么? 系统中存在的耦合–尤其是那些过早做出的, 不成熟的决策所导致的耦合. 那些决策与系统业务需求(用例)无关的, 细节性的决策(框架/数据库/web服务器/工具库/依赖注入等)应该是辅助的, 可以被推迟.
一个设计良好的系统架构不应该依赖于这些细节, 而应该尽可能地推迟i这些细节性的决策, 并致力于将这种推迟i所产生的影响降到最低.
软件架构设计的工作重点之一就是: 将策略彼此分离, 然后将它们按照变更的方式进行重新分组. 维度: 变更原因, 时间和层次
业务实体 Entity: 关键业务逻辑和关键业务数据是紧密相关的, 很适合放在同一个对象中处理
业务逻辑: 应该是系统中最独立, 复用性最高的代码
架构设计的核心目标: 一个良好的架构设计应该围绕着用例展开. 尽可能地允许用户推迟和延后应该采用什么框架/数据库/web服务等. 良好的架构设计应该只关注用例, 并能将它们与其他周边的因素隔离.

外层代表的是机制, 内层代表的是策略
依赖关系规则: 源码中的依赖关系必须只指向同心圆的内层, 即由低层机制指向高层策略

P6: 实现细节

数据库/Web/应用程序框架都是实现细节!

好的架构 how:

对项目有整体的认识
对需求有足够的了解
对未来有所预见
意识到现有系统的问题, 复杂度的来源
知道如何去解决这个问题: 重新设计/重构/优化

读书笔记-遗留系统重建实战

Sun, 11 Aug 2019 00:00:00 +0800

遗留项目: 任何已存在的, 难以维护或难以扩展的项目

这本书总体来说还不错, 值得一读

第一章: 了解遗留项目中的挑战

特征:

老旧
庞大
继承而来
文档不完善

遗留代码:

没有测试和无法测试的代码: 难以确认
不灵活的代码: 难以修改和扩展
被技术债拖累的代码:

遗留基础设施:

开发环境: 难以搭建/搭建成本高, 构件工具/项目中构件脚本/文档中大量的手工步骤
过时的依赖: 没有定期维护, 带来了后期升级维护的成本和风险
异构环境: 不同环境不能保持一致, 这种环境不一致带来的风险(无法模拟生产环境)

遗留文化:

害怕变化: 缺少信息 1)哪些功能不再使用可以移除? 2)哪些bug可以被安全的修复 3) 改动之前应该咨询哪些用户? -> 结果: 保持现状是最安全的选择; 纯粹的风险, 忽略了带来的好处;
知识仓库: 知识的匮乏; 团队知识的共享和传承; 1) 缺乏面对面沟通 2)代码是我的 3)忙碌的面孔

第二章: 找到起点

恐惧: 遗留系统带来的不确定性; 对未知的恐惧: 更改了一行代码可能会破坏一些根本不相关的东西

探索性重构: 尝试重命名方法, 在两个类之间移动方法, 引入新的接口, 添加注释等等小变更

好处:

增加你对代码的理解, 了解越多, 掌握的信息就越多, 恐惧越少;
提高的代码的可读性;
在版本控制系统/IDE/编译器/其他开发人员等帮助下, 更简单且安全

特征测试: 验证系统指定部件当前的行为

收集软件的有用数据:

静态代码分析工具 / bug查找工具
性能: 性能测试+生产环境性能监控
错误计数: 例如500错误
对常见的任务计时: 1) 从头开始搭建开发环境时间 2) 发布或部署项目所花的时间 3) 修复一个bug的平均时间
版本库中修改最多的文件

静态分析工具

FindBugs: 查找java中潜在的bug -> 修复关键bug
PMD: 是否遵循最佳实践 -> 修复
CheckStyle: 修复风格问题, 提高可读性

第三章: 准备重构

重构时始终记得组织的目标

两种角色:

传统主义者: 不要碰任何东西, 强烈反对任何形式变化的开发者; 认为重构会带来不必要的风险;
反传统主义者: 所有东西都要重写; 厌恶遗留代码; 热衷于提高代码质量, 但是可能过于激进;

需要通过沟通, 确保团队每个人对项目有相同的理解, 统一目标及计划;

获得组织的批准

选择重构的目标: 三个维度评估, 难度/风险/价值

容易实现的目标: 风险=低, 难度=低
痛点: 价值=高

重构还是重写?

不应该重写的情况: 1)风险 2)开销 3)任务总是超出预期时间
重写的好处: 自由/可测试性
重写的必要条件: 1) 尝试过重构并且失败了 2) 编程范型的转变
第三种方式: 增量重写, 将重写分成若干个较小的阶段, 每个阶段都应该提供业务价值, 应该可以在任何给定阶段之后停止项目, 并且仍然能获得一些好处.

第四章: 重构

有纪律的重构:

把重构和其他的工作分开
依靠IDE的refactor!
依靠版本控制系统

常见的遗留代码的特征和重构

移除陈旧代码:

被注释掉的代码
死代码: 绝对不会被执行的代码
僵尸代码: 那些功能已经去掉或者不再存在
过期代码: 时间依赖/ab test/活动等

移除有毒的测试:

没有测试任何东西
脆弱的测试:
随机失败的测试

第五章: 重搭架构

重搭架构是比方法和类更高级别的重构. 可以把它想像成大型的重构, 将大型应用拆分为多模块

好处:

通过模块化内建质量
良好的涉及保障可维护性
通过独立达到自治

涉及:

单体应用拆分为多模块
前后端分离
微服务

其他

开发环境自动化:

一个好的README
vagrant/ansible/docker等实现开发环境自动化

多环境一致性: 测试环境/预发布环境/生产环境

开发/构建/部署过程自动化

Linux 项目持续成功: 公开和坦诚沟通的文化, 重视CodeReview

主题

1. 源代码并不是项目的全部

2. 信息不能是自由的

文档: 信息丰富/易于编写/易于发现/易于阅读/可信赖

促进沟通: 代码评审/结对编程/技术访谈/向其他团队展示你的项目/黑客日

3. 工作是做不完的

维护代码库质量十一个永无止境的任务; 需要保持警惕并在质量问题一出现就解决它

定期进行代码评审 / 破窗理论

4. 自动化一切

自动化测试/自动化构建/自动化部署等

使你的生活更加轻松
是你的接班人的生活更加轻松

5. 小型为佳

保持代码库小型轻量;

[分享]深度工作

Tue, 02 Jul 2019 12:30:00 +0800

之前做的一个分享

你需要更多的思考时间

Sun, 23 Jun 2019 08:00:00 +0800

目前每天都七点半准时起, 无论是否工作日, 几个月下来, 觉得时间多了好多.

最近三个月阅读时间多了很多, 无他, 只因每天要早起坐班车, 下班也坐班车, 每天有大概一个半小时在车上, 只能用kindle打发时间.

每天比其他同事差不多早了一个小时到公司, 这段时间用来做什么呢?

我的答案是: 不要立刻开始工作

当然, 每个人选择不一样, 可能这一个小时没人打扰, 编码效率会高一点.

但是, 为什么不将这个时间空出来, 做一些其他事情, 这些事情, 可以起到类似杠杆作用, 撬动你的工作, 提升效率, 减少无畏的时间浪费, 以便更好地享受生活呢?

当下

我们总是被当下的工作所淹没, 即, 注意力被现在的工作抓走. 例如: 昨天有个bug没修, 今天会有个需求会, 下午要和谁对接口, 晚上要上线等等.

而当一天的工作开始后, 你将马不停蹄, 奔波在各种事务中, 忙累了一天之后, 下班回家洗洗睡, 明天继续

你可能某天觉得好累, 厌倦, 生活过成了模式

假设你有更多的时间思考

所以, 假设你每天有一小时时间, 用来做什么?

思考!

一个人思考!

不管是上班前, 还是下班后, 不管是在公司, 还是回家了, 你都有必要给思考留一些时间, 如果一小时太多, 十五分钟就够了.

思考什么呢? 任何事情, 工作或者生活的问题, 抛出来, 思考, 做一些决策和记录

例如: 工作的风格是不是有需要改进的地方? 昨天与人沟通是不是太过激进了? 今天这个方案有个细节似乎有问题? 今天周五晚上去哪浪? 昨天的bug可能是什么原因? 最近有个手工操作频率很高, 自动化要花多久每次能省多少时间?

注意, 这时候不要开 vim 或者 IDE, 不要开文档等等, 不要在意细节, 思考, 得到结论, 记录, 该做的加入todo list.

例如:

- 将xx操作自动化 => 加入到trello的近期事项中
- 晚上去xx 吃饭   => 直接发微信给老婆
- 方案 XX 有问题  => 记录事项到list, 具体确定时注意
- bug可能原因是:xxx   => 将猜测记录到对应issues
- xxx需要优化  => 到对应issue评论

这些都是很发散的问题, 但是有了安静思考的时间, 可以做出更好的决策, 或者有更好的想法.

每件事情, 都会随着时间推移, 变得更好.

另外, 还可以针对近期工作做下梳理, 以及对今日的todo list做下排期;

然后进入第二步

Learn something

第一步, 花的时间可能10分钟不到, 你可以理清楚很多事情.

那么, 剩下的40-50分钟做什么?

学习!

学什么? 跟项目相关的, 跟工作相关, 跟自己思考问题得到结论相关的内容.

例如, 合作项目对方用的xxx技术, 你从来没有接触过, 昨天接入只是扫了眼文档完成接入, 那么你可以google下这个关键词, 然后开始了解, 甚至深入学习.

例如, 昨天遇到一个报错, 解决了但是没有来得及深究, 这时候可以开始深究

你的经验, 主要来自于你的工作, 以及工作相关的领域. 所以, 需要从这些部分学习, 深入, 得到最大化的成长.

注意, 尽量关注跟工作相关的领域, 那些可能跟你工作相关性很低的领域, 除非0)你在不远的将来会涉及 1) 你想转领域了 2) 你感兴趣或者对你成长有帮助 3) 你对本领域已经很有经验了想尝试下(或许有些激进, 个人观点)

例如, 你是个初级的前端开发, 每日忙于工作, 工作所涉及的技术还没有吃透, 看到机器学习很火想学, 每天花一两个小时在上面, 但是工作中用不到, 你短期内又不可能转, 绝大多数人, 最终是跑了一大堆开源项目的hello world, 走马观花了下文档和各种公司. 那么, 每天的这一两个小时相当于是损耗时间, 作用很小(性价比不高), 即使最终要转, 一样需要重头学习积累.

我的经验是:

跟当前工作相关, 才能事半功倍. 这样或许会有些功利, 但你我以及大部分人都是普通人, 精力有限, 用在刀刃上.

知行合一, 从工作内容出发去拓展, 未来实践的概率高, 对个人成长提升也大.

不说那么多, 40分钟过去, 差不多同事都陆续到了, 你只有几分钟时间, 就要进入战斗模式了

进入战斗模式之前, 建议第三步

每日计划

近两年, 个人一直在使用 trello 作为个人看板

每天在开始工作前, review下今天以及本周需要做的事情, 移动下卡片, 标注下deadline, 备注下注意事项等等

然后, 选择一个, 开始干活.

我们总是容易沉溺于繁杂的事务, 而忘了身在何处.

每天独处的思考时间, 可以让我们脱出局中, 而无论是工作还是生活, 都会逐步改善

每天学习, 然后在工作中实践, 才能感受到成长的力量

每日计划, 效率加成

2019-06-23 深圳

Django项目重构小结

Thu, 06 Dec 2018 08:00:00 +0800

由于历史原因, 项目组中存在很多历史悠久的项目.

这类项目, 有着一些共同特征: 历史悠久, 几度经手, 缺乏文档, 维护困难, 模块不合理, 代码坏味道, 版本老旧等等.

总之, 维护困难.

如果维护需求不多, 基本不动, 这类项目可以保持现状, 稳定运行不出问题就行.

但是, 另一方面, 如果项目需求多, 需要频繁修改, 由于项目的原因导致变更困难/进度缓慢/问题频出, 那么就该考虑进行代码重构了.

梳理了一些django项目重构的事项, 供参考.

1. code review

将核心代码做个pr, 组织一次线上的code review.

不要线下review, 此时代码可能非常庞大, 本身并不适合review
要有本项目历史维护者参与, 也要有非项目维护者的外部人员参与

线上reivew一周, 收集大家的comment, 之后做个分类汇总

2. 升级django版本

如果是django1.3及以下, 可以考虑升级到 1.8

做升级, 并做相应的变更, 使得程序能正常运行

可以考虑升级到django2.x(python3)

3. use CBV or DRF

具体区别可以参考 Class-Based Views vs. Function-Based Views

老旧项目, 90%以上都是 FBV(Function-Based-View), 如果项目比较小, 使用FBV可以短平快地搞定需求.

但是如果项目变得比较大了, 可以考虑使用 CBV

对于大型项目, 建议使用 DRF(Django REST framework), 中小型项目不建议引入DRF的原因是, DRF有一定的学习门槛, 比较重, 可能引入不必要的复杂度.

微型项目: FBV or CBV
中小型项目: CBV
大型项目: DRF

此时会涉及(以下均是django 1.8文档)

可以:

权限控制使用mixin, 去掉了原先的权限控制decorator
定义抽象出自己需要的view, 例如MakoTemplateView / JsonView
合并相关的view

流程:　url不动, 将所有FBV改成CBV, 抽象及合并代码, 合并相关view

├── common
│   ├── __init__.py
│   ├── constants.py
│   ├── context_processors.py
│   ├── decorators.py
│   ├── exceptions.py
│   ├── http.py
│   ├── log.py
│   ├── middlewares
│   │   ├── __init__.py
│   │   └── exception.py
│   ├── mixins
│   │   ├── __init__.py
│   │   └── base.py
│   ├── responses.py
│   ├── tests.py
│   ├── utils.py
│   └── views
│       ├── __init__.py
│       └── mako.py

4. 分层及模块切分

严格的分层，使得每一层职责清晰；

thin views, fat models

业务逻辑, 尽量瘦小简短
将view中, 跟model具体对象相关的逻辑, 挪到model的方法中, 或者@property中, 补充一系列porperty/classmethod/staticmethod
注意, 不包含{application}.objects.xxxx的ORM操作

　fat managers

将view中, 跟ORM相关的复杂逻辑, 挪到manager中
[拆分出{application}/manager.py]
Django Manager

use form

使用django form替换掉所有参数处理及校验相关的代码
去除/合并原有的逻辑代码
[拆分出{application}/forms.py]

use enum

replace all the magic number and build the choices for model
[拆分出common/constants.py 和 {application}/constants.py]
common/constants.py 放项目全局常量
{application}/constants.py 放app局部使用常量

add utils helpers

将工具类代码逻辑进行抽离, 减少代码容易
[拆分出common/utils.py 和 {applications}/utils.py]

├── app
│   ├── __init__.py
│   ├── admin.py
│   ├── constants.py
│   ├── forms.py
│   ├── manager.py
│   ├── migrations/
│   ├── models.py
│   ├── tests.py
│   ├── urls.py
│   ├── utils.py
│   └── views.py

stupid template

将复杂逻辑, 移到后端来
如果使用django原生的模板, 可以善用 Built-in template tags and filters 以及自定义Custom template tags and filters
如果使用mako的, 尽量将数据构造/判断等等, 放在后端搞定, 不要在模板中使用大量的判断逻辑, 模板尽量只渲染

5. 抽离第三方依赖api [拆分出components/xxx.py]

重灾区: 可能每个地方都有拼url, 调用, 处理返回值, 可能前期就一两个地方, 但是随着时间推移, 会出现腐烂的趋势, 很多地方直接拷贝, 改改用. 需要全部抽出
将原先散落在各处的依赖第三方系统的api调用, 全部抽出到同一个文件中
减少代码冗余
同时, 可以统一处理输入/输出/异常等
后续接口协议变更, 可以做统一变更

├── components
│   ├── __init__.py
│   ├── engine.py
│   ├── login.py
│   └── tests.py

6. 统一

重灾区, 由于历史及人员的不同习惯, 往往一个项目会引入非常多的不同的做法去完成同一件事.

在重构的节点, 我们必须将其统一, 否则由于破窗理论, 整体项目会越来越混乱.

原则:　做同一件事，只存在一种方法; 不要存在重复的代码; 不能妥协.

　常量

有时候, 同一个定义, 可能有几套常量, 每个人自己定义了一套

　utils

重灾区, 不同模块下, 可能每个开发者自己将历史工具类/函数拷贝过来, 而不是使用公共的
可能需求略有区别, 所以公共的工具模块/类, 需要重构支持

　错误码

统一所有错误码

异常

统一异常类
统一异常处理方式/风格
在同一层处理异常:　一种思路, 在middleware中统一处理所有类型异常, 而在view及其之下的调用链中可以减少try-except, 或者发现问题直接raise对应异常

　协议

统一的返回值结构
统一的http错误码/状态码
可能涉及前端变更调用, 但是, 该改动必须改
可以通过自定义view/mixin等方式处理, 也可以对django的Response/JsonResponse做一层封装

　unicode_literals

如果使用python2, 可以from __future__ import unicode_literals
不强求

7. 逐行重构

Python 代码规范小结
重构 - 读书笔记(Python示例)
删除无用的代码/注释/文档等
命名:　对所有变量名／常量名／函数名／类名／模块名等等重新思考，改成更合适的名字(此时编辑器或IDE的批量查找替换发挥作用)
归属问题:　函数／变量／方法等, 要思考是否属于这里, 不合适直接调整
表达式
控制流: return early / guard clauses….
异常处理
函数等
……
同时, 根据code review结果, 逐一修改
该加注释加注释, 该加文档加文档

8. format the url

因为要动前端调用, 所以放靠后会更合适

推荐使用restful风格
格式化url
涉及前端调用处一并修改
如果被其他系统依赖, 可能需要兼容老的url/协议, 可用, 但标明deprecated, 并同时提供新版本的url/协议

9. fix all pep8 issues

flake8 --config=.flake8 .

开始不忽略任何错误, 完整修一遍
重构所有过于复杂的函数 C901 XXXX is too complex
能不加# noqa就不加

10. unittest

加单元测试, 优先核心模块的核心逻辑

11. 然后

code review again
自测
测试
灰度
发布

工作七年小结: 学习,生活及其他

Sun, 01 Jul 2018 08:00:00 +0800

一切经历都是有价值的, 你要从中有所收获

再有三天, 工作七年了.

大学毕业前, 实习做了一年多的Java开发;

因为实习错过了校招, 11年一个人北上北京找工作, 阴差阳错, 找了个测试开发的工作, 没成为北漂, 向南飘到了杭州, 开始了自己的职业生涯.

在杭州一年多, 塑造我现在行事风格, 高效/专注/细心等等, 过多不表, 区间测试各种后端需要关注各种语言各种技术, 写自动化测试, 学习了shell和python等等, 然而国内测试开发其实更多的是测试, 发现自己并不是很喜欢, 年少冲动, 压不住内心的想法, 投了几个python简历, 之后毅然决然南下.

在深圳第一家公司, python后台开发, 一直做到14年, 从测试转为开发, 也算如鱼得水, 而且基本不加班, 所以有很多时间倒腾各种东西. 14年由于某些不可抵抗力公司over了, 如果没有over, 或许我现在还在那里. 离职出去浪了一个月, 回来愣头青有个抵挡不住的想法, 我想去创业公司…..

历时一周顺利入职创业公司, 公司团队都很nice, 从零到一开始做一些事情, 过程中对项目运作/产品开发等等, 都有了新的认识, 奈何天不遂人员, 入职十个月, 公司解散, 失业了.

然后, 这次浪得有点久, 整整一百天, 花了三天找到了工作, 入职了现在的公司, 一晃两年半了.

在深圳, 到现在已经5年半了. 五年三家公司, 也算经历丰富:)

想相信大部分人起点会好很多, 没那么折腾, 毕业进入公司, 可以一直呆三年, 五年, 可以很好的沉淀进步, 收获更多. 这么多年的折腾, 导致了我其实可以说正儿八经的开发生涯只有5年, 5年该到什么程度, 我也不知道, 我只知道, 我需要规划好, 不断学习和成长;

关于学习

我一直有两个观点:

从工作相关的内容出发, 向外扩散以及向下延伸, 学以致用, 不断实践-学习-实践的循环中逐步成长
成体系, 站在全局的角度, 思考业界的趋势和职业规划的方向所需要的技能体系, 像打游戏修炼一样, 点满技能树

第一点, 转换率最高, 因为跟每天使用接触的东西离得近, 所以胜在实践多, 成长高. 而不会了解了一堆概念, 写了一堆hello world, 但是平时无法使用, 逐步地这类无效学习的时间就沉没了. 但是前者范围小, 太过局限, 对于制定短期成长目标有效, 对长期方向性成长目标作用小.

第二点, 是方向性的内容, 对自己的职业发展有利. 各种技术革新非常快, 信息爆炸, 可能你一个月前关注了5.0版本, 一个月后6.0又出了, 人的精力有限, 应该用在刀刃上, 而那些在业界趋势以及跟自己职业规划契合的内容值得学习. 很多东西都不是一蹴而就, 是慢慢积累来的.

盲区

买很多书, 却无法静心看完, 收获有限

几年前, 我的想法是, 一本书都不买, 那么你收获永远是0, 买了书, 即使转化率低, 你的收获也是有的.

导致我这几年囤积了三四百本书, 其中有经典的, 也有快销品.

三年前出过一波, 今年因为有了一个叫多抓鱼的平台, 陆陆续续卖了几十本:)

我发现刚工作的时候, 买了很多快销书, 各种快速入门等等, 我追过ios/swift, 追过前端开发, 追过推荐系统, 追过…..回过头来, 发现收获有, 但是相对于投入的时间和精力, 转化率太低了.

所以有了本文的第一个观点, 从工作内容出发的学以致用.

如果我能早明白这一点……

一亩三分地, 够用就好

一路走来, 遇到过, 有些人觉得, 耕好自己的一亩三分地, 学到的内容够用就行; 但是这或许是那个工作十年实际只有一年经验的梗的出处

技术每时每刻在发展, 需要一直保持学习的信息, 不能停歇.

看过异类, 你会了解到, 每天的一点点差距, 经过时间的放大, 最终会变成鸿沟般的差距

怎么深挖?

实践>看书>开各种业界资料, 你刚好在做这块的, 一直在不断实践, 用法/机制/原理/概念等等, 然后通过书籍和资料, 深度挖掘之.

怎么成体系?

问自己问题: 1.业界现在的趋势是什么? 自己关注的部分是否是趋势? 或者是否有被淘汰的趋势 2. 自己喜欢的是什么? 职业规划是什么?

然后, 知识爆炸和知识付费的年代, 我相信获取相关的信息并不难, 很快的, 你可以理清楚一棵技能树, 然后在未来的日子里, 不断去点满之

过去我一直通过开源的资料+大牛的博客去学习, Google 是个好东西:)

而基于这些, 你又可以引到各种经典的书籍, 买了, 反复阅读之. 大多是大部头, 需要有耐心.

这两年流行知识付费, 种类繁多, 良莠不齐, 例如知乎的live, 付费的电子书, 付费视频课程, 极客时间等等. 虽然获取知识有成本了, 但是我很高兴见到这种情况, 因为, 过去距离你很远的大牛, 往往你只能从其博客和演讲了解和学习到一些东西, 而现在, 你可以成体系的学习这些内容. 而这其中, 我觉得知乎live最水(不成体系, 贵, 效果不行), 付费视频课程更适合短平快的初学者, 而极客时间, 适合体系化及深挖.

所以我推荐下极客时间

在这里放个广告, 是我买的课程的推广海报, 扫码购买后你我都有返现:)

我购买的课程

还是基于我上面的第一条第二条观点, 只关注工作相关的和对自己职业生涯有利的.

关于生活

生活是美好的, 生活也是操蛋的, 怎么过, 看自己.

follow your heart

我想这个鸡汤大家都喝过

但是, 遵循内心的想法去做选择, 却又是没错的

想想我第一次离职转开发, 以及后来想去创业, 都是遵循了自己内心的想法, 虽然有些冲动,

现在想想, 虽然错过了活得更轻松或者半财务自由的机会.

我们都要为自己的决定负责. 不需要为站在现在看起来是机会, 站在当时局限性无法看到的机会而懊悔.

绝大多数时候, 你的命运, 你的生活, 都掌握在自己的手上.

父母朋友等, 或许会给你建议, 但是, 大部分境况, 只有你自己知道, 而且大部分决定, 也只有你自己能做.

美好的细节以及注意力陷阱

生活中有很多美好的细节, 生活也可以过得很精彩.

例如, 今天天气很好, 那就出去浪, 宅在家里干什么. 阳光很好, 就去公园晒个太阳, 看看书, 我一直很喜欢这项老年人运动:) 想运动了, 就去海边跑跑步, 骑骑车; 想买东西就去逛一逛商场;

我们的时间, 大部分被手机, ipad, 以及电脑霸占了.

每天, 都需要这些东西来刺激下神经, 过后有发现什么都没有下, 很空虚.

你可以统计下, 自己每天花多少时间在刷手机, 每周花多少个小时看剧? 不是说这没有用, 娱乐放松还是需要的, 但是目前娱乐内容的丰富性已经超出了我们的想象.

我的做法是, 沉迷-反思-限制; 例如, 我以前每天花一个多小时刷微博, 后来直接卸载一年多, 近期装回来了, 取关了百分之九十的号, 现在每天几分钟看完.

另一个做法, 关掉所有通知, 只根据需要开启必要的应用. 取消所有微信公众号的文章推送, 只关注需要关注的.

仪式感

生活要有仪式感, 不能过程朝九晚久, 五天工作两天休息的死气沉沉的模式化

例如: 周末的开始是周五晚上, 那就每周五晚上找些事情做, 例如电影之夜, 或者海边夜跑……

关于工作

生存, 进步以及自我实现

站在他人的角度上思考问题

每个人的立场不一样.

我们很容易陷入是对是错这种细节. 而往往, 工作中并没有那么绝对, 更多时候, 是是否合适

讨论问题, 提问等等, 多站在对方的角度思考下

另外, 值得一提的是沟通问题, 例如你问一个问题, 该怎么问最好? 如何问沟通效率最高? 如何问对方能100%理解并响应

谦虚, 接受意见反省并改进

谦虚很重要, 你我大部分是普通人, 虽然文人相轻, 但是每个人都有自己的经历, 每个人看待问题的角度并不一样

所以时刻保持谦虚, 才能在工作中同他人更好的相处, 也能更多地学习一些不同领域的好的内容.

接受意见-反省-改进. 这是一个需要关注的问题, 很多时候, 人的惯性是很难纠正的, 一个不好的点, 提过, 短时间内好一点, 但是后面又复发, 这样给合作的的感觉是: 这个人不靠谱.

对就是对, 错就是错, 错了反省, 改进, 然后后面行事多多注意.

多走一步

不要守着自己的一亩三分地, 凡事多往前走一步, 多思考一点, 往往会取得更好的效果.

专业

首先是专业技能一定要到位, 其实是行事作风以及结果要足够靠谱.

树立自己的专业口碑.

偶尔回想, 会想起很多事情, 在北京住过地下室实习的日志, 在杭州每周骑行龙井西湖, 在深圳住过城中村, 往事如烟;

未来还很长, 生活还在继续.

杂七杂八写了一些, 这两年由于各种原因, 博客更新少了, 打算重新拾起来, 多写写一些东西.

就这样吧

2018-07-01 于深圳

[分享]bash日常: bash-utils

Sat, 30 Jun 2018 08:00:00 +0800

早上优化了下自己的一个项目 bash-utils

I always use the bash as my devops script, while it’s boring to write the condition judgement/echo statement/exit. So, I want to make the bash script short and clear. I have collected some useful function into this repo, which save me a lot of time in past few years. Just source the utils.sh and write the expression calling the functions. I can just focus on the logical, not the bash syntax and expression

日常在写一些脚本的时候, 偏好于用bash, 当然, 逻辑太过复杂的时候会用python.

bash相对于python来说, 已经很精简了.

但是, 日常经常做一些逻辑比较重复的自动化任务, 写着写着发现bash这么写还是太冗长了, 而且每次需要重复类似却又不尽相同的动作.

所以, 逐步的, 将一些东西梳理出来了.

目的是, 只要source utils.sh, 就能将注意力集中在业务逻辑上, 而不是bash语法.

往往只需要原先四分之一左右的行数, 搞定逻辑

其实, bash中最多的无非条件判断+字符串处理, 以及我们写脚本需要打印日志. 所以集中将这三块经常做的抽离出函数, 十几个函数, 顶掉80%的工作

有兴趣可以看看, 欢迎提pr

2018-06 深圳

极客时间推广海报

Mon, 18 Jun 2018 08:00:00 +0800

2017总结: 予时光以意义

Sun, 31 Dec 2017 08:00:00 +0800

予时光以意义

我的2017

这句话，算是过去一段时间的一个思考; 最初应该是在看三体“给岁月以文明，而不是给文明以岁月”, 后来偶然间, 在匆匆忙忙后, 闲暇时的一个感悟;

过去的2017, 一如既往地繁忙, 有段时间, 还是陷入了周一到周五的模式, 时间匆匆流逝, 转眼快2018了, 回首一年, 收获良多.

絮絮叨叨, 做一次总结, 坚持了好几年的总结, 前两年断了, 这次看能否续上一续.

关于工作

效率上, 今年又又又对自己的工作流重构了下; 目前全面使用trello看板在管理自己的任务; 买了个实体番茄钟, 严格按照35分钟工作/5分钟休息, 在持续运转, 每天正常7个番茄钟, 火力全开的时候可以到达11个(不过会很累啊…….)

沟通交流上, 变得更淡定了吧, 对于一些突发的变更不会再那么慌乱;

今年对自己做的工作, 大体上只能到70分的样子, 起码没做到优秀;

盯了一个项目, 一年半了, 非常冗长琐碎, 事情比较多, 虽然经历一次次优化和调整, 也算是走上正轨, 但是后期感觉个人精力上占用比较多, 导致没法全面投入去做其他项目, 所以导致总体结果并没有达到自己预定的目标, 几个项目都不错, 但是没有做到最好;

其他几个项目, 涉及业务及基础功能开发, 也都保质保量按时交付, 对很多东西也都有了成体系的了解和实践, 但是还是欠缺深入;

总之一年下来, 逐步地有些缺乏定位, 不知道自己的定位和方向在哪里.

接近年底的时候, 也做了一次重新梳理, 大体确认了后续深入的方向, 也算是一个收获.

明年, 仔细做个规划, 深入去做一些事情, 希望有所改善;  今年尝试开了下知乎专栏, 写一些东西, 然而最终没有坚持下来……博客更新也有限, 主要是刚迈入新的领域, 还没有更深入和深刻的了解, 后面再慢慢来吧.

工作, 占据了生活很大一部分, 起码时间上, 目前会占用很多, 所以很多时候, 要让自己开心, 有快乐地去完成一些事情, 做自己想做的事情.

如何自己充电提升能力, 如何持续优化和改进工作流, 如何愉快的合作, 如何专注工作, 如何按时交付…..这些都是需要在不断的思考和实践中持续前进, 往前走.

关于读书

2017年, 读书相对以前少了很多;

今年书目中多了一项: 经济学; 主要是因为穷, 继去年看了«贫穷的本质»之后, 一月份看了«稀缺», 但是这个书更多的是对个人工作方法论有所帮助, 开始在意工作中各种稀缺, 也学习利用这种稀缺变相提升某种场景下的效率; 经济学另外读了下«穷爸爸富爸爸»/«小岛经济学»/«微观经济学»(在读)/聪明的投资者…….要成体系, 目前还差很多

四月, 补了东野圭吾的«虚无的十字架»和«幻夜», 一如既往地好看, 还有好多后面慢慢读了, 不轻易开启一本, 因为这类小说一读就停不下来;

八月, 在去台湾的旅途中, 开启了«巨人的陨落», 篇幅很长, 多线并行, 整体还不错, 可以一读, 但是没有«平凡的世界»那种厚重感, 更多的是对那个时代的那个情况下的好奇;

技术方面, 七月中旬再次过了一遍«代码大全», 其他时候, 补了三四本容器相关/k8s相关的书, 算是自己在技术方面的一个补充和充电吧.

快要搬家才发现买那么多书的痛苦; 但是依然会持续地买, 因为书真真的很便宜啊;

关于游戏

生活中, 比以前少了一项骑行(可惜了我在墙角落灰的大行 P8), 多了一项打游戏

十一的时候, 入了ps4, 哈哈, 第一次股票操作换得的奖励;

然后, 带着妹子打通Knack, 然后一起分屏打植物大战僵尸, 一个人猥琐地过美国末日, 后来又开新坑, 打神海四;

想起了很小的时候, 打小霸王的日子; 也算是圆了一个梦;

手机这边, 纪念碑谷2第一时间下载通关, 感觉沿袭了经典, 但是没有更多的出彩; 十一的时候, 最后一天跟妹子一人一个手机, 玩To the moon. 直到玩完最后一幕, 也没有太大感伤, 跟妹子交流里面的剧情, 才恍然大悟, 唏嘘不已;

关于生活

2017, 年初的时候, 见了回家长

2017, 年中的时候, 订了个婚

2017, 八月份, 公司outing去了趟台湾,

2017, 快年底的时候, 买了个房, 途中虽然有些波折, 但是最终还是走完流程, 顺利交房;

2017, 快年底的时候, 结了个婚  予时光以意义, 2017, 做了很多事情, 也改变了很多;

首先一个改变, 是从一个大龄单身男青年变成一个已婚人士, 并且步入了法定的中年; 身上的担子和责任更大了, 也需要以不一样的思维去面对这个世界;

其次, 提前开始了中年危机的思考, 危机感更强了, 早几年的时候, 是技术焦虑, 而现在, 变成了定位焦虑, 人总是在不断焦虑中, 从一个阶段进入另一个; 磕磕碰碰, 一路向前;

另外, 年中的时候, 咬咬牙, 彻底戒掉了微博, 改成订阅; 每天刷微博的习惯去掉后, 发现生活其实并不需要信息流的那些刺激, 没了那些, 每天其实可以有更多的时间去做一些有意义的事情;

到十月份的时候, 还在坚持跑步, 虽然已经退化成一个只能跑七八公里的渣渣, 但是毕竟坚持下来了, 体重也得到了很好的控制;

予时光以意义, 时间并不会等你, 你必须一点点往前走, 而这一切时光, 不能虚度;

2017-12-31 于老家

k8s APIServer源码: api注册详细细节

Sat, 23 Sep 2017 15:00:00 +0800

基于版本 1.6.7

前面介绍了, api注册过程

问题: go-restful github的route中, handler和path是如何绑定在一起的? handler在哪里定义的?

以/api为例

前面介绍到/api和/apis分别注册加入到Container, 而最终, 二者调用installer.Install(ws). 这一步, 我们需要进一步了解细节.

webservice.add(route)

问题: 构建Route加入到WebService在哪里处理的?

vendor/k8s.io/apiserver/pkg/endpoints/installer.go

func (a *APIInstaller) Install(ws *restful.WebService) (apiResources []metav1.APIResource, errors []error) {
	// Register the paths in a deterministic (sorted) order to get a deterministic swagger spec.
	paths := make([]string, len(a.group.Storage))
	var i int = 0
	for path := range a.group.Storage {
		paths[i] = path
		i++
	}
	sort.Strings(paths)
	for _, path := range paths {
		apiResource, err := a.registerResourceHandlers(path, a.group.Storage[path], ws, proxyHandler)
	}
}

apiserver/pkg/endpoints/installer.go

仅摘录部分核心代码, 这里, 获取handler之后, 构建route, 然后加入到webservice中

func (a *APIInstaller) registerResourceHandlers(path string, storage rest.Storage, ws *restful.WebService, proxyHandler http.Handler) (*metav1.APIResource, error) {
   ...
	creater, isCreater := storage.(rest.Creater)
	....
	actions = appendIf(actions, action{"POST", resourcePath, resourceParams, namer, false}, isCreater)
	case "POST":

	 // 获取handler
    handler = handlers.CreateResource(creater, reqScope, a.group.Typer, admit) // => next
    // 构建route,  action.Path -> handler
	  route := ws.POST(action.Path).To(handler).
				Doc(doc).
				Param(ws.QueryParameter("pretty", "If 'true', then the output is pretty printed.")).
				Operation("create"+namespaced+kind+strings.Title(subresource)+operationSuffix).
				Produces(append(storageMeta.ProducesMIMETypes(action.Verb), mediaTypes...)...).
				Returns(http.StatusOK, "OK", versionedObject).
				Reads(versionedObject).
				Writes(versionedObject)
		addParams(route, action.Params)
		// 添加route到webservice
		ws.Route(route)
}

create handler

vendor/k8s.io/apiserver/pkg/endpoints/handlers/rest.go

// CreateResource returns a function that will handle a resource creation.
func CreateResource(r rest.Creater, scope RequestScope, typer runtime.ObjectTyper, admit admission.Interface) restful.RouteFunction {
	return createHandler(&namedCreaterAdapter{r}, scope, typer, admit, false)
}

func createHandler(r rest.NamedCreater, scope RequestScope, typer runtime.ObjectTyper, admit admission.Interface, includeName bool) restful.RouteFunction {
	return func(req *restful.Request, res *restful.Response) {
		original := r.New()  // => here
		responsewriters.WriteObject(http.StatusCreated, scope.Kind.GroupVersion(), scope.Serializer, result, w, req.Request)
	}
}

即, 最终handler执行时, 调用的是rest.Creater.New()

这里的 Creater 是一个interface

# vendor/k8s.io/apiserver/pkg/registry/rest/rest.go

// Creater is an object that can create an instance of a RESTful object.
type Creater interface {
	// New returns an empty object that can be used with Create after request data has been put into it.
	// This object must be a pointer type for use with Codec.DecodeInto([]byte, runtime.Object)
	New() runtime.Object

	// Create creates a new version of a resource.
	Create(ctx genericapirequest.Context, obj runtime.Object) (runtime.Object, error)
}

回到最初的问题

最终, handler调用的是rest.Creater.New()

而creater声明的位置

apiserver/pkg/endpoints/installer.go

	creater, isCreater := storage.(rest.Creater)

这里, 想要知道handler最终调用的是哪里定义的方法, 我们需要分析storage的来源

第一步: 链路分析

调用链

// pkg/master/master.go
// => got: apiGroupInfo 初始化
func (m *Master) InstallLegacyAPI(c *Config, restOptionsGetter generic.RESTOptionsGetter, legacyRESTStorageProvider corerest.LegacyRESTStorageProvider) {
	legacyRESTStorage, apiGroupInfo, err := legacyRESTStorageProvider.NewLegacyRESTStorage(restOptionsGetter)
	m.GenericAPIServer.InstallLegacyAPIGroup(genericapiserver.DefaultLegacyAPIPrefix, &apiGroupInfo)
}

// vendor/k8s.io/apiserver/pkg/server/genericapiserver.go
func (s *GenericAPIServer) InstallLegacyAPIGroup(apiPrefix string, apiGroupInfo *APIGroupInfo) error {
    s.installAPIResources(apiPrefix, apiGroupInfo)
}

// vendor/k8s.io/apiserver/pkg/server/genericapiserver.go
// NOTE => apigroup TO apigroupversion
// => got: apigroupversion
func (s *GenericAPIServer) installAPIResources(apiPrefix string, apiGroupInfo *APIGroupInfo) error {
	for _, groupVersion := range apiGroupInfo.GroupMeta.GroupVersions {
		apiGroupVersion := s.getAPIGroupVersion(apiGroupInfo, groupVersion, apiPrefix)
		apiGroupVersion.InstallREST(s.HandlerContainer.Container);	}
}

// vendor/k8s.io/apiserver/pkg/server/genericapiserver.go
// => got: APIGroupVersion.Storage = make(map[string]rest.Storage
//         APIGroupVersion.Storage[path] = apiGroupInfo.VersionedResourcesStorageMap[groupVersion.Version][path]
func (s *GenericAPIServer) getAPIGroupVersion(apiGroupInfo *APIGroupInfo, groupVersion schema.GroupVersion, apiPrefix string) *genericapi.APIGroupVersion {
	storage := make(map[string]rest.Storage)
	for k, v := range apiGroupInfo.VersionedResourcesStorageMap[groupVersion.Version] {
		storage[strings.ToLower(k)] = v
	}
	version := s.newAPIGroupVersion(apiGroupInfo, groupVersion)
	version.Root = apiPrefix
	version.Storage = storage
	return version
}

// vendor/k8s.io/apiserver/pkg/endpoints/groupversion.go
// => got: installer.group = APIGroupVersion
func (g *APIGroupVersion) InstallREST(container *restful.Container) error {
    installer := g.newInstaller()
    installer.Install(ws)
}

func (g *APIGroupVersion) newInstaller() *APIInstaller {
	prefix := path.Join(g.Root, g.GroupVersion.Group, g.GroupVersion.Version)
	installer := &APIInstaller{
		group:             g,           // group = APIGroupVersion
		prefix:            prefix,
		minRequestTimeout: g.MinRequestTimeout,
	}
	return installer
}

// vendor/k8s.io/apiserver/pkg/endpoints/installer.go
// got: a.group.Storage[path] = APIInstaller.group.Storage[path] = APIGroupVersion.Storage[path]
//      APIGroupVersion.Storage[path] = apiGroupInfo.VersionedResourcesStorageMap[groupVersion.Version][path]
func (a *APIInstaller) Install(ws *restful.WebService) (apiResources []metav1.APIResource, errors []error) {
	// Register the paths in a deterministic (sorted) order to get a deterministic swagger spec.
	paths := make([]string, len(a.group.Storage))
	var i int = 0
	for path := range a.group.Storage {
		paths[i] = path
		i++
	}
	sort.Strings(paths)
	for _, path := range paths {
		apiResource, err := a.registerResourceHandlers(path, a.group.Storage[path], ws, proxyHandler)
	}
}

// apiserver/pkg/endpoints/installer.go
// got: storage = apiGroupInfo.VersionedResourcesStorageMap[groupVersion.Version][path]
func (a *APIInstaller) registerResourceHandlers(path string, storage rest.Storage, ws *restful.WebService, proxyHandler http.Handler) (*metav1.APIResource, error) {

	creater, isCreater := storage.(rest.Creater)
}

到了这里, 其实有了一个清晰的结论

// apiGroupInfo.VersionedResourcesStorageMap
storage = apiGroupInfo.VersionedResourcesStorageMap[groupVersion.Version][path]
creater, isCreater := storage.(rest.Creater)

此时, 我们再反向寻找apiGroupInfo初始化的位置

第二步: apiGroupInfo 初始化

pkg/master/master.go

func (m *Master) InstallLegacyAPI(c *Config, restOptionsGetter generic.RESTOptionsGetter, legacyRESTStorageProvider corerest.LegacyRESTStorageProvider) {
	legacyRESTStorage, apiGroupInfo, err := legacyRESTStorageProvider.NewLegacyRESTStorage(restOptionsGetter) // => next
	m.GenericAPIServer.InstallLegacyAPIGroup(genericapiserver.DefaultLegacyAPIPrefix, &apiGroupInfo)
}

pkg/registry/core/rest/storage_core.go

func (c LegacyRESTStorageProvider) NewLegacyRESTStorage(restOptionsGetter generic.RESTOptionsGetter) (LegacyRESTStorage, genericapiserver.APIGroupInfo, error) {
  // 初始化: VersionedResourcesStorageMap
	apiGroupInfo := genericapiserver.APIGroupInfo{
		GroupMeta:                    *api.Registry.GroupOrDie(api.GroupName),
		VersionedResourcesStorageMap: map[string]map[string]rest.Storage{},
		Scheme:                      api.Scheme,
		ParameterCodec:              api.ParameterCodec,
		NegotiatedSerializer:        api.Codecs,
		SubresourceGroupVersionKind: map[string]schema.GroupVersionKind{},
	}
	// ......

	// 初始化了一个restStorage的map，然后赋值给APIGroupInfo.VersionedResourcesStorageMap["v1"]
	restStorageMap := map[string]rest.Storage{
		"pods":             podStorage.Pod,
		"pods/attach":      podStorage.Attach,
		"pods/status":      podStorage.Status,
		"services":        serviceRest.Service,
		"nodes":        nodeStorage.Node,
		.....
	}

	apiGroupInfo.VersionedResourcesStorageMap["v1"] = restStorageMap

	return restStorage, apiGroupInfo, nil
}

即

apiGroupInfo.VersionedResourcesStorageMap["v1"] = map[string]rest.Storage{
		"pods":             podStorage.Pod,
		"pods/attach":      podStorage.Attach,
		"pods/status":      podStorage.Status,
		"services":        serviceRest.Service,
		"nodes":        nodeStorage.Node,
		.....
	}

此时, 根据

// apiGroupInfo.VersionedResourcesStorageMap
storage = apiGroupInfo.VersionedResourcesStorageMap[groupVersion.Version][path]
creater, isCreater := storage.(rest.Creater)

我们可以得到

storage = apiGroupInfo.VersionedResourcesStorageMap["v1"]["pods"]
// equals
storage = podStorage.Pod
creater, isCreater := (podStorage.Pod).(rest.Creater)

然后, 我们再看下podStorage.Pod的实现

第三步: podStorage.Pod

pkg/registry/core/pod/storage/storage.go

type PodStorage struct {
	Pod         *REST
  ...
}

// REST implements a RESTStorage for pods
type REST struct {
	*genericregistry.Store     // => NOTE
	proxyTransport http.RoundTripper
}

即, PodStorage.Pod 类型是 REST, 而REST.genericregistry.Store, 其定义文件中存在

vendor/k8s.io/apiserver/pkg/registry/generic/registry/store.go

// New implements RESTStorage.New.
func (e *Store) New() runtime.Object {
	return e.NewFunc()
}

func (e *Store) Create(ctx genericapirequest.Context, obj runtime.Object) (runtime.Object, error) {
}

即,

storage = apiGroupInfo.VersionedResourcesStorageMap["v1"]["pods"]
// equals
storage = podStorage.Pod
creater, isCreater := (podStorage.Pod).(rest.Creater)

// equals
creater, isCreater := (REST).(rest.Creater)
creater, isCreater := (*genericregistry.Store).(rest.Creater)

第四步: creater.New()

vendor/k8s.io/apiserver/pkg/registry/generic/registry/store.go

// New implements RESTStorage.New.
func (e *Store) New() runtime.Object {
	return e.NewFunc()
}

pkg/registry/core/pod/storage/storage.go

func NewStorage(optsGetter generic.RESTOptionsGetter, k client.ConnectionInfoGetter, proxyTransport http.RoundTripper, podDisruptionBudgetClient policyclient.PodDisruptionBudgetsGetter) PodStorage {

	store := &genericregistry.Store{
		NewFunc:     func() runtime.Object { return &api.Pod{} },
		....
	}
}

// pkg/api/types.go
type Pod struct {
	metav1.TypeMeta
	// +optional
	metav1.ObjectMeta

	// Spec defines the behavior of a pod.
	// +optional
	Spec PodSpec

	// Status represents the current information about a pod. This data may not be up
	// to date.
	// +optional
	Status PodStatus
}

etcd相关的, 在后面介绍

k8s APIServer源码: api注册主体流程

Sat, 23 Sep 2017 14:00:00 +0800

基于版本 1.6.7

k8s使用了go-restful github, 在前面, 已经介绍了container如何初始化的.

这里, 需要关注, api是如何注册进来的. 即, route -> webservice -> container

begin

pkg/master/master.go

func (c completedConfig) New() (*Master, error) {

   //  register /api
   m.InstallLegacyAPI(c.Config, c.Config.GenericConfig.RESTOptionsGetter, legacyRESTStorageProvider)
   //  register /apis
   m.InstallAPIs(c.Config.APIResourceConfigSource, c.Config.GenericConfig.RESTOptionsGetter, restStorageProviders...)
}

1. /api

pkg/master/master.go

func (m *Master) InstallLegacyAPI(c *Config, restOptionsGetter generic.RESTOptionsGetter, legacyRESTStorageProvider corerest.LegacyRESTStorageProvider) {
    legacyRESTStorage, apiGroupInfo, err := legacyRESTStorageProvider.NewLegacyRESTStorage(restOptionsGetter)
    m.GenericAPIServer.InstallLegacyAPIGroup(genericapiserver.DefaultLegacyAPIPrefix, &apiGroupInfo)

vendor/k8s.io/apiserver/pkg/server/genericapiserver.go

func (s *GenericAPIServer) InstallLegacyAPIGroup(apiPrefix string, apiGroupInfo *APIGroupInfo) error {
    s.installAPIResources(apiPrefix, apiGroupInfo)
}

2. /apis

pkg/master/master.go

func (m *Master) InstallAPIs(apiResourceConfigSource serverstorage.APIResourceConfigSource, restOptionsGetter generic.RESTOptionsGetter, restStorageProviders ...RESTStorageProvider) {
	for i := range apiGroupsInfo {
		m.GenericAPIServer.InstallAPIGroup(&apiGroupsInfo[i])	}
}

vendor/k8s.io/apiserver/pkg/server/genericapiserver.go

func (s *GenericAPIServer) InstallAPIGroup(apiGroupInfo *APIGroupInfo) error {
    s.installAPIResources(APIGroupPrefix, apiGroupInfo)
}

3. all to installAPIResources

vendor/k8s.io/apiserver/pkg/server/genericapiserver.go

func (s *GenericAPIServer) installAPIResources(apiPrefix string, apiGroupInfo *APIGroupInfo) error {
	for _, groupVersion := range apiGroupInfo.GroupMeta.GroupVersions {
		apiGroupVersion.InstallREST(s.HandlerContainer.Container)
	}
}

vendor/k8s.io/apiserver/pkg/endpoints/groupversion.go

func (g *APIGroupVersion) InstallREST(container *restful.Container) error {
	installer := g.newInstaller()
	// 新建一个WebService
	ws := installer.NewWebService()

	// 关键, URL注册, add router into ws
	apiResources, registrationErrors := installer.Install(ws)
	lister := g.ResourceLister
	if lister == nil {
		lister = staticLister{apiResources}
	}
	AddSupportedResourcesWebService(g.Serializer, ws, g.GroupVersion, lister)

	// container.add(webservice)
	container.Add(ws)
	return utilerrors.NewAggregate(registrationErrors)
}

在这里

新建一个WebService
由installer.Install(ws)将API 对应的route新建初始化后, 加入到 WebService
将WebService加入到Container

完成了router -> webservice -> container的流程

后面, 分析 installer.Install(ws) 具体做了哪些事情(vendor/k8s.io/apiserver/pkg/endpoints/installer.go)

k8s APIServer源码: 服务启动

Sat, 23 Sep 2017 13:00:00 +0800

基于版本 1.6.7

启动流程

cmd/kube-apiserver/apiserver.go

func main() {
   app.Run(s)
}

cmd/kube-apiserver/app/server.go

func Run(s *options.ServerRunOptions) error {
	// 构建master配置信息
	config, sharedInformers, err := BuildMasterConfig(s)
	// 调用RunServer
	return RunServer(config, sharedInformers, wait.NeverStop)
}

func RunServer(config *master.Config, sharedInformers informers.SharedInformerFactory, stopCh <-chan struct{}) error {
	// 执行相关初始化
	m, err := config.Complete().New()     // => TO: Container初始化
	// 启动
	return m.GenericAPIServer.PrepareRun().Run(stopCh)  // => next
}

vendor/k8s.io/apiserver/pkg/server/genericapiserver.go

启动主体函数都在这个文件中, 绑定地址/端口号, 并最终启动

func (s preparedGenericAPIServer) Run(stopCh <-chan struct{}) error {
	s.NonBlockingRun(stopCh)
}

func (s preparedGenericAPIServer) NonBlockingRun(stopCh <-chan struct{}) error {
	s.serveSecurely(internalStopCh)
	// or
	s.serveInsecurely(internalStopCh) // => next
}

vendor/k8s.io/apiserver/pkg/server/serve.go

func (s *GenericAPIServer) serveInsecurely(stopCh <-chan struct{}) error {
	insecureServer := &http.Server{
		Addr:           s.InsecureServingInfo.BindAddress,
		Handler:        s.InsecureHandler,   // s.Hnalder for secure
		MaxHeaderBytes: 1 << 20,
	}
   runServer(insecureServer, s.InsecureServingInfo.BindNetwork, stopCh) // => next
}


func runServer(server *http.Server, network string, stopCh <-chan struct{}) (int, error) {
	go func() {
		for {
			var listener net.Listener
			listener = tcpKeepAliveListener{ln.(*net.TCPListener)}
			// *http.Server
			err := server.Serve(listener)
			}
	}()
}

Container初始化

cmd/kube-apiserver/app/server.go

func RunServer(config *master.Config, sharedInformers informers.SharedInformerFactory, stopCh <-chan struct{}) error {
	// 执行相关初始化
	m, err := config.Complete().New()     // => TO: Container初始化
	// 启动
	return m.GenericAPIServer.PrepareRun().Run(stopCh)  // => next
}

kubernetes/pkg/master/master.go

func (c completedConfig) New() (*Master, error) {
   // m.GenericAPIServer.HandlerContainer = APIContainer,   APIContainer.Container =  restful.NewContainer()
	s, err := c.Config.GenericConfig.SkipComplete().New() // completion is done in Complete, no need for a second time
   m := &Master{
		GenericAPIServer: s,
	}
}

vendor/k8s.io/apiserver/pkg/server/config.go

到这里, 完成了 s.Handler, s.InsecureHandler 的初始化

func (c completedConfig) New() (*GenericAPIServer, error) {
  s := &GenericAPIServer{
  }
  // s.HandlerContainer = APIContainer
  	s.HandlerContainer = mux.NewAPIContainer(http.NewServeMux(), c.Serializer)  // => next 1

  // 生成 Handler
  	s.Handler, s.InsecureHandler = c.BuildHandlerChainsFunc(s.HandlerContainer.ServeMux, c.Config)  // => next 2
}

1: vendor/k8s.io/apiserver/pkg/server/mux/container.go

新建一个APIContainer, 包含

// NewAPIContainer constructs a new container for APIs
func NewAPIContainer(mux *http.ServeMux, s runtime.NegotiatedSerializer) *APIContainer {
	c := APIContainer{
		// 新建一个Container
		Container: restful.NewContainer(),
		NonSwaggerRoutes: PathRecorderMux{
			mux: mux,
		},
		UnlistedRoutes: mux,
	}
	// 配置 http.ServerMux
	c.Container.ServeMux = mux
	// 配置路由方式, 使用CurlyRouter
	c.Container.Router(restful.CurlyRouter{}) // e.g. for proxy/{kind}/{name}/{*}
	return &c
}

2: vendor/k8s.io/apiserver/pkg/server/config.go

type Config struct {
	BuildHandlerChainsFunc func(apiHandler http.Handler, c *Config) (secure, insecure http.Handler)
}


func NewConfig() *Config {
	return &Config{
			BuildHandlerChainsFunc:      DefaultBuildHandlerChain,
	}
}


func DefaultBuildHandlerChain(apiHandler http.Handler, c *Config) (secure, insecure http.Handler) {
	return generic(protect(apiHandler)), generic(audit(apiHandler)) // add filters to handler
}

注意, 这里传递的参数是: s.HandlerContainer.ServeMux, DefaultBuildHandlerChain的参数是apiHandler http.Handler, 前者包含后者interface定义的方法.

net/http/server.go

type Handler interface {
        ServeHTTP(ResponseWriter, *Request)
}

// ServeHTTP dispatches the request to the handler whose
// pattern most closely matches the request URL.
func (mux *ServeMux) ServeHTTP(w ResponseWriter, r *Request) {
	if r.RequestURI == "*" {
		if r.ProtoAtLeast(1, 1) {
			w.Header().Set("Connection", "close")
		}
		w.WriteHeader(StatusBadRequest)
		return
	}
	h, _ := mux.Handler(r)
	h.ServeHTTP(w, r)
}

初始化后, Hnalder 以及 InsecureHandler赋值Container, 然后在new Server前, 将handler放入

&http.Server{
		Addr:           s.InsecureServingInfo.BindAddress,
		Handler:        s.InsecureHandler,   // s.Hanlder for secure
		MaxHeaderBytes: 1 << 20,
}

k8s APIServer源码: go-restful框架

Sat, 23 Sep 2017 12:00:00 +0800

基于版本 1.6.7

k8s的APIServer, 使用了go-restful作为其处理框架, 注册资源并接收处理 HTTP 请求.

在阅读APIServer源码之前, 需先理解go-restful主要概念.

intro

package for building REST-style Web Services using Google Go

go-restful github

concepts

Container: 一组WebService的集合, 目的: Containers for WebServices on different HTTP endpoints.
WebService: Route的集合; 为一组Route定义统一的 root path / 请求类型 / 响应类型
Route: 定义method/ULR path/调用函数/文档/参数/ curly route; 支持正则及动态谭树
Filter: Filters for intercepting the request → response flow on Service or Route level, 可以加global / Webservice / Route 各自的filter

init steps:

create container
create resource WebService

define route, path, filter and bind to route handler

```
add router to WebService
```
add WebService to container
new server with Handler=container
start server

examples

示例1: use default containers

ws := new(restful.WebService)
ws.
	Path("/users").
	Consumes(restful.MIME_XML, restful.MIME_JSON).
	Produces(restful.MIME_JSON, restful.MIME_XML)

ws.Route(ws.GET("/{user-id}").To(u.findUser).
	Doc("get a user").
	Param(ws.PathParameter("user-id", "identifier of the user").DataType("string")).
	Writes(User{}))
...

func (u UserResource) findUser(request *restful.Request, response *restful.Response) {
	id := request.PathParameter("user-id")
	...
}

示例2: 含多个container

// https://github.com/emicklei/go-restful/blob/master/examples/restful-multi-containers.go
// GET http://localhost:8080/hello
// GET http://localhost:8081/hello
package main

import (
	"github.com/emicklei/go-restful"
	"io"
	"log"
	"net/http"
)

func main() {
  // add to default container
	ws := new(restful.WebService)
	ws.Route(ws.GET("/hello").To(hello))
	restful.Add(ws)
	go func() {
		log.Fatal(http.ListenAndServe(":8080", nil))
	}()

  // container 2
	container2 := restful.NewContainer()
	ws2 := new(restful.WebService)
	ws2.Route(ws2.GET("/hello").To(hello2))
	container2.Add(ws2)
	server := &http.Server{Addr: ":8081", Handler: container2}
	log.Fatal(server.ListenAndServe())
}

func hello(req *restful.Request, resp *restful.Response) {
	io.WriteString(resp, "default world")
}

func hello2(req *restful.Request, resp *restful.Response) {
	io.WriteString(resp, "second world")
}

示例3: 包含 filter

// filter https://github.com/emicklei/go-restful/blob/master/examples/restful-filters.go
// Global Filter
func globalLogging(req *restful.Request, resp *restful.Response, chain *restful.FilterChain) {
	log.Printf("[global-filter (logger)] %s,%s\n", req.Request.Method, req.Request.URL)
	chain.ProcessFilter(req, resp)
}

func main() {
	// install a global (=DefaultContainer) filter (processed before any webservice in the DefaultContainer)
	restful.Filter(globalLogging)

	restful.Add(NewUserService())
	log.Print("start listening on localhost:8080")
	log.Fatal(http.ListenAndServe(":8080", nil))
}


func NewUserService() *restful.WebService {
	ws := new(restful.WebService)
	ws.
		Path("/users").
		Consumes(restful.MIME_XML, restful.MIME_JSON).
		Produces(restful.MIME_JSON, restful.MIME_XML)

	// install a webservice filter (processed before any route)
	ws.Filter(webserviceLogging).Filter(measureTime)

	// install a counter filter
	ws.Route(ws.GET("").Filter(NewCountFilter().routeCounter).To(getAllUsers))

	// install 2 chained route filters (processed before calling findUser)
	ws.Route(ws.GET("/{user-id}").Filter(routeLogging).Filter(NewCountFilter().routeCounter).To(findUser))
	return ws
}

reference

重构 - 读书笔记(Python示例)

Sat, 17 Jun 2017 23:39:00 +0800

去年十二月, 重读时, 输出了几篇博文, 主要几章重构技巧梳理 6/7/8/9/10/11, 这周重读时, 从另一个角度总结一下

我们总是想着, 找个时间重构, 额, 其实, 重构更应该放在平时, 每一次去变更代码时处理. 毕竟, 所谓的重构契机有时候太过遥远; 而如果不做重构, 痛苦的是每时每刻维护代码的自己

如果你发现自己需要为程序添加一个特性, 而代码结构使你无法很方便地达成目的, 那就先重构那个程序, 使特性的添加比较容易进行, 然后再添加特性

另外, 如果可能, 尽量加单元测试, 哪怕一次只增加一两个, 一段时间后, 你会发现, 你会感谢过去的自己

原则

小步前进, 频繁测试
隔离变化
控制可见范围, 让变量/常量/函数/类等, 在最小的范围内可见. 例如设为私有变量/私有函数, 移除不必要的设值函数
重构时, 不要关注性能. 到性能优化阶段, 再关注性能. 不同阶段关注点不一样, 不要过早优化. 很多时候, 性能并不是瓶颈, 可读性和可维护性更重要
任何时候, 都不要拷贝代码, 拷贝类, 甚至拷贝源码文件

1. 命名

好的名字, 清晰表达其含义. 命名至关重要
好的代码应该清楚表达出自己的功能, 变量名称是代码清晰的关键
如果为了提高代码的可读性, 需要修改某些名字, 大胆去改!
IDE/单元测试/好的查找替换工具
建议读编写可读代码的艺术这本书.

2. 常量和临时变量

提取常量

你有一个字面数值, 带有特别含义. 创建一个常量, 根据其意义为它命名, 并将上述字面数值替换为这个常量

def potential_energy(mass, height):
    return mass * 9.81 * height

GRAVITATIONAL_CONSTANT = 9.81
def potential_energy(mass, height):
    return mass * GRAVITATIONAL_CONSTANT * height

任何时候, 都不要拷贝常量, 当你发现要改一个数据, 要到非常多的文件去改字面值时, 你就需要意识到, 该提取常量了

加入: 引入解释性变量

一个复杂的表达式, 将复杂表达式或其中一部分放入临时变量, 以变量名称来解释表达式用途

if "MAC" in platform.upper() and "IE" in browser.upper() and was_initialized() and resize > 0:
    #do something


is_macos = "MAC" in platform.upper()
is_ie_browser = "IE" in browser.upper()
was_resized = resize > 0

if is_macos and is_ie_browser and was_initialized() and was_resized:
    # do something

分解: 分解临时变量

某个临时变量被赋值超过一次, 非循环变量, 也不用于收集计算结果.每次赋值, 创砸一个独立, 对应的临时变量

单一职责原则

tmp = 2 * (height * width)
print tmp

tmp = height * width
print tmp

perimeter = 2 * (height * width)
print perimeter

area = height * width
print area

去除: 移除临时变量

临时变量仅被一个简单表达式赋值一次, 可以去除这个临时变量

临时变量, 简单表达式, 另外, 需要考虑使用次数, 如果仅使用一次, 可以去除, 如果多次, 则需谨慎考虑对可读性的而影响

best_price = order.base_price()
return best_price > 1000

return order.base_price > 1000

移除: 控制标记

在一系列布尔表达式中, 某个变量带有"控制标记"(control flag)的作用. 以break语句或return取代控制标记

def dosomething():
    is_success = False
    if xxx:
       is_success = True

    if yyy:
       is_success = False
    ...
    return is_success

def dosomething():
    if xxx:
        return True

    if yyy:
        return True
    ...
    return False # 一定不要忘记

注意力相关.

这类逻辑中, 很痛苦的是, 你必须无时无刻关注这些控制标记的值, 追踪变量在每一个逻辑之后的变化, 会带来额外的思考负担, 从而让代码变得不易读.

3. 函数

拆分: Extract Method提炼函数

你有一段代码可以被组织在一起并独立出来, 将这段代码放进一个独立函数中, 并让函数名称解释该函数的用途

def print_owing(double amount):
    print_banner()

    // print details
    print "this is the detail: "
    print "amnount: %s" % amount

def print_details(amount):
    print "this is the detail: "
    print "amnount: %s" % amount

def print_owing(double amount):
    print_banner()
    print_details(amount)

去除: Inline Method内联函数

一个函数的本体与名称同样清楚易懂, 在函数调用点插入函数本体, 然后移除该函数

小型函数, 函数太过简单了, 可能只有一个表达式, 去除函数!

def is_length_valid(x):
    return len(x) > 10

print 'the length is %s' % ('valid' if is_length_valid(x) else 'invalid')

print 'the length is %s' % ('valid' if len(x) > 10 else 'invalid)

合并: 合并多个函数, 使用参数

若干函数做了类似的工作. 但在函数本体中却包含了不同的值. 建立单一函数, 以参数表达那些不同的值

def five_percent_raise():
    pass
def ten_percent_raise():
    pass

def percent_raise(percent):
    pass

副作用: 函数不应该有副作用

某个函数既返回对象状态值, 又修改对象状态. 建立两个不同函数, 一个负责查询, 一个负责修改.

单一职责原则, 一个函数不应该做两件事, 函数粒度尽量小.

4. 表达式

guard(注意力相关)

过多的条件逻辑, 难以理解正常的执行路径. 在python中的特征是, 缩进太深

coolshell中曾经讨论过的问题如何重构“箭头型”代码, 而在python中的现象是, 缩进嵌套层级太深, 有时候甚至有十几层缩进, 整体难以理解

而减少嵌套缩进的方式是, 使用guard语句, 尽早返回,

注意力相关, 尽早return, 你也就不用关心已经过去的逻辑了, 只需关注后面代码的逻辑.

if _is_dead:
    result = dead_amount()
else:
    if _is_separated:
        result = separated_amount()
    else:
        if _is_retired:
            result = retired_amount()
        else:
            result = normal_payamount()
return result

if _is_dead:
    return dead_amount()

if _is_separated:
    return separated_amount()

if _is_retired:
    return retired_amount()

return normal_payamount()

合并: 合并条件表达式

你有一系列条件测试, 都得到相同结果. 将这些测试合并成一个条件表达式, 并将这个条件表达式提炼成为一个独立函数

if _seniority < 2:
    return 0
if _months_disabled > 10:
    return 0
if _is_part_time:
    return 0

if is_not_eligible_for_disability:
    return 0

分解: 分解复杂条件表达式

你有一个复杂的条件语句(if-then-else). 从if, the, else三个段落中分别提炼出独立函数

if date < SUMMER_START) or date > SUMMER_END:
    charge = quantity * _winter_rate + _winter_servioce_charge
else:
    charge = quantity * _summer_rate

if not_summber(date):
    charge = winter_charge(quantity)
else:
    charge = summber_charge(quantity)

提取: 合并重复的条件片段

在条件表达式的每个分支上有着相同的一段代码. 将这段重复代码搬移到条件表达式之外

if is_special:
    total = price * 0.95
    send()
else:
    total = price * 0.98
    send()


if is_special:
    total = price * 0.95
else:
    total = price * 0.98
send()

这是维护系统, 特别是中后期很容易忽略的问题. 很容易在代码中出现, 特别是遇到那种加需求的地方, 通常, 会选择不动原来的代码, 加个分支, 复制代码下来改. 但这样的后果是, 逐步地, 会发现每个分支中都有重复代码.

5. 参数及返回值

参数和返回值: 提取对象

如果参数/返回值是一组相关的数值, 且总是一起出现, 可以考虑提取成一个对象.

def get_width_height():
    ....

    return width, height

def get_area(width, height):
    return width, height

class Rectangle(object):
    def __init__(self, width, height):
        self.width = width
        self.height = height

    def area(self):
        return self.width * self.height

def get_shape():
    ....
    return Rectangle(height, width)

类似的还有: start_time/end_time -> TimeRange /

减少参数

对象调用了某个函数, 并将所得结果作为参数, 传递给另一个函数. 而接受该参数的函数本身也能调用前一个函数. 让参数接收者去除该参数, 并直接调用前一个函数

base_price = quantity * item_price
discount_level = get_discount_level()
final_price = discounted_price(base_price, discount_level)

base_price = quantity * item_price
final_price = discounted_price(base_price)

6. 类

搬移: 函数/字段

搬移函数: 某个函数与所在类之外的另一个类有更多的交互, 调用或被调用(例如: 使用另一个对象的次数比使用自己所在对象的次数还多). 即, 跟另一个类更相关. 则搬移过去
搬移字段: 某个字段被其所在类之外的另一个类更多地用到

拆分: 拆分类

某个类做了应该由两个类做的事. 类太大/太臃肿. 建立一个新类, 将相关字段和函数从旧类版移到新类

特征: 类中某些字段是有关系的整体, 或者有相同的前缀

class Persion(object):
    def __init__(self, name, age, office_area_code, office_number):
        self.name = name
        self.age = age
        self.office_area_code = office_area_code
        self.office_number = office_number
    def get_phone_number(self):
        return "%s-%s" % (self.office_area_code, self.office_number)

class Person(object):
    def __init__(self, name, age, office_area_code, office_number):
        self.name = name
        self.age = age
        self.phone_number = PhoneNumber(office_area_code, office_number)

    def get_phone_number(self):
        return self.phone_number.get_number()

class PhoneNumber(object):
    def __init__(self, area_code ,number):
        self.area_code = area_code
        self.number = number
    def get_number(self):
        return "%s-%s" % (self.area_code, self.number)

去除

一个类没有做太多的事情, 不再有独立存在的理由.

7. 模式

原则:

慎用
只使用你理解的模式
只在符合的业务场景使用对应模式

adapter

你需要为提供服务的类增加功能, 但是你无法修改这个类.

使用组合(推荐, 持有对象)/继承(加子类), 持有该对象, 增加对应附加功能

adapter思维.

使用场景: 使用一些第三方库处理外部依赖, 例如依赖一个系统, 业务A(requests)/es(Elasticsearch)/redis(redispy), 但是, 基于第三方系统, 你需要有自己业务相关的统一处理逻辑, 此时, 你可以建立一个XXClient, 持有第三方组件底层调用逻辑, 同时封装自身业务逻辑, 在上层直接调用

facade

适配模式中举的例子, 也有facade的思想, 将复杂的东西, 统一封装, 对外提供相对简单清晰地接口

template method

出现的次数也很高

装饰器

python中最常用

其他

根据使用场景, 应用策略/桥梁/工厂/观察者等等, 具体看业务场景

举例

重构一个相对较大的django项目

明确业务对象, 对象概念, 对象边界
明确分层
明确代码目录结构, 划分模块, 明确每个模块可以放入的东西
粗粒度重构: 移动模块/类/函数, 根据前几步的划分, 将模块/类/函数等, 移动到对应模块中, 同时, 修改import和调用点
中粒度重构: 根据django项目本身划分, 移动函数
中粒度重构: Extract Method. 读具体函数代码, 遇到 重复代码 / 过长函数 / 过大的类 / 超大的if-else或switch / 包含大段注释的代码 等, 思考, 提炼函数, 放入对应模块
细粒度重构: 提取常量 / 提取枚举 / 修改模块名类名函数名变量名

举例:

对于django项目, 原则fat models, helper modules, thin views, stupid templates
fat model, 将对象本身相关的, 尽量放入models, 这个对象相关的, 可以加入补充一系列porperty/classmethod/staticmethod, 可以有效地降低使用这个对象时调用处的代码复杂度. 例如, 每次取兑现改一个字段都需要进行转换, 则搞个property替换每次都需要的转换逻辑. (找拿到model对象后的处理逻辑代码中那些反复出现的, 重复的)
将对象查询相关的, 全部迁移到manager中, 需要先通过Model.objects查询然后做各种事情的, 迁移放入到manager中
utils, 将业务逻辑无关的工具函数等, 统一归入utils模块中; 将业务有关但多个application共用的utils放入到common.utils模块中, 而将appication依赖的局部utils, 放入到application.utils中
constants, 同上, 区分通用, 还是某个applications中使用
thin view, 业务逻辑, 尽量瘦小简短
stupid template, 模板, 尽量傻瓜, 不要包含复杂计算/判断逻辑, 将复杂迁移到后端代码

其他

善用工具, 有方案设计评审, 平时通过pull request, 走code review, 有代码风格自动检查, 要求单元测试, 走cicd流程. 在平时, 就有意识地控制代码质量

写给新人的沟通建议

Sun, 09 Apr 2017 08:00:00 +0800

最近也碰上抄袭的号, 转了我几年前两个文章, 只改了标题, 然后删掉每篇文章中我个人的一两段吐槽, 然后发出来. 抄袭当原创, 然后在评论里以作者的角度回复别人, 看着有点恶心. 这种成本还是太低了, 举报两次, 知乎给删掉了, 但是对于我来说还是很不爽的, 举报的成本太高了, 来一篇举报一篇. 这个号下面的文章(入口), 目测都是直接用别人的文章改个标题了事.

很多年前写过一篇在自己博客里面, 后端不高兴——关于协作和沟通, 做后端的同学可以看看吐槽哈.

工作也好多年了, 前前后后跟不少新人合作过, 实际合作中不免各种问题, 都是从新人过来的, 所以打算写一些点, 算是一些感受吧

关于问题描述

好像之前有人也讲过.

不要发: hi, 在吗, 你可能会发现过了很久对方回复:在, 然后你可能也没立即接下一句, 晚一会回复:xxxx问题, 然后对方又隔了很长一段时间才回….如此来来往往, 一次沟通跨度从一两个小时到好几天

一般新人会觉得心累, 有点玻璃心的会觉得委屈, 如果事情紧急, 光自己干着急了.

其实老鸟也很累, 一般事情比较多, 各种事情混在一起, 面对这种类型沟通, 无法获取足够多的信息, 自然无法快速解决. 其实心里也想事情快速处理掉.

这种有点类似打乒乓球的沟通方式是不对的. 每次没有提供足够的信息, 而又期待对方快速反馈, 然而每个人都有自己忙碌的事情, 势必导致这类沟通十分之低效.

正确的沟通方式应该是: 倾倒式的沟通.

hi xxxx:
我是xxxxx
目前遇到一个问题
现象
数据
结果

这个问题是xxxxxx?

而对方在看到你的消息后, 一次性就可以全面了解你的问题, 了然于胸, 很快就能解决问题.

而区别是: 一次传达的有效信息量.

如何问题

建议不管是新手还是老鸟, 都读一读提问的智慧

实际上, 有些时候某些问题看起来十分的无奈

- 系统挂了       -- 一脸懵逼, 什么系统
- 接口返回错误   -- excuse me? 哪个接口? 给的参数是? 返回结果/状态码是?
- 页面有点问题   -- 哪个页面? 什么问题?

......

很是无奈, 很多问题看起来言简意赅, 但是蛋疼的也是这个, 缺乏信息量, 缺乏对问题的准确描述, 往往站在信息接收人的角度是: 一脸懵逼. 然后, 就开始来来往往的沟通

所以: 如何准确描述问题, 算是提问的基本要求了

基础问题不要问

基础问题, 例如某些库的方法/参数, http状态码, 某个异常堆栈信息.

很多时候, 拿这类问题去问别人, 是十分低效且有害的!

因为: 这个时代, 搜索引擎这么强大, 技术资料如此丰富, 各类社区如此多前人踩坑, 团队的wiki如此完善, 你还拿一个如此基础的问题去问别人, 似乎说不过去吧.

只要是搜索引擎能回答的就别问别人……

也不是说不能问, 但是前提是, 自己搜索无果, 无法解决的情况下.(google, 且会基本搜索技巧)

这类问题, 看起来很简单是吧, 对其他人也许也就一句话的事情, 但是, 这样造成不好的结果是, 对方被你打断了! 无论多短暂, 都是打断, 断点-思考-回答-回到断点.

因为回答你一个本可以自己解决的问题, 而手头正在做的事情被打断.

而这个, 对效率影响是非常大的.

所以, 忠告: 不要把同事当做搜索引擎, 尊重对方.

遇到问题, 先从自己查起

很多人遇到问题后, 第一意识是, 我的代码是ok的, 你的接口有问题.

然后, 直接抛给对方(对方大写懵逼)

而此时, 对方心里肯定第一意识也是: 我的代码是ok的, 一定不是我的问题. 此时心态上会有些变化, 然后去确认接口是不是有问题, 如果有问题也就罢了, 没问题会反向再反馈回来, 自己排查.

而很多时候, 要么没看文档, 没配host, 配错host, 环境不对, 没有遵循协议, 参数传错等等一系列自己代码的低级错误导致的.

也许这都是小事, 但当次数多了, 而大多数问题不是对方问题时, 你的信誉点已经降到了最低, 你的任何问题反馈, 无形中会被降级.

想象一下, 有人说你接口有问题, 然后你确认服务没问题(几分钟), 找对方要参数数据复现没问题(十几分钟), 然后到对方电脑查问题(几分钟), 一折腾半个多小时没了. 最后发现是一个低级问题(例如没配host), 你心里…..

所以, 先确认错误, 排查下是否是自己的问题

不要胡乱猜测, 拿数据说话

接上个问题, 当你认为别人系统有问题时, 请拿数据说话. 当别人认为你系统有问题的时候, 请对方提供数据.

发现自己在跟人沟通时, 问的最多的问题是: 把调用的接口/参数/返回值/状态码/日志等等, 发给我, 谢谢.

发现有问题, 不要猜, 代码是确定的, 查就是了.

当看到报错, 从上往下查, 一层层向下跟踪, 确认输入/输出/异常/状态码等. 学会追踪调用是必备技能.

有足够的数据才能断定是哪的问题

如果是自己的问题, 修正.

如果是别人的问题, 拿着数据, 也方便别人定位问题.

特别忌讳的是: 没有数据的情况下, 猜测, 然后把问题抛出去了, 会造成组织效率低下, 可能你一个小小猜测, 花费别人很多时间. 每个人的时间都需要尊重.

该问就问, 不要害怕打断

基于上面的几点, 假设问题自己没法解决, 需要求助, 那就求助吧.

不要害怕打扰别人, 一般程序员都很nice, 有问题, 把问题准备好, 精确描述, 自己的尝试, 目前遇到的点等等, 将信息汇聚, 一次性问, 然后直接去问.

紧急请当面, 次紧急用电话, 不大紧急, 可以用IM 工具, 对方实在忙, 可以先约个时间.

小结

学会基本的沟通技巧, 善用之, 同时, 尊重他人的时间, 他人也会尊重你的时间.

vim 杂谈 - 关于快速编辑

Sat, 25 Mar 2017 08:00:00 +0800

在vim中写代码, 并不是, 我们所见到的代码都要一个个字符输进去, 一定不是这样的.

这篇, 让我们来谈谈如何进行快速编辑.

当然, 一篇文章只能概述, 给大家一些参考, 具体每项都可以自行找相关资料. 很多外链, 莫跳丢了

注意, 其中会涉及到比较多的插件, 而 k-vim 用的是 vim-plug, 如果你用得是其他的插件管理工具, 自行转换.

textobject

文本对象, 是进行快速编辑的基础秘诀. 将一个单词, 句子, 段落当成一个对象看待, 可以进行快速选中/替换/删除等操作

有一篇文章解释得很清楚 Vim Text Objects: The Definitive Guide

简单说明

命令格式:  操作+范围+对象

对象

w  -  word单词
s  -  sentence句子
p  -  paragraph段落
' " ) ] } > 等成对的
t  -  Tag标签

范围

i  -  在里面
a  -  所有, 包括成对的引号等

操作

d  -  删除
v  -  选中
c  -  替换

例子, |代表光标位置

123(a|bc)456

di)   删除引号内的内容   => 123()456
da)   删除引号内容, 包括引号  => 123456
vi)   选中引号内内容 abc
....

textobject增强

vim自带了很多文本对象, 但是还可以进一步增强, 例如, 以行l(line)/以文件e(entire file)/以缩进i(indent)

在 k-vim 中, 加了如下的几个文本对象, 这样, 在写python代码时, 你可以很方便的批量选中同一个缩进里面的所有代码块, 即使代码之间有空行.

" text object
" 支持自定义文本对象
Plug 'kana/vim-textobj-user'
" 增加行文本对象: l   dal yal cil
Plug 'kana/vim-textobj-line'
" 增加文件文本对象: e   dae yae cie
Plug 'kana/vim-textobj-entire'
" 增加缩进文本对象: i   dai yai cii - 相同缩进属于同一块
Plug 'kana/vim-textobj-indent'

还有很多插件, 提供了更加丰富的文本对象, 例如, 函数中的参数等. 可以根据需要自行加入

代码补全

代码补全, 是必需品, 也是提升效率的大杀器.

对比试用过非常多的补全插件之后, 最终选定了 YouCompleteMe. 快速提示/模糊匹配/跳转到函数定义等等, 总之, 非常流畅, 体验很好.

这个插件唯一缺点是: 太难装. 没错, 就是太难装, 对vim版本有要求, 然后在天朝这种网络环境下要拉接近300M的文件下来不是一件很容易的事情, 下完之后还得编译>_<#

但是, 历经千辛万苦之后, 你会发现这是值得的, 有了 YCM, 写代码的速度和质量能提升非常非常非常非常多.

Plug 'Valloric/YouCompleteMe'

代码片段

代码片段, 是代码补全的互补. 当你预先定义一些常用的片段, 就能输入关键字后, 触发补全整个代码片段

这里推荐的插件是 ultisnips(代码片段补全工具) 配合 vim-snippets(常用代码片段, 包含各类预研)

" Group dependencies, vim-snippets depends on ultisnips
" 代码片段快速插入 (snippets中,是代码片段资源,需要学习)
" Snippets are separated from the engine. Add this if you want them:
Plug 'SirVer/ultisnips' | Plug 'honza/vim-snippets'

引号括号等及 html 标签不全

另一个必须品, 当我们输入引号('' ""), 括号(() [] {}) 以及 html的标签, 这类都是成对出现的,

当我们输入一半, 自动补全另一半字符. 这里用到的插件是 delimitMate 和 closetag.vim

" 自动补全单引号，双引号等
Plug 'Raimondi/delimitMate'
" 自动补全html/xml标签
Plug 'docunext/closetag.vim', { 'for': ['html', 'xml'] }

然后, 针对Python做了个优化, 可以快速补全docstring

"""
"""

多光标编辑

在编辑一段代码时, 例如, 想修改函数体内某个变量名, 除了用替换(查找+替换相对复杂), 还可以用 vim-multiple-cursors, 之前写的一篇博客 VIM插件: MULTIPLE-CURSORS(多光标操作)

" 多光标选中编辑
" multiplecursors
Plug 'terryma/vim-multiple-cursors'

快速注释

很多时候要注释多行的代码, 或者解开注释. 你需要 nerdcommenter

你只需要 选中(shift+v+j/k) 然后 ,cc. 如果仅注释当前行的话, 可以省了选中这一步, 直接,cc

解开注释 ,cu(注意, 这里的,等于键)

" quick edit
" 快速注释
Plug 'scrooloose/nerdcommenter'

演示博客: VIM插件: NERDCOMMENTER(快速注释)

修改环绕字符

场景: 给单词加引号, 给十个单词加引号, 删除某一对引号/括号, 加

将字符串括起来

用到两个插件 vim-surround(负责环绕字符编辑) 和 vim-repeat(负责重复)

" 快速加入修改环绕字符
" for repeat -> enhance surround.vim, . to repeat command
Plug 'tpope/vim-repeat' | Plug 'tpope/vim-surround'

吐槽下, vim-surround快捷键特别感人…..

博客说明: VIM插件: SURROUND & REPEAT(成对符号编辑)

对齐

偶尔的需求, 需要根据=或,或者空格, 将多行数据对齐, 之前的一篇博客说明 VIM插件: EASY-ALIGN(快速对齐)

" easyalign
" 快速赋值语句对齐
Plug 'junegunn/vim-easy-align'

去行尾空格

轻微强迫症, 忍不了每行代码行尾没用的空格

" trailingwhitespace
" 快速去行尾空格 [, + ]
Plug 'bronson/vim-trailing-whitespace'

配了 ,+空格, 一键去除当前文件所有的行尾空格

" trailingwhitespace {{{
    map  :FixWhitespace
" }}}

后面文章会提及vim中那些被动技能, 会提到如何配置保存时自动去除行尾空格

缩进

写代码时, 有时候要进行缩进, 选中后, 例如shift-v加jk上下选中多行, <或者>可以进行整体缩进, 但是遇到个问题, 有时候需要多次缩进, 而默认, 缩进一次后, 选中消失, 要操作, 得再次选中…..(>_<#)

增加如下配置, 缩进完自动选中, 可以再次缩进

" 调整缩进后自动选中，方便再次操作
vnoremap <  >gv

快速替换/删除最近插入的内容

当我们插入一段内容, 然后切换到普通模式后, 相对插入的内容进行快速选中, 然后删除或者替换, 可以

" 选中并高亮最后一次插入的内容
nnoremap gv `[v`]

python开发

两个插件推荐

" 改变编辑时缩进行为, 更友好的缩进
Plug 'hynek/vim-python-pep8-indent'

" import 排序, 强迫症福音
Plug 'fisadev/vim-isort'

预告: 下一篇, 将快速导航, 如何在项目维度导航跳转

vim 杂谈 - 关于移动

Mon, 20 Mar 2017 08:00:00 +0800

这个专栏的主要目的, 是介绍后台开发, vim, python, 工具, 效率, 项目等等一些所思所想. 欢迎关注及交流.

k-vim 这个项目, 虽然一年只更新一两次, 但是里面很多配置, 都是基于使用中的痛点, 以及 符合自觉 的原则进行的变更.

整体而言, k-vim 虽然做成了一个开箱即用的配置, 但是很多使用者更想知道一些更具体的说明, 包含配置项, 配置原因等等.

之前有个blog有提过一句

Don’t put anything in your .vimrc you don’t understand!

虽然我不是十分赞同(我更倾向于基于一个完备的配置再进行深入了解和 DIY, 毕竟从0打造成本略高).

但是觉得有必要, 写一写, 谈一谈vim中的一些配置的原因.

目测会成系列, 从前到后你也能个性化自己的完整配置. 也可以借鉴一些技巧和插件使用(总共会提及约60+插件)

第一篇, 移动.

HJKL

一谈到移动, 首先想到的是hjkl, 最基本的上下左右

h 左移
l 右移

k 上移
j 下移 (记忆 jump)

当然, 左右只是字符间移动, 上下是行之间的移动

优化HJKL

首先, 为了防止自己情不自禁使用 上下左右 方向键, 可以禁用之.

" 关闭方向键, 强迫自己用 hjkl
map  
map  
map  
map

其次, 当一行超长之后, se wrap, 一行就显示为多行(一个物理行 - 多个展示行), 如果是默认配置, 使用 jk 移动时, 将会是物理行维度的, 而直觉上应该在展示行维度跳转(视觉上), 所以加配置, 使得jk在展示行之间上下跳转

"Treat long lines as break lines (useful when moving around in them)
"se swap之后，同物理行上直接跳
nnoremap k gk
nnoremap gk k
nnoremap j gj
nnoremap gj j

另外, 当上下移动时, 默认光标到顶/到底后, 再用jk时, 光标是贴着终端顶部或底部的, 需要配置, 保证光标距离顶部或底部一定行数, 这样显示视觉效果更好.

" 在上下移动光标时，光标的上方或下方至少会保留显示的行数
set scrolloff=7

单词间移动

wbe, 原先是wWbBeE, 大小写都是有各自含义的, 但是, 更懒的做法, 只用小写wbe, 毕竟, 使用大写WBE, 你还得多按一个shift键, 以及, 肌肉记忆下, 操作的一瞬间, 你很难将你想要的和使用大写还是小写分别代表什么动作, 句子里哪个是标点关联起来.

所以, 直接无视大写吧

w 移到下一个单词 (记忆 next word)
b 移动到单词开头 (记忆 back)
e 移动到单词尾部

关于 0和$, 以及 HML 的优化

0和$, 分别是

0 移动到行首
$ 移动到行尾

而, 0, 需要手指离开字母区, $更惨, 还得多按一个shift. 另外其实还有个^的, 实在按不着>_<#

HML 是同屏间, 快速移动到屏幕顶部/中间/底部, 顶部和底部还好, 中间到底在哪? 具体哪一行, 这个是比较范的操作, 非精确操作(不能一次性移动到想要的位置), 所以我的结论是: 废掉

将H映射成移动到行首(最左边), 将L映射成移动到行尾(最右边), 和原先hjkl意义同, 且在字母区. 更符合直觉

" Go to home and end using capitalized directions
noremap H ^
noremap L $

行内: fFtT

f/F, 同一行内向前/向后跳转, 而t/T同, 只是会调到目标位置的前面一个字符

我的做法是, 忘掉tT, fF更符合直觉, 真正的指哪到哪, 而且f=find也好记

f  跳转到向前搜索的字母位置
F  跳转到向后搜索的字母位置

在这里, 推荐一个插件(被动生效), 可以高亮显示目标字母: quick-scope A Vim plugin that highlights which characters to target for f, F and family. No mappings are needed.

文件: 关于 ctrl + fbud

ctrl + f/b 下翻/上翻一页, 而ctrl + u/d 下翻/上翻半页.

我的做法是, 忘掉ctrl + f/b, 只用ctrl + u/d

我们经常做的操作是, 不停的上翻/下翻, 连续动作, 一整页太多, 看内容很容易思维上断开, 需要返回去重看, 而半页有一半的东西是连着的; 而对于使用压掌大法按ctrl的人来说, 按住ctrl再反复fb, 特别是 b, 特别难按, fb都在左边, 左手太累

而ud, 可以将操作放到两手, 也方便(肌肉)记忆

ctrl + u 上翻半页(记忆 up)
ctrl + d 下翻半页(记忆 down)

文件: 头尾和某一行

gg  跳转到文件头
G   跳转到文件尾

:n  精确移动到第几行

记住这三个, 基本够了吧?

分屏移动

ctrl + w + hjkl 是默认分分屏的快捷键, 去掉w更快些

" 分屏窗口移动, Smart way to move between windows
map  j
map  k
map  h
map  l

插件: 标记跳转增强 `vim-signature`

默认, m + 字母, 可以在当前打一个标记, 然后 反引号+字母 可以跳转到标记行

但是存在的缺点是: 标记不可见, 且反引号实在难按

所以做了些增强

安装这个插件: vim-signature

具体安装/配置/演示: VIM插件: VIM-SIGNATURE(快速标记跳转)

" 交换 单引号/反引号, 使得可以快速使用 单引号 跳到marked位置
nnoremap ' `
nnoremap ` '

其常用的几个快捷键

" 显示marks - 方便自己进行标记和跳转
" m[a-zA-Z] add mark
" '[a-zA-Z] go to mark
" m  del all marks
" m/        list all marks
" m.        add new mark just follow previous mark

插件: 终极跳转 easymotion

有一个插件, 对跳转做了深入的定制, 那就是: vim-easymotion

安装了之后, 简直想怎么跳就怎么跳. 作为一个必备插件, 大家有必要深入学习下用法, 跳转效率翻倍

之前写的一篇博文介绍: VIM插件: EASYMOTION(快速跳转)

用法1: 跳转到当前光标前后的位置(w/b)
用法2: 搜索跳转(s)
用法3: 行级跳转(jk)
用法4: 行内跳转(hl)
用法5: 重复上一次动作(.)

具体配置及演示见博文

其他

vim中跳转的配置大抵这些就够用了.

下一篇, 将介绍如何快速编辑. 后续还有搜索替换等等一系列内容

读书笔记-重构: 章11 处理概括关系

Sun, 04 Dec 2016 20:56:00 +0800

重构的读书笔记, 简单转成python版本的code, 供参考

章11 处理概括关系

多是类相关, 浅显易懂, 不写示例代码了, 有兴趣可以看看原书的例子

11.1 Pull Up Field 字段上移

两个子类拥有相同的字段. 将该字段移至超类

11.2 Pull Up Method 函数上移

游戏函数, 在各个子类中产生完全相同的结果. 将该函数移至超类

11.3 Pull Up Constructor Body 构造函数本体上移

你在各个子类中拥有一些构造函数, 他们的本体几乎完全一致. 在超类中新建一个构造函数, 并在子类的构造函数中调用它

11.4 Push Down Method 函数下移

超类中的某个函数只与部分(而非全部)子类有关. 将这个函数移到相关的那些子类中

11.5 Push Down Field 字段下移

超类中的某个字段只被部分(而非全部)子类用到. 将这个字段移到需要它的那些子类去

11.6 Extract Subclass 提炼子类

类中的某些特性只被某些(而非全部)实例用到. 新建一个子类, 将上面所说的那一部分特性移到子类中

11.7 Extract Superclass 提炼超类

两个类有相似特性. 为这两个类建立一个超类, 将相同特性移至超类

11.8 Extract Interface 提炼接口

若干客户使用类接口中的同一子集, 或者两个类的接口有部分相同. 将相同的子集提炼到一个独立接口中

11.9 Collapse Hierarchy 折叠继承体系

超类和子类之间无太大区别. 将它们合为一体

11.10 From Template Method 塑造模板函数

你有一些子类, 其中相应的某些函数以相同顺序执行类似的操作, 但各个操作细节上有所不同. 将这些操作分别放进独立函数中, 并保持他们有相同的签名, 于是原函数也就变得相同了. 然后将原函数上移至超类.

模板方法模式

11.11 Replace Inheritance with Delegation 以委托取代继承

某个子类只是用超类接口中的一部分, 或是根本不需要继承而来的数据. 在子类中新建一个字段用以保存超类; 调整子函数, 令它改而委托超类; 然后去掉两者之间的继承关系

判断是否误用/滥用了继承

11.12 Replace Delegation with Inheritance 以继承取代委托

你在两个类之间使用了委托关系, 并经常为整个接口编写许多极简单的委托函数. 让委托类继承受托类.

读书笔记-重构: 章10 简化函数调用

Sun, 04 Dec 2016 20:55:00 +0800

重构的读书笔记, 简单转成python版本的code, 供参考

章10: 简化函数调用

10.1 Rename Method 函数改名

函数的名称未能揭示函数的用途. 修改函数名称

给函数一个好名字

def get_number():
    return "%s-%s" % (area_code, number)

def get_office_telephone_numer():
    return "%s-%s" % (area_code, number)

10.2 Add Parameter 添加参数

某个函数需要从调用端得到更多信息. 为此函数添加一个对象参数, 让对象带进函数所需要的信息

动机: 必须修改一个函数, 而修改后的函数需要一些过去没有的信息, 此时需要添加一个参数

10.3 Remove Parameter 移除参数

函数本体不再需要某个参数. 将该参数去除

程序员可能经常添加参数, 却往往不愿意去去除它们.

10.4 Separate Query from Modifier 将查询函数和修改函数分离

某个函数既返回对象状态值, 又修改对象状态. 建立两个不同的函数, 其中一个负责查询, 另一个负责修改

单一职责原则. 任何有返回值的函数, 都不应该有看得到的副作用

def get_total_and_set_ready_state():
    pass

def get_total():
    pass

def set_ready_ste():
    pass

10.5 Parameterize Method 令函数携带参数

若干函数做了类似的工作. 但在函数本体中却包含了不同的值. 建立单一函数, 以参数表达那些不同的值

def five_percent_raise():
    pass
def ten_percent_raise():
    pass

def percent_raise(percent):
    pass

10.6 Replace Parameter with Explicit Methods 以明确函数取代参数

你有一个函数, 其中完全取决于参数值而采取不同行为. 针对该参数的每一个可能值, 建立一个独立函数

def set_value(name, value):
    if name == 'height':
        _height = value
        return
    if name == 'width':
        _width = value
        return

def set_height(value):
    pass

def set_width(value):
    pass

10.7 Preserve Whole Object 保持对象完整

你从某个对象中取出若干值, 将他们作为某一次函数调用时的参数. 改为传递整个对象.

low = rangle.get_low()
high = rangle.get_high()

plan = plan.within_rangle(low, high)

plan = plan.within_rangle(rangle)

10.8 Replace Parameter with Methods 以函数取代参数

对象调用了某个函数, 并将所得结果作为参数, 传递给另一个函数. 而接受该参数的函数本身也能调用前一个函数. 让参数接收者去除该参数, 并直接调用前一个函数

base_price = quantity * item_price
discount_level = get_discount_level()
final_price = discounted_price(base_price, discount_level)

base_price = quantity * item_price
final_price = discounted_price(discount_level)

10.9 Introduce Parameter Object 引入参数对象

某些参数总是很自然地同时出现. 以一个对象取代这些参数

def method_1(start, end):
    pass

def method_2(start, end):
    pass

def method_1(date_range):
    pass

def method_2(date_range):
    pass

10.10 Remove Setting Method 移除设值函数

类中某个字段应该在类创建时被设值, 然后就不再改变. 去掉该字段的所有设值函数.

class A(object):
    def __init__(self, value):
        self.__value = value

    @property
    def value(self):
        self.__value

10.11 Hide Method 隐藏函数

有一个函数, 从来没有被其他任何类用到. 将这个函数改成private

class A(object):
    def __get_value(self):
        pass

10.12 Replace Constructor with Factory Method 以工厂函数取代构造函数

你希望在创建对象时不仅仅是做简单的建构动作. 将构造函数替换为工厂函数

class Employee(object):
    def __init__(self, type):
        if type....

class Employee(object):
    @staticmethod
    def create(type):
        if type....

10.13 Encapsulate Downcast 封装向下转型

某个函数返回的对象, 需要由函数调用者执行向下转型(downcast). 将向下转型动作移到函数中.

强类型OO语言中. python不涉及, 但是道理相通. 如果调用某个函数, 每次都要对返回值进行处理. 那么, 可以将处理逻辑放入到函数中

10.14 Replace Error Code with Exception 以异常取代错误码

某个函数返回一个特定的代码, 用以表示某种错误情况. 改用异常.

if amount > _balance:
    return -1
else:
    _balance -= amount
    return 0

if amount > _balance:
    raise Exception()

_balance -= amount

10.15 Replace Exception with Test 以测试取代异常

面对一个调用者可以预先检查的条件, 你抛出了一个一行. 修改调用者, 使它在调用函数之前先做检查

try:
    return values[index]:
except:
    return 0

if index >= len(values) or index < 0:
    return 0
return values[index]

读书笔记-重构: 章9 简化表达式

Sun, 04 Dec 2016 20:50:00 +0800

重构的读书笔记, 简单转成python版本的code, 供参考

章9: 简化表达式

9.1 Decompose Conditional 分解条件表达式

你有一个复杂的条件语句(if-then-else). 从if, the, else三个段落中分别提炼出独立函数

if date < SUMMER_START) or date > SUMMER_END:
    charge = quantity * _winter_rate + _winter_servioce_charge
else:
    charge = quantity * _summer_rate

if not_summber(date):
    charge = winter_charge(quantity)
else:
    charge = summber_charge(quantity)

9.2 Consolidate Cnditional Expression 合并条件表达式

你有一系列条件测试, 都得到相同结果. 将这些测试合并成一个条件表达式, 并将这个条件表达式提炼成为一个独立函数

if _seniority < 2:
    return 0
if _months_disabled > 10:
    return 0
if _is_part_time:
    return 0

if is_not_eligible_for_disability:
    return 0

9.3 Consolidate Dumplicate Conditional Fragments 合并重复的条件判断

在条件表达式的每个分支上有着相同的一段代码. 将这段重复代码搬移到条件表达式之外

if is_special:
    total = price * 0.95
    send()
else:
    total = price * 0.98
    send()

if is_special:
    total = price * 0.95
else:
    total = price * 0.98
send()

9.4 Remove Control Flag 移除控制标记

在一系列布尔表达式中, 某个变量带有"控制标记"(control flag)的作用. 以break语句或return取代控制标记

found = False
for i in range(5):
    print i
    if i == 3:
        found = True

return found

for i in range(5):
    print i
    if i == 3:
        return True

9.5 Replace Nested Conditional with Guard Clauses 以守卫语句取代嵌套条件表达式

函数中的条件逻辑使人难以看清正常的执行路径. 使用守卫语句表现所有特殊情况

在Python中相当有用

if _is_dead:
    result = dead_amount()
else:
    if _is_separated:
        result = separated_amount()
    else:
        if _is_retired:
            result = retired_amount()
        else:
            result = normal_payamount()
return result

if _is_dead:
    return dead_amount()

if _is_separated:
    return separated_amount()

if _is_retired:
    return retired_amount()

return normal_payamount()

9.6 Replace Conditional with Polymorphism 以多态取代条件表达式

你手上有多个条件表达式, 它根据对象类型的不同而选择不同的行为. 将这个条件表达式的每个分支放进一个子类内的覆写函数中, 然后将原始函数声明为抽象函数

if area == 'EUROPEAN':
    return get_base_speed()
elif area == 'AFRICAN':
    return get_base_speed() - get_load_factor() * _number_of_coconuts
else:
    return 0 if _is_nailed else get_base_speed(_voltage)

class Bird(object):
    def get_base_speed():
        pass

class European(Bird):
    def get_base_speed():
        pass

class African(Bird):
    def get_base_speed():
        pass

9.7 Introduce Null Object 引入Null对象

你需要再三检查某对象是否为null. 将null值替换为null对象

多态的根本好处是你不必再向对象询问: 你是什么类型, 然后根据类型调用其行为.

if customer is None:
    plan = billing_plan.basic()
else:
    plan = customer.get_plan()

if customer is None:
    customer_name = 'occupant'
else:
    customer_name = customer.get_name()

class Customer(object):
    pass

class NullCustomer(Customer):
    def get_plan(self):
        return billing_plan.basic()
    def get_name(self):
        return 'occupant'

9.8 Introduce Assertion 引入断言

某一段代码需要对程序状态做出某种假设. 以断言明确表示这种假设

# note: limit must greater 100 here
do something

assert limit > 100
do something

读书笔记-重构: 章8 重新组织数据

Sat, 03 Dec 2016 11:10:00 +0800

重构的读书笔记, 简单转成python版本的code, 供参考

章8: 重新组织数据

8.1 Self Encapsulate Field 自封装字段

你直接访问一个字段, 但字段间的耦合关系逐渐变额笨拙. 为这个字段建立取值/设置函数, 并且只以这些函数来访问字段

间接访问的好处是, 可以灵活改变获取数据的途径

class A(object):
    def include(self, arg):
        return self.low < arg < self.high

class A(object):
    def include(self, arg):
        return self.low < arg < self.high

    @property
    def low(self):
        return self._low

    @property
    def height(self):
        return self._high

8.2 Replace Data Value with Object 以对象取代数据值

你有一个数据项, 需要与其他数据和行为一起使用才有意义

独立成对象

class Customer(object):
    def__init__(self, name, area_code, number):
        ....

    def get_phone_number(self):
        return "%s-%s" % (self.area_code, self.number)

class Phone(object):
    def __init__(self, area_code ,number):
        ....
    @property
    def number(self):
        return "%s-%s" % (self.area_code, self.number)


class Customer(object):
    def__init__(self, name, area_code, number):
        ....

8.3 Change Value to Reference 将值对象改为饮用对象

你从一个类衍生出许多彼此相等的实例, 希望将他们替换为同一个对象. 将这个值对象变成引用对象

# only 4 types, but 10000 A instance
class A(object):
    def __init__(self, type_id, type_name):
        self.type_id = type_id
        self.type_name = type_name

class Type(object):
    def __init__(type_id, type_name):
        self.type_id = type_id
        self.type_name = type_name

class A(object):
    def __init__(self, _type):
        self._type = _type

8.4 Change Reference to Value 将引用对象改为值对象

你有一个引用对象, 很小且值不可变, 而且不易管理. 将它变成一个值对象

手法, 将重构目标变成不可变对象. 即, 只有可以变成不可变对象的才能运用这个技巧

class Currency(object):
    def __init__(self, code):
        self.code = code

class Currency(object):
    def __init__(self, code):
        self._code = code

    @property
    def code(self):
        return self._code

    def __eq__(self, other):
        return self.code == other.code

8.5 Replace Array with Object 以对象取代数组

你有一个数组, 其中元素各自代表不同的东西. 以对象替换数组, 对于数组中的每个元素, 以一个字段来表示

row = ["Liverpoo", 15]

claas Record(object):
    def __init__(self, name, wins):
        self.name = name
        self.wins = wins

record = Record("Liverpoo", 15)

8.6 Duplicate Observed Data 复制"被监视数据"

你有一些领域数据置身于 GUI 控件中, 而领域函数需要访问这些数据. 将数据复制到一个领域对象中. 建立Observer模式, 用以同步领域对象和GUI对象内的重复数据

observer模式, 不解释

8.7 Change Unidirectional Association to Bidirectional 将单向关联改为双向关联

两个类都需要使用对方特性, 但其间只有一条单向连接. 添加一个反向指针, 并使修改函数能够同时更新到两条连接

class Customer(object):
    def get_orders(self):
        # need a lot of codes here

class Order(object):
    def __init__(self):
        pass

    @property
    def customer(self):
        return self._customer
    @customer.setter
    def customer(self, customer):
        self._customer = customer

    def get_customer_address():
        return self._customer.address

class Customer(object):
    def __init__(self):
        self.orders = []

    def add_order(self, order):
        self.orders.append(order)

    def get_orders(self):
        return self.orders

class Order(object):
    def __init__(self):
        pass

    @property
    def customer(self):
        return self._customer

    @customer.setter
    def customer(self, customer):
        self._customer = customer
        self._customer.add_order(self)

    def get_customer_address():
        return self._customer.address

8.8 Change Bidirectional Association to Unidirectional 将双向关联改为单向关联

两个类之间有双向关联, 但其中一个类如今不再需要另一个类的特性了

上面的例子, 如果Customer不再需要get_orders. 则可以去掉双向连接, 防止僵尸对象出现

8.9 Replace Magic Number with Symbolic Constant 以字面常量取代魔法数

你有一个字面数值, 带有特别含义. 创建一个常量, 根据其意义为它命名, 并将上述字面数值替换为这个常量

def potential_energy(mass, height):
    return mass * 9.81 * height

GRAVITATIONAL_CONSTANT = 9.81
def potential_energy(mass, height):
    return mass * GRAVITATIONAL_CONSTANT * height

8.10 Encapsulate Field 封装字段

你的类中存在一个public字段, 将它声明为private, 并提供相应访问函数

class A(object):
    def __init__(self, value):
        self.value = value

class A(object):
    def __init__(self, value):
        self.__value = value

    @property
    def value(self):
        return self.__value

    @value.setter
    def value(self, v):
        self.__value = v

8.11 Encapsulate Collection 封装集合

有个函数返回一个集合. 让这个函数返回该集合的一个只读副本, 并在这个类中提供添加/移除集合元素的函数

class A(object):
    def __init__(self):
        self._members = []
    def get_members(self):
        return self._members

class A(object):
    def __init__(self):
        self._members = []
    def get_members():
        return tuple(self._members)

    def add_member(self, member):
        self.members.append(member)

    def remove_member(self, member):
        self.members.remove(member)

8.12 Replace Record with Data Class 以数据类取代记录

你需要面对传统编程环境中的记录结构. 为该记录创建一个"哑"数据对象

可能面对的是一个遗留程序, 需要与其记录进行结构交流. 例如从数据库读出来的记录, 接口调用返回数据等

8.13 Replace Type Code with Class 以类取代类型码

类之中有一个类型码, 但它并不影响类的行为. 以一个新的类替换该数值类型码

class Person(object):
    def __init__(self):
        self.O = 0
        self.A = 1
        self.B = 2
        slef.AB = 3

class Person(object):
    def __init__(self):
        self.O = BloodGroup.O
        self.A = BloodGroup.A
        self.B = BloodGroup.B
        slef.AB = BloodGroup.AB

8.14 Replace Type Code with Subclasses 以子类取代类型码

你有一个不可变的类型码, 它会影响到类行为. 以子类取代类型码

使用多态来处理, 需要在一个类中使用if-else或者switch来根据类型码做出不同行为的类

class Employee(object):
    def __init__(self):
        self.ENGINEER = 1
        self.SALESMAN = 0

class Employee(object):
    def __init__(self):
class Engineer(Employee):
    pass
class Salesman(Employee):
    pass

8.15 Replace Type Code with State/Strategy 以Stat/Strategy取代类型码

你有一个类型码, 它会影响类的行为, 但你无法通过继承手法消除它. 以状态对象取代类型码

State模式和Strategy模式

8.16 Replace Subclass with Fields 以字段取代子类

你的各个子类的唯一差别只在"返回常量数据"的函数上. 修改这些函数, 使它们返回超类中的某个(新增)字段, 然后销毁子类

class Person(object):
    def is_male(self):
        pass
    def get_code(self):
        pass

class Male(Person):
    def is_male(self):
        return True
    def get_code(self):
        return "M"

class Feale(Person):
    def is_male(self):
        return False
    def get_code(self):
        return "F"

class Person(object):
    def is_male(self):
        return self._is_male
    def get_code(self):
        return 'M' if self._is_male else "F"

读书笔记-重构: 章7 在对象之间搬移特性

Sat, 03 Dec 2016 11:05:00 +0800

重构的读书笔记, 简单转成python版本的code, 供参考

章7: 在对象之间搬移特性

7.1 Move Method 搬移函数

你的程序中, 有个函数与其所驻之外的另一个类进行更多交流: 调用后者, 或者被后者调用. 在该函数最常引用的类中建立一个有着类似行为的新函数. 将就函数变成一个单纯的委托函数, 或是将就函数完全移除

class A(object):
    def count(self):
        b = B()
        # a lot operations with b
        return b.compute()
class B(object):
    def compute(self): pass

class A(object):
    pass
class B(object):
    def count(self):
        # a lot operations with b
        return self.compute()
    def compute(self): pass

7.2 Move Field 搬移字段

某个字段被其所驻类之外的另一个类更多地用到. 在目标类新建一个字段, 修改原字段的所有用户, 令他们改用新字段

7.3 Extract Class 提炼类

某个类做了应该由两个类做的事情. 建立以一个新的类, 将相关字段和函数从旧类版移到新的类

class Persion(object):
    def __init__(self, name, age, office_area_code, office_number):
        self.name = name
        self.age = age
        self.office_area_code = office_area_code
        self.office_number = office_number
    def get_phone_number(self):
        return "%s-%s" % (self.office_area_code, self.office_number)

class Person(object):
    def __init__(self, name, age, office_area_code, office_number):
        self.name = name
        self.age = age
        self.phone_number = PhoneNumber(office_area_code, office_number)

    def get_phone_number(self):
        return self.phone_number.get_number()

class PhoneNumber(object):
    def get_number(self):
        return "%s-%s" % (self.area_code, self.number)

7.4 Inline Class 将类内聚化

某个类没有做太多事情. 将这个类的所有特性移动到另一个类中, 然后移除原类

class A(object):
    def __init__(self, value):
        self.value = value
    def fmt(self):
        return "[%s]" % self.value
class B(object):
    def format(object, values):
        for value in values:
            a = A(value)
            print a.fmt()

class B(object):
    def format(object, values):
        for value in values:
            print "[%s]" % value

7.5 Hide Delegate 隐藏"委托关系"

客户通过一个委托来调用另一个对象. 在服务类上建立客户所需要的所有函数, 用以隐藏委托关系

class Employee(object):
    def get_department(self):
        return Department()

john = Employee()

manager = john.get_department().get_manager()

class Employee(object):
    def get_department(self):
        return Department()

    def get_manager(self):
        return Department().get_manager()

john = Employee()
manager = john.get_manager()

7.6 Remove Middle Man 移除中间人

某个类做了过多的简单委托动作. 让客户直接调用受托类

当上一步实例中Employee承载了大量的委托行为. 可以反向处理, 移除中间人. (当受托类功能越来越多, 完全变成了一个"中间人")

7.7 Introduce Foreign Method 引入外加函数

你需要为提供服务的类增加一个函数, 但你无法修改这个类. 在客户类中建立一个函数, 并以第一参数形式传入一个服务类实例

new_start = Date(previous_end.get_year(), previous_end.get_month(), previous_end.get_date() + 1)

new_start = next_day(previous_end)

def next_day(previous_end):
    return Date(previous_end.get_year(), previous_end.get_month(), previous_end.get_date() + 1)

7.8 Introduce Local Extension 引入本地扩展

你需要为服务类提供一些额外函数, 但你无法修改这个类. 建立一个新类, 使它包含这些额外函数. 让这个扩展品成为原类的子类或者包装类

class A(object):
     pass

class A(object):
    pass
class B(A):
    # add extra methods

读书笔记-重构: 章6 重新组织函数

Sat, 03 Dec 2016 11:00:00 +0800

重构的读书笔记, 简单转成python版本的code, 供参考

章6: 重新组织函数

6.1 Extract Method 提炼函数

你有一段代码可以被组织在一起并独立出来, 将这段代码放进一个独立函数中, 并让函数名称解释该函数的用途

def print_owing(double amount):
    print_banner()

    // print details
    print "this is the detail: "
    print "amnount: %s" % amount

def print_details(amount):
    print "this is the detail: "
    print "amnount: %s" % amount

def print_owing(double amount):
    print_banner()
    print_details(amount)

6.2 Inline Method 内联函数

一个函数的本体与名称同样清楚易懂. 在函数调用点插入函数本体, 然后移除该函数

def get_rating(x):
    return 2 if more_than_five_late_deliveries(x) else 1
def more_than_five_late_deliveries(x):
    return x > 5

def get_rating(x):
    return 2 if x > 5 else 1

6.3 Inline Temp 内联临时变量

你有一个临时变量, 只被一个简单表达式赋值一次, 而它妨碍了其他重构手法. 将所有对该变量的引用动作, 替换为对它复制的哪个表达式自身

base_price = order.get_base_price()
return base_price > 1000

return order.get_base_price() > 1000

6.4 Replace Temp with Query 以查询取代临时变量

你的程序以一个临时变量保存着某一表达式的运算结果. 将表达式提炼到一个独立函数中. 将这个临时变量的所有引用点替换为对新函数的调用. 伺候新函数就可以被其他函数使用

注意: 开始时可以不用担心带来性能问题. 只有存在复用, 且去临时变量.

base_price = quantity * item_price

if base_price > 1000:
    return base_price * 0.95
else:
    return base_price * 0.98

if base_price() > 1000:
    return base_price() * 0.95
else:
    return base_price() * 0.98

def base_price():
    return quantity * itme_price

6.5 Introduce Explaining Variable 引入解释性变量

你有一个复杂的表达式, 将该复杂表达式或其中一部分的结果放入一个临时变量, 以此变量名称来解释表达式的用途

if "MAC" in platform.upper() and "IE" in browser.upper() and was_initialized() and resize > 0:
    #do something

is_macos = "MAC" in platform.upper()
is_ie_browser = "IE" in browser.upper()
was_resized = resize > 0

if is_macos and is_ie_browser and was_initialized() and was_resized:
    # do something

6.6 Split Temporary Variable 分解临时变量

你的程序有某个临时变量被赋值过一次, 它既不是循环变量, 也不被利用与收集计算结果. 针对每次赋值, 创造一个独立, 对应的临时变量

tmp = 2 * (height * width)
print tmp

tmp = height * width
print tmp

perimeter = 2 * (height * width)
print perimeter

area = height * width
print area

6.7 Remove Assignments to Parameters 移除对参数的赋值

代码对一个参数进行赋值. 以一个临时变量取代该参数的位置

def discount(int input_value):
    if input_value > 50:
        input_value -= 2

def discount(int input_value):
    result = input_value
    if input_value > 50:
        result -= 2

6.8 Replace Method with Method Object 以函数对象取代函数

你有一个大型函数, 其中对局部变量的使用使你无法采用Extract method. 将这个函数放进一个单独对象中, 如此一来局部变量就成了对象内的字段, 然后你可以在同一个对象中将这个大型函数分解成多个小型函数

class Account(object):
    def delta(self):
        # do something
        return x
    def gamma(self, input_value, quantity, year_to_date):
        i_value_1 = (input_value * quantity) + self.delta()
        i_value_2 = (input_value * year_to_date) + 100
        if year_to_date - i_value_1:
            i_value_2 -= 20
        i_value_3 = i_value_2 * 7
        # and so on.
        return i_value_3 - 2 * i_value_1

class Account(object):
    def delta(self):
        # do something
        return x
    def gamma(self, input_value, quantity, year_to_date):
        return Gamma(self, input_value, quantity, year_to_date).compute()

class Gamma(object):
    def __init__(self, account, input_value, quantity, year_to_date):
        self.account = account
        self.input_value = input_value
        self.quantity = quantity
        self.year_to_date = year_to_date

        self.i_value_1 = 0
        self.i_value_2 = 0
        self.i_value_3 = 0


    def compute(self):
        self.i_value_1 = (self.input_value * self.quantity) + self.account.delta()
        self.i_value_2 = (self.input_value * self.year_to_date) + 100

        important_thing()

        self.i_value_3 = self.i_value_2 * 7
        # and so on.
        return self.i_value_3 - 2 * self.i_value_1

    def important_thing(self):
        if self.year_to_date - self.i_value_1:
            self.i_value_2 -= 20

6.9 Substitute Algorithm 替换算法

你想要把某个算法那替换成另一个更清晰的算法. 将函数本体替换成另一个算法. 用更清晰的替换原先的

def find_person(i):
    if i == "Don":
        return "D"
    if i == "John":
        return "J"
    if i == "Kent":
        return "K"
    return ""

def find_person(i):
    return {"Don": "D",
            "John": "J",
            "Kent": "k",
            }.get(i, "")

Python 代码规范小结

Thu, 03 Nov 2016 08:00:00 +0800

code review中一些小结, 还没来得及加例子, 简要记录, 供参考

law

一: 一切都与复杂度有关二: 代码应当易于理解

对人:

“好程序员”应当竭尽全力, 把程序写得让其他程序员(以及以后的自己)容易理解.

对代码:

代码被阅读的次数远多于编写和修改的次数

E = mc2 (Error = more codes)

对项目:

公式: 可行性=(当前价值+未来价值)/(实现成本+维护成本). 即相比降低实现成本, 降低维护成本更加重要

基础: 风格

团队成员遵守统一的风格, 保持风格的一致性, 减少理解难度

遵循基础的编码风格:

请仔细阅读, 使用对应编辑器插件工具协助检查

遵循 pep8 风格利用pep8工具(编辑器相关插件)来解决这个问题, 在review之前处理. 以避免在review过程中出现此类问题.
遵循 Google Code Style / 中文版
不要吝啬空行, 把相关的代码行分组, 形成代码块. 声明按块组织起来, 并且把代码分成”段落”(按步骤/顺序/逻辑结构分), 排版合理
每行只写一个语句, 每行只声明一个变量

注释

注释应该有很高的价值(传递信息/空间占用)

代码本身应该尽力做到自说明
注释, 记录了在写代码过程中的思考, 保持紧凑, 简单准确的描述
不要使用尾注释. 容易被整行拷贝/不容易被编辑修改/逐渐腐烂
```
  x = 1  # bad comment

  # good comment
  x = 1
```
不需要的代码, 维护到版本库后(写明commit info), 然后删除. 不要注释起来
不要给不好的命名加注释, 应该去修改命名
不要给那些从代码本身就能快速推断出来的事实写注释.(不要为了注释而注释)
对于复杂的计算逻辑, 要给出注释, 可以通过列举例子, 简单的输入输出来描述
对于大段的逻辑或模块, 需要给总结性注释
注释代码时, 应注重-为何做, 而不是-怎么做
每行注释前用一个空行分开. 注释缩进要和相应代码一致

命名

把信息装入名字中.(自说明)

尽量短, 但是要包含足够的信息(刨掉其中毫无意义的词)
命名一定要有意义, 尽量少使用单个字符作为命名, 除非短表达式(列表解析/lambda等)以及小的作用域范围
常量大写, 变量小写, 类名驼峰, 函数名小写加下划线, 不要混用下划线和驼峰.
不要使用关键字命名, 例如type 和 dir
避免使用容易混淆的命名, 防歧义
慎用首字母缩略词和缩写, 除非团队成员都理解(不要妄图用注释来解决这个问题, 即, 不要注释不好的命名)
不要使用大小写来区分不同对象
同一个变量, 在多个地方, 前后端/数据库/不同函数/请求等, 尽量保持命名一致性
不要害怕过长的命名, 保证易于理解和阅读(现代编辑器可以搞定自动补全和批量变更的问题)
使用具体的名字, 而不是泛化的名字, 例如params/args等, 没有隐含任何信息
bool类型, 除非名字本身有True/False的含义, 否则建议统一使用is_前缀
不要使用双重否定的命名: is_not_pass
for a in b, 注意 a 和 b 的单复数区分

常量

常量大写
作用于同一个模块/逻辑的多个常量, 建议使用统一的前缀
将常量统一组织到某个文件/某几个文件, 并写明注释.
函数/循环中的正则, 请预先compile, 放入变量中.
善用Enum, 对可读性提升很大
同一个枚举变量中, 其包含类型应当一致

变量

减少变量: 变量越多, 越难全部追踪其动向. a.减少没有价值的中间变量 b.减少中间结果(可以通过提前返回来消除) c.减少控制流变量
缩小变量作用域: 避免全局变量(命名空间污染). 需要做到让你的变量对尽量少的代码行可见.
变量定义尽量靠近其使用的地方, 或者, 在使用时定义.
不要使用import *, 会出现各种突如其来的变量名, 可能导致名字空间污染, 造成诡异问题

数据结构

dict, 不要使用for key in d.keys(), 直接使用for key in d

表达式

原则: 保持简短, 易懂.(拆分超长表达式)

抽取反复出现的长表达式到变量或者函数调用
使用解释变量, 将超长表达式中的自表达式抽取城一个解释变量.(抽取, 然后使用变量, 而不是每次都重复表达式)
总结变量: 一个表达式不需要解释, 但是装入一个新的变量中仍然有用. 短名字替代一大块代码. 例如: numbers[0]['obj'].name
使用摩根定理: not a and not b to not (a or b)
删除公共子表达式：如果发现某个表达式老是在你面前出现，就把它赋值给一个变量
中文, 请统一使用u"中文"
表达式中避免使用魔数, 使用常量/枚举替代之

控制流: 分支

if/else顺序: a. 先处理正逻辑而不是负逻辑. b. 先处理掉简单的情况, 还能保证if/else在同一个屏幕内都可见(否则到了else需要回头查) c.先处理有趣或可疑的逻辑
return early, 从函数中提前返回. 使用guard clause来实现. 某些情况返回后, 将不必要思考某个分支出口, 剩余注意力集中在为数不多的情况. 另一个好处是, 能有效减少代码缩进.
减少嵌套: 嵌套很深的代码很难理解, 每个嵌套层次会在读者’思维栈’上又增加了一个条件. 使用return early来减少嵌套. 而循环中的减少嵌套方式, 可以使用if condition: continue/break来进行提早返回.
减少嵌套: 当你对代码进行改动的时候, 从全新的角度审视它, 把它作为一个整体来看待.只关心局部, 不敢动旧有代码, 很容易一层层逻辑嵌套往里加导致深层嵌套
使用is来判定是否是None, 而不是==
条件语句中参数顺序: 左侧变量, 右侧字面值/常量
默认情况都使用if...else, 三目运算只有在最简单的情况下才使用
if condition: return 则不需要else
注意if/else的多层嵌套, 在某些情况下, 判断条件中恒真/恒假的情况

控制流: 循环

善用enumerate而不是维护index变量( enumerate 还可以从1开始计数)
除非必要(逻辑确实如此且带break), 否则不要使用for...else.(增加理解成本)
不要使用for _ in l: _.x, 可读性太差
减少循环内的if...else...嵌套层次, 可以使用if condition: continue

控制流: 异常处理

异常日志同注释, 应该有很高的价值(传递信息/空间占用)

不要把所有代码放到try except中, 只捕获会出异常的代码片段. 注意粒度, 不要放入不必要的代码
不要吞掉异常, 处理或抛出, 同时要打日志(使用logging而不是print打日志)
谨慎使用except Exception捕获所有异常.
不要在finally语句中使用return进行返回, 有坑.
异常的错误信息要有用, 即足够明确, 对问题排查有帮助.
不要使用异常控制程序的流程. 滥用异常, 异常不应该处理正常逻辑
不要滥用异常, 底层被调用函数早已try...except处理了, 调用方不需要再次处理

函数

函数不要太大, 嵌套不要太深

参数命名的一致性: 多个参数, 选择一个有意义的顺序, 并始终一致地使用它(可读性更好, 更容易发现问题)
不要使用可变对象作为函数默认参数的值
一次只做一件事, 注意函数大小, 注意抽象/拆分
抽取不相关的子问题到独立的函数中, 例如纯工具代码, 通用代码, 项目专属代码
抽取反复出现重复的代码到独立函数中
return 值不要使用0/1来代表True/False
同一个函数可能存在多个return, 返回值要保持一致(个数/类型)
return early, 减少阅读代码时的逻辑堆积, 减少贯穿函数始终用于最终判断return的变量数量. 超过3个就变得有些难以维护了, 阅读过程中确定其值有困难
如果函数调用链中, 参数或者return的值反复出现pack/unpack, 可以考虑用dict封装来进行传递.
如果发现每次调用一个函数后, 还需要对返回值进行二次处理, 则是函数封装得不够导致的. 需重构函数, 将处理加进去. (防止某次调用忘了二次处理导致的bug)

类

不要使用type进行类型检查, 用isinstance
使用新式类, 驼峰命名
假设类的某个属性, 每次取出来都需要进行处理(格式化, 转换等, 例如日期格式), 使用property封装这层处理, 同时处理异常情况.

模块

import顺序: 标准库/第三方库/本项目, 之间使用空行隔开
多行import, 请使用from a import (b, c, d)而不是\来进行换行
不要使用from A import *
当相对独立的多个逻辑代码混杂放在一起, 或者发现constant文件超大包含了大量不同逻辑的产量, 可以考虑模块切分

抽象

一定不要机械地复制粘贴代码(会出现大量的重复代码), 应该从全局考虑是否可以抽象
多个函数之间, 如果仅有一两行代码不同, 则可以进行抽象提取
当一段相似的代码出现两次以上, 需要考虑封装(注意粒度)

设计

软件设计三大误区: 1.编写不必要的代码 2.代码难以修改 3.过分追求通用

思考足够充分, 减少过度设计

其他

熟悉标准库, 减少土制轮子的概率, 可以少写代码
熟悉框架/优秀第三方库提供的接口及特性, 原因同上
项目发布前, 移除所有print语句
文件/函数是否写明作者信息? 不, 版本记录中有作者信息. 容易形成领地, 他人不敢修改/不敢大改, 容易造成代码腐烂. 占用空间且没啥用.

参考书目

编写可读代码的艺术
简约之美—软件设计之道
编写高质量代码—改善Python程序的91个建议

[分享]关于vim

Sun, 24 Jul 2016 08:00:00 +0800

很早之前的小组分享, 整理成pdf

ElasticSearch集群部署文档

Wed, 29 Jun 2016 08:00:00 +0800

官方es搭建步骤写的很简略, 但是实际搭建过程中, 会涉及一系列环境配置. 以下的流程, 是在搭建过程中梳理出来的详细步骤(实践过3遍以上)

其实, 这些流程在具体应用的时候, 都可以变成自动化脚本, 或者直接用docker好了, 以便扩容足够快(目前我们用的打包成集成安装包, 实现脚本自动部署)

只是简单集群的基本设置, 不涉及调优的参数配置, 不涉及client/master/data节点区分等等. 可以参照搭建的主体流程.

版本及连接

elasticseearch版本: 2.3.3

系统要求

如果仅作测试用, 不需要两天机器, 可以将两个节点部署在同一台机器上, 对磁盘/cpu要求不高, 内存大于2g基本足够了

如果是正式环境, 需要根据日志量进行评估, 例如, 每天日志量占硬盘约约10G, 且保留30天日志, 则磁盘会占用约300g, es设定的阈值是磁盘空间占满85%则日志开始告警. 所以, 需要至少 300/0.85=354g.

准备两台机器, 在同一个局域网内(可ping通), 分别在每台机器上部署相应es节点, 搭建一套日志集群.

两台机器, 最少的资源了, 但是没法做到高可用, 所以, 还需要再加一台机器, 防止脑裂, 具体见最后(两台主力机器+一台稳定的机器就行)

集群节点: 最少两台机器
内存: 16G及以上
cpu: 4核及以上
硬盘: 800G及以上, 建议1T, 集群容量约10亿级(取决于对应日志大小)
操作系统: centos

这里假设, 两台机器ip分别为

第一台机器: 10.0.0.1
第二台机器: 10.0.0.2

机器系统为centos6.5

部署

1. 确认JDK版本及安装

es依赖java的版本最小为1.7

java -version

如果系统中未安装JDK

则命令返回bash: java: command not found, 需要安装JDK

如果系统中安装了JDK, 需确认版本是否大于java 1.7, 否则需要升级

java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) Server VM (build 24.51-b03, mixed mode)

安装及升级java(注意根据系统不同运行对应安装命令)

# Redhat/Centos/Fedora
sudo yum install java-1.7.0-openjdk

或者到官网, 下载最新的jdk的rpm包, 然后安装

wget http://download.oracle.com/otn-pub/java/jdk/8u91-b14/jdk-8u91-linux-x64.rpm
rpm -Uvh jdk-8u91-linux-x64.rpm

再次确认安装成功

java -version

2. 下载es

版本: 2.3.3

下载地址:

elasticsearch-2.3.3.tar.gz (tar.gz格式)

命令行中的下载命令:

curl -L -O https://download.elastic.co/elasticsearch/release/org/elasticsearch/distribution/tar/elasticsearch/2.3.3/elasticsearch-2.3.3.tar.gz

解压:

tar -xzf elasticsearch-2.3.3.tar.gz

3. 用户/目录/权限设置

新建用户, 假设为es

sudo useradd es

新建目录, 假设/data/目录挂载的硬盘最大(500G以上)

mkdir -p /data/LogTool
mkdir -p /data/LogData

将解压后的目录移动至新建的目录/data/LogTool下, 并改名为elasticsearch

mv elasticsearch-2.3.3 /data/LogTool/elasticsearch

将目录所有者修改为test

chown -R es:es /data/LogTool
chown -R es:es /data/LogData

5. 切换用户

切换到es用户, 并进入elasticsearch目录

su es
cd /data/LogTool/elasticsearch/

以用户es的身份进行后续操作

6. 修改配置文件

以用户es的身份进行操作

文件路径: config/elasticsearch.yml

修改该文件中配置项: (注意, 原始文件中都是被#号注释掉了, 需要去掉对应注释并修改配置值)

集群名: cluster.name, 注意: 两台机器配置一致

cluster.name: inner_es_cluster

节点名: node.name, 注意: 两台机器配置不同, 一台为01, 另一台为02

# 第一台机器
node.name: inner_es_node_01

# 第二台机器
node.name: inner_es_node_02

数据路径: path.data, 为新建立的目录

path.data: /data/LogData/

日志路径: path.logs

path.logs: /data/LogData/logs

LockMemory:

bootstrap.mlockall: true

本机ip: network.host, 注意两台机器配置不同, 分贝配置为对应机器的内网ip

# 第一台机器
network.host: 10.0.0.1

# 第二台机器
network.host: 10.0.0.2

Discovery配置: 注意这里是两台机器内网ip+9300端口, 注意这里minimum_master_nodes=2, 见最后一点防脑裂说明

discovery.zen.ping.unicast.hosts: ["10.0.0.1:9300", "10.0.0.2:9300"]
discovery.zen.minimum_master_nodes: 2

gatewary配置:

gateway.recover_after_nodes: 2
gateway.recover_after_time: 5m
gateway.expected_nodes: 1

新增其他配置到文件末尾, 根据需求加, 这里用到了script, 同时增大了recovery的配置(要大些保证recovery速度, 但是又不能太大, 会将带宽占满)

script.engine.groovy.inline.search: on
script.engine.groovy.inline.aggs: on
indices.recovery.max_bytes_per_sec: 100mb
indices.recovery.concurrent_streams: 10

7. 设置es占用内存

修改文件bin/elasticsearch.in.sh, 将文件如下变量变更为4g(根据自身机器配置, 配置的内存最大不超过机器物理内存的75%. 两个变量值相等, 以获取最大的性能). 当然, 实际使用中4g可能远远不够, 这个值仅是个示例

ES_MIN_MEM=4g
ES_MAX_MEM=4g

修改centos配置: /etc/security/limits.conf, 以便启用memlock, 提升性能

加入, 注意, 示例中用户为es

es soft memlock unlimited
es hard memlock unlimited

确认max descriptiors

查看系统数量

如果结果是unlimited, 则无需任何处理, 直接进入下一步

ulimit -n
unlimited

如果结果是一个整数, 且小于204800

ulimit -n
4096

此时, 需要编辑/etc/security/limits.conf, 加入

es soft nofile 204800
es hard nofile 204800

另一种方法, 修改bin/elasticsearch, 在文件的前半部分加入下面这行代码, 保证在启动前执行即可.

ulimit -n 204800

8. 启动测试

以用户es的身份进行操作

在命令行中执行启动命令

cd /data/elasticsearch/
./bin/elasticsearch

可以看到程序启动日志

[2016-06-30 17:20:26,677][WARN ][bootstrap                ] unable to install syscall filter: seccomp unavailable: requires kernel 3.5+ with CONFIG_SECCOMP and CONFIG_SECCOMP_FILTER compiled in
[2016-06-30 17:20:27,390][INFO ][node                     ] [inner_es_node_01] version[2.3.3], pid[6415], build[218bdf1/2016-05-17T15:40:04Z]
[2016-06-30 17:20:27,390][INFO ][node                     ] [inner_es_node_01] initializing ...
[2016-06-30 17:20:27,948][INFO ][plugins                  ] [inner_es_node_01] modules [lang-groovy, reindex, lang-expression], plugins [], sites []
[2016-06-30 17:20:27,974][INFO ][env                      ] [inner_es_node_01] using [1] data paths, mounts [[/data (/dev/xvdb1)]], net usable_space [67.4gb], net total_space [98.4gb], spins? [no], types [ext3]
[2016-06-30 17:20:27,974][INFO ][env                      ] [inner_es_node_01] heap size [990.7mb], compressed ordinary object pointers [true]
[2016-06-30 17:20:29,926][INFO ][node                     ] [inner_es_node_01] initialized
[2016-06-30 17:20:29,926][INFO ][node                     ] [inner_es_node_01] starting ...
[2016-06-30 17:20:30,083][INFO ][transport                ] [inner_es_node_01] publish_address {10.0.0.1:9300}, bound_addresses {10.0.0.1:9300}
[2016-06-30 17:20:30,088][INFO ][discovery                ] [inner_es_node_01] inner_es_cluster/odmTjZRHRVaa8Zn4vTPcxA
[2016-06-30 17:21:00,091][WARN ][discovery                ] [inner_es_node_01] waited for 30s and no initial state was set by the discovery
[2016-06-30 17:21:00,099][INFO ][http                     ] [inner_es_node_01] publish_address {10.0.0.1:9200}, bound_addresses {10.0.0.1:9200}
[2016-06-30 17:21:00,099][INFO ][node                     ] [inner_es_node_01] started

等待约一分钟后, 看到如下日志代表启动成功

[2016-06-30 17:21:00,099][INFO ][node                     ] [inner_es_node_01] started

确认集群是否启动成功

curl http://10.0.0.1:9200/

{
  "name" : "inner_es_node_01",
  "cluster_name" : "inner_es_cluster",
  "version" : {
    "number" : "2.3.3",
    "build_hash" : "218bdf10790eef486ff2c41a3df5cfa32dadcfde",
    "build_timestamp" : "2016-05-17T15:40:04Z",
    "build_snapshot" : false,
    "lucene_version" : "5.5.0"
  },
  "tagline" : "You Know, for Search"
}

启动第二个节点时日志

[2016-06-30 17:32:42,494][WARN ][bootstrap                ] unable to install syscall filter: seccomp unavailable: requires kernel 3.5+ with CONFIG_SECCOMP and CONFIG_SECCOMP_FILTER compiled in
[2016-06-30 17:32:43,295][INFO ][node                     ] [inner_es_node_02] version[2.3.3], pid[10240], build[218bdf1/2016-05-17T15:40:04Z]
[2016-06-30 17:32:43,295][INFO ][node                     ] [inner_es_node_02] initializing ...
[2016-06-30 17:32:43,879][INFO ][plugins                  ] [inner_es_node_02] modules [lang-groovy, reindex, lang-expression], plugins [], sites []
[2016-06-30 17:32:43,905][INFO ][env                      ] [inner_es_node_02] using [1] data paths, mounts [[/data (/dev/xvdb1)]], net usable_space [67.4gb], net total_space [98.4gb], spins? [no], types [ext3]
[2016-06-30 17:32:43,905][INFO ][env                      ] [inner_es_node_02] heap size [990.7mb], compressed ordinary object pointers [true]
[2016-06-30 17:32:45,876][INFO ][node                     ] [inner_es_node_02] initialized
[2016-06-30 17:32:45,876][INFO ][node                     ] [inner_es_node_02] starting ...
[2016-06-30 17:32:45,978][INFO ][transport                ] [inner_es_node_02] publish_address {10.0.0.2:9300}, bound_addresses {10.0.0.2:9300}
[2016-06-30 17:32:45,983][INFO ][discovery                ] [inner_es_node_02] inner_es_cluster/VBsHeFjXQXau59hkjTuhTA
[2016-06-30 17:32:49,067][INFO ][cluster.service          ] [inner_es_node_02] detected_master {inner_es_node_01}{1BktktzhQ_y6BN-lNIKhHg}{10.0.0.1}{10.0.0.1:9300}, added {{inner_es_node_01}{1BktktzhQ_y6BN-lNIKhHg}{10.0.0.1}{10.0.0.1:9300},}, reason: zen-disco-receive(from master [{inner_es_node_01}{1BktktzhQ_y6BN-lNIKhHg}{10.0.0.1}{10.0.0.1:9300}])
[2016-06-30 17:32:49,077][INFO ][http                     ] [inner_es_node_02] publish_address {10.0.0.2:9200}, bound_addresses {10.213.136.23:9201}
[2016-06-30 17:32:49,077][INFO ][node                     ] [inner_es_node_02] started

注意, 日志中cluster.service部分, 表示发现了第一台机器的节点

[2016-06-30 17:32:49,067][INFO ][cluster.service          ] [inner_es_node_02] detected_master {inner_es_node_01}{1BktktzhQ_y6BN-lNIKhHg}{10.0.0.1}{10.0.0.1:9300}, added {{inner_es_node_01}{1BktktzhQ_y6BN-lNIKhHg}{10.0.0.1}{10.0.0.1:9300},}, reason: zen-disco-receive(from master [{inner_es_node_01}{1BktktzhQ_y6BN-lNIKhHg}{10.0.0.1}{10.0.0.1:9300}])

启动第二个节点后, 同样确认是否启动成功

curl http://10.0.0.1:9200/

{
  "name" : "inner_es_node_02",
  "cluster_name" : "inner_es_cluster",
  "version" : {
    "number" : "2.3.3",
    "build_hash" : "218bdf10790eef486ff2c41a3df5cfa32dadcfde",
    "build_timestamp" : "2016-05-17T15:40:04Z",
    "build_snapshot" : false,
    "lucene_version" : "5.5.0"
  },
  "tagline" : "You Know, for Search"
}

9. 正式启动

ctrl+c 关掉原先的进程

使用命令, 以daemon形式启动, 进程pid写入es.pid, 可以用于重启等

bin/elasticsearch -d -p es.pid
echo $?
0

查看对应进程是否启动

ps aux | grep elasticsearch

使用curl请求服务确定是否正常

curl http://10.0.0.1:9200/

或者, 更好的方式, 使用supervisord管理进程, 以下为supervisord.conf示例

[program:es]
directory=/data/LogTool/elasticsearch
command=/data/LogTool/elasticsearch/bin/elasticsearch
autostart=true
autorestart=true
stdout_logfile=/data/LogTool/elasticsearch/log/supervisord_es_out.log
stderr_logfile=/data/LogTool/elasticsearch/log/supervisord_es_err.log

10. 脑裂

单机测试开发的时候, 其实一个节点就够了. 上线, 使用两个节点, 目的是利用es本身的特性做到高可用.

但是两个节点是远远不够的. 启动后, 集群会选举一个master, 一切ok. 但是如果存在网络问题或者某个节点无响应(负载过高), 就会认为对方dead了, 然后两个节点自动选举为master, 在后续建索引的时候造成数据不一致.

两个节点防脑裂的配置, minimum_master_nodes决定了选主需要的最少节点数, N/2+1, 两个节点即2

discovery.zen.minimum_master_nodes: 2

但是, 此时一个节点挂了, 则整个集群挂了(无法选举主节点了)

所以, 要再加一个节点, 这个节点只要保证稳定即可, 对cpu和磁盘要求不高. 这个es节点的配置同其他节点的区别node.data: false, 不存储索引数据.

# split brain prevent
node.data: false

Logstash+ElasticSearch处理mysql慢查询日志

Tue, 24 May 2016 08:00:00 +0800

遇到一个需求, 需要查询某些业务的慢查询日志. 结果DBA平台那边提供的慢查询日志不能解决实际的业务场景(上报的字段补全), 无奈, 自己挽起袖子上

参考了这篇文章, 不过自己根据需求做了较多的变更

开始吧

1. 找到日志的位置

先确认是否开启了, 然后找到日志文件的位置

> show variables like '%slow%';
+---------------------+-------------------------------------+
| Variable_name       | Value                               |
+---------------------+-------------------------------------+
| log_slow_queries    | ON                                  |
| slow_launch_time    | 2                                   |
| slow_query_log      | ON                                  |
| slow_query_log_file | /data/mysqllog/20000/slow-query.log |
+---------------------+-------------------------------------+

2. 慢查询日志

格式基本是如下, 当然, 格式如果有差异, 需要根据具体格式进行小的修改

# Time: 160524  5:12:29
# User@Host: user_a[xxxx] @  [10.166.140.109]
# Query_time: 1.711086  Lock_time: 0.000040 Rows_sent: 385489  Rows_examined: 385489
use dbname;
SET timestamp=1464037949;
SELECT 1 from dbname;

3. 使用 logstash 采集

采集, 无非是用multiline进行多行解析

但是, 需要处理的几个问题

第一个是, 去除掉没用的信息

第二个, 慢查询sql, 是会反复出现的, 所以, 执行次数成了一个很重要的指标. 我们要做的, 就是降噪(将参数去掉, 涉及带引号的内容+数字), 将参数类信息过滤掉, 留下核心的sql, 然后计算出一个hash, 这样就可以在查询, 根据这个字段进行聚合. 这里用到了 mutate 以及 checksum

  # calculate unique hash
  mutate {
    add_field => {"sql_for_hash" => "%{sql}"}
  }
  mutate {
    gsub => [
        "sql_for_hash", "'.+?'", "",
        "sql_for_hash", "-?\d*\.{0,1}\d+", ""
    ]
  }
  checksum {
    algorithm => "md5"
    keys => ["sql_for_hash"]
  }

最后算出来的md5, 放入了logstash_checksum

第三个, 某些sql会非常大, 例如某些不规范的sql可能到几百M或是上G….会直接导致采集进程OOM, 所以, 处理时, 设定超过100k丢弃掉

第四个, 默认多行处理, 一条sql可能停留在采集端没有上报, 需要等到下一条sql进来, 这样是有问题的, 如果一直没有后续, 最后一条将不会进入引擎. 所以, 在配置中设定了超过5s自动上报

完整的logstash配置文件(具体使用可能需要根据自身日志格式做些小调整) 注意, 里面的pattern ALLWORD [\s\S]*

input {
  file {
    path => ["/data/mysqllog/20000/slow-query.log"]
    sincedb_path => "/data/LogNew/logstash/sincedb/mysql.sincedb"
    type => "mysql-slow-log"
    add_field => ["env", "PRODUCT"]
    codec => multiline {
      pattern => "^# User@Host:"
      negate => true
      what => previous
      max_bytes => "100kib"
      auto_flush_interval => 5
    }
  }
}
filter {
  if ("multiline_codec_max_bytes_reached" in [tags]) {
      drop {}
  }
  grok {
    # User@Host: logstash[logstash] @ localhost [127.0.0.1]
    # User@Host: logstash[logstash] @  [127.0.0.1]
    match => [ "message", "^# User@Host: %{ALLWORD:user}\[%{ALLWAORD}\] @ %{ALLWORD:dbhost}? \[%{IP:ip}\]" ]
  }
  grok {
    # Query_time: 102.413328  Lock_time: 0.000167 Rows_sent: 0  Rows_examined: 1970
    match => [ "message", "^# Query_time: %{NUMBER:duration:float}%{SPACE}Lock_time: %{NUMBER:lock_wait:float}%{SPACE}Rows_sent: %{NUMBER:results:int}%{SPACE}Rows_examined:%{SPACE}%{NUMBER:scanned:int}%{ALLWORD:sql}"]
  }

  # Capture the time the query happened
  grok {
    match => [ "message", "^SET timestamp=%{NUMBER:timestamp};" ]
  }
  # if codec multiline parse failure
  if ("_grokparsefailure" in [tags]) {
      drop {}
  }
  date {
    match => [ "timestamp", "UNIX" ]
  }

  mutate {
    gsub => [
        "sql", "\nSET timestamp=\d+?;\n", "",
        "sql", "\nuse [a-zA-Z0-9\-\_]+?;", "",
        "sql", "\n# Time: \d+\s+\d+:\d+:\d+", "",
        "sql", "\n/usr/local/mysql/bin/mysqld.+$", "",
        "sql", "\nTcp port:.+$", "",
        "sql", "\nTime .+$", ""
    ]
  }



  # calculate unique hash
  mutate {
    add_field => {"sql_for_hash" => "%{sql}"}
  }
  mutate {
    gsub => [
        "sql_for_hash", "'.+?'", "",
        "sql_for_hash", "-?\d*\.{0,1}\d+", ""
    ]
  }
  checksum {
    algorithm => "md5"
    keys => ["sql_for_hash"]
  }

  # Drop the captured timestamp field since it has been moved to the time of the event
  mutate {
    # TODO: remove the message field
    remove_field => ["timestamp", "message", "sql_for_hash"]
  }
}
output {
    #stdout{
    #    codec => rubydebug
    #}
    #if ("_grokparsefailure" not in [tags]) {
    #    stdout{
    #        codec => rubydebug
    #    }
    #}
    if ("_grokparsefailure" not in [tags]) {
        elasticsearch {
          hosts => ["192.168.1.1:9200"]
          index => "logstash-slowlog"
        }
    }
}

采集进去的内容

{
           "@timestamp" => "2016-05-23T21:12:59.000Z",
             "@version" => "1",
                 "tags" => [
        [0] "multiline"
    ],
                 "path" => "/Users/ken/tx/elk/logstash/data/slow_sql.log",
                 "host" => "Luna-mac-2.local",
                 "type" => "mysql-slow",
                  "env" => "PRODUCT",
                 "user" => "dba_bak_all_sel",
                   "ip" => "10.166.140.109",
             "duration" => 28.812601,
            "lock_wait" => 0.000132,
              "results" => 749414,
              "scanned" => 749414,
                  "sql" => "SELECT /*!40001 SQL_NO_CACHE */ * FROM `xxxxx`;",
    "logstash_checksum" => "3e3ccb89ee792de882a57e2bef6c5371"
}

4. 写查询

查询, 我们需要按logstash_checksum进行聚合, 然后按照次数由多到少降序展示, 同时, 每个logstash_checksum需要有一条具体的sql进行展示

通过 es 的 Top hits Aggregation 可以完美地解决这个查询需求

查询的query

body = {
    "from": 0,
    "size": 0,
    "query": {
        "filtered": {
            "query": {
                "match": {
                    "user": "test"
                }
            },
            "filter": {
                "range": {
                    "@timestamp": {
                        "gte": "now-1d",
                        "lte": "now"
                    }
                }
            }
        }
    },
    "aggs": {
        "top_errors": {
            "terms": {
                "field": "logstash_checksum",
                "size": 20
            },
            "aggs": {
                "top_error_hits": {
                    "top_hits": {
                        "sort": [
                            {
                                "@timestamp":{
                                    "order": "desc"
                                }
                            }
                        ],
                        "_source": {
                            "include": [
                               "user" , "sql", "logstash_checksum", "@timestamp", "duration", "lock_wait", "results", "scanned"
                            ]
                        },
                        "size" : 1
                    }
                }
            }
        }
    }
}

跟这个写法相关的几个参考链接: Terms Aggregation / Elasticsearch filter document group by field

5. 渲染页面

python的后台, 使用sqlparse包, 将sql进行格式化(换行/缩进/大小写), 再往前端传. sqlparse

>>> sql = 'select * from foo where id in (select id from bar);'
>>> print sqlparse.format(sql, reindent=True, keyword_case='upper')
SELECT *
FROM foo
WHERE id IN
  (SELECT id
   FROM bar);

然后在页面上, 使用js进行语法高亮 code-prettify

[分享]关于代码调试DE那些事

Thu, 12 May 2016 08:00:00 +0800

之前写过一篇博文, 做分享, 重新梳理了下

Logstash+ElasticSearch+Kibana- 实现相对通用的数据收集分析

Sun, 08 May 2016 08:00:00 +0800

ElasticSearch + Logstash + Kibana, 目前应该算是一套完整的日志收集/存储/统计解决方案.

在上一篇 Logstash+ElasticSearch+Kibana处理nginx访问日志中, 介绍了如何统一处理nginx日志

最近正好在做应用日志及上报日志的汇聚和统计工作, 分享下处理方式.

目标是: 一次搭建, 后面只需要关心输入(日志记录)以及输出(Kibana统计展示)

日志

日志的来源:

1. 服务日志: 服务端记录下来的日志, 例如搜索日志等, 内容较为详尽
2. 上报日志: 来自于前端/android/ios/桌面端等, 根据用户操作行为, 上报一些数据, 例如按钮点击量, 转化率等, 也可以上报崩溃日志

其中, 上报日志, 可以制定一套协议, 不同端统一走上报服务接口. 这个服务对性能有要求, 具体协议需要足够灵活, 支持各类统计分析需求. 使用golang写了一个 http_json_logger

日志在不同应用/机器记录后, 可以通过rsync/nfs/scp等, 汇总到一个地方进行统一处理, 也可以通过多个logstash shipper进行汇聚

关于日志格式, 统一使用json格式, 落地过程中包含平台{platform}, 以及项目{project}, 模块{module}, 落地时间ts等

为什么要落地: 落地成文件, 定时压缩备份存档, 不论日志处理系统是否有问题, 都能保证数据已经存下来了.

当然, 也可以考虑使用logstash监听端口, 分别落地到文件及转入es, 没具体实践过.

在这一步, 我的处理方案是:

1. 使用统一上报接口, 日志落地到上报服务的数据盘

2. 服务端服务日志, 同一台机器在相同数据盘, 使用同一个logstash shipper进行汇聚

对日志文件名等, 不强求一致性, 你可以认为, 不同项目/不同模块的json都可以直接记录到同一个日志文件(虽然不鼓励这么做), 通过日志body内容而不是日志文件名来处理

汇聚: logstash shipper

不得不说, logstash的确是神器

上一步, 日志中强制日志中每一行是一条json记录. 同时json body中记录了时间戳(timestamp, ts字段)

这一步, 配置 logstash将某些目录下的所有日志文件进行汇聚

配置示例:

input {
  file {
    path => [ "/data/collect/ios/*.log", "/data/collect/android/*.log", "/data/collect/web/*.log", "/data/collect/wap/*.log" ]
    start_position => "beginning"
    codec => json
  }
}

# make ts to @timestamp
filter {
  date {
    match => [ "ts" , "dd/MMM/YYYY:HH:mm:ss Z", "UNIX" ]
  }
}


output {
    redis { host => "127.0.0.1" data_type => "list" key => "logstash:collect:log" }
}

这时候, 所有日志集中到了一个地方

处理并存储到es

首先, 从redis中读取消息体, 检查并丢弃一些信息, 然后, 根据消息体内platform/ project/module, 分配到es不同的index 可以根据需要控制粒度

配置示例

input {
  redis {
    host => "127.0.0.1"
    port => "6379"
    key => "logstash:collect:log"
    data_type => "list"
    codec  => "json"
    type => "logstash-collect-log"
    tags => ["collect"]
  }
}


# drop invalid record
filter {
    if ![platform] {
        drop {}
    }
    if ![project] {
        drop {}
    }
    if ![module] {
        drop {}
    }
}

output {
    elasticsearch {
      host => "127.0.0.1"
      index => "%{platform}-%{project}-%{module}-%{+YYYY.MM.dd}"
    }
}

ES

你会发现, es已经的index中已经有了具体的数据. json中的每个字段都有……

然后呢?

整套调通之后, 接下来的工作呢?

假设来了个统计需求

分析需求, 拆解, 确定统计维度, 需要上报的字段等, 根据协议, 确定{platform}/{project}/{module}
前端/客户端等, 根据协议, 调用上报接口, 执行数据上报
到kibana, 找到对应index, 根据需求配置对应的展现

所有的一般性统计需求, 都可以通过三板斧直接搞定, 只需处理输入以及输出, 没有任何额外工作.

最后

目前量不大, 完美解决了快速迭代中各类原先处理起来十分困难的统计需求和日志分析(原来要自己上报汇聚数据, 自己拷贝到同一台机器, 自己写统计脚本, 存库, 还得自己撸前端, 搞完之后还被黑说: 花了那么多时间, 只搞出个这么反人类的/丑/不是我想要的.....界面)

当然, 随着业务发展, 各类日志的量都会逐渐上来, 对性能/存储的要求会越来越高, 但是elk本身对横向扩容只是非常完美, 在相当长一段时间内, 应该可以hold住.(老大, 我要加机器/硬盘/内存/CPU)

ok, 先这些

wklken

2015-05-08 于深圳

ELK维护的一些点(二)

Sat, 07 May 2016 08:00:00 +0800

很杂, 涉及到最近处理的一些点

根据string转浮点数的某个字段排序

一个字段, resp_time, mapping中是string, 有需求是, 按照响应时间降序排序, 此时需要构造qsl(在search中使用), 使用该字段转换为浮点数, 降序排列

第一步, 修改es配置, 增加groovy支持

elasticsearch.yml中加入

script.engine.groovy.inline.search: on

然后, 执行 rolling restart, 逐一重启集群每个节点

第二步, 构造qsl, sort中, 增加_script 使用groovy脚本, 将对应字段从string转成数字, 再进行排序

'sort': [{'_script': {'lang': 'groovy',
                       'order': 'desc',
                       'script': 'Float.parseFloat(doc["resp_time"].value)',
                       'type': 'number'}},
          {'@timestamp': 'desc'}
          ]

附 scripting文档

`fielddata-format-disabled`导致的排序失效

有个集群, 升级后, 发现resp_time字段的mapping是

"resp_time" : {
"type" : "string",
"norms" : {
    "enabled" : false
},
"fielddata" : {
    "format" : "disabled"
},
"fields" : {
    "raw" : {
    "type" : "string",
    "index" : "not_analyzed",
    "ignore_above" : 256
    }
}

注意这里的, 是因为升级es 2.0之后, 默认值变更带来的问题

"fielddata" : {
  "format" : "disabled"
},

fielddata文档

此时, 排序的qsl将会报错, 无法按照对应要求排序

Field data loading is forbidden on resp_time

解决方案, 挺简单的, 使用foo.raw即可

'sort': [{'_script': {'lang': 'groovy',
    'order': 'desc',
    'script': 'Float.parseFloat(doc["resp_time.raw"].value)',
    'type': 'number'}},
{'@timestamp': 'desc'}
]

使用聚合

把string类型的resp_time放到aggs中做聚合的时候.

"aggs": {
     "resp_time_stats": {"stats": {"script": 'Float.parseFloat(doc["resp_time.raw"].value)'}}
}

此时, 会报错

{u'error': {u'failed_shards': [{u'index': u'logstash-2016.04.10',
                                u'node': u'AvemqKN-RGKy68zJXUapBg',
                                u'reason': {u'reason': u'scripts of type [inline], operation [aggs] and lang [groovy] are disabled',
                                            u'type': u'script_exception'},
                                u'shard': 0}],
            u'grouped': True,
            u'phase': u'query',
            u'reason': u'all shards failed',
            u'root_cause': [{u'reason': u'scripts of type [inline], operation [aggs] and lang [groovy] are disabled',
                             u'type': u'script_exception'}],
            u'type': u'search_phase_execution_exception'},
 u'status': 500}

处理, es加配置, 逐一重启

script.engine.groovy.inline.aggs: on

logstash grok default patterns

默认的一些pattern, 见 grok-patterns

grok检查在线实时编辑, https://grokdebug.herokuapp.com/

logstash codec multiline 限制行数和日志大小

配置, 具体见 multiline文档

input {
        codec => multiline {
            patterns_dir => "./patterns"
            pattern => ""
            what => "previous"
            negate  => true
            max_lines => 100
            max_bytes => "50kib"
        }
}

单位 bytes

实践中, 使用max_bytes, 当what=previous + negate=true的情况下, 即不匹配模式的, 归属前一部分, 这种情况下, 性能ok, 反之what=next + negate=true的情况下, 不匹配成功归属于后半部分, 此时产生的cpu消耗非常之大, 可以将一台机器跑满.

另外, 假设配置max_bytes=1M, 此时用户打了50M, 会给这个event打上tag multiline_codec_max_bytes_reache, 但是, 这50M 最终还是会经logstash灌入到es里面. 即, 超了, 但是并不自动截掉

这时候, 我们可以, 使用mutate-replace直接替换掉

    # if multiline_codec_max_lines_reached
    if ("multiline_codec_max_bytes_reached" in [tags]) {
        mutate {
            replace => {
                "message" => "Log System Warnning: multiline_codec_max_lines_reached, Your log has exceeded 50kB(51200 chars), it was blocked by log system. Please check your code to make your log info shorter and useful"
                "msg" => "Log System Warnning: multiline_codec_max_lines_reached, Your log has exceeded 50kB(51200 chars), it was blocked by log system. Please check your code to make your log info shorter and useful"
            }
        }
    }

使用supervisord管理logstash进程

之前提到, 升级集群后, 使用supervisord统一管理logstash进程, 链接

查看当前机器logstash进程top

有时, 需要上机器看看对应采集端所有logstash进程是否存在问题, 常常用到top命令, 所以写了个简单的脚本, 配合supervisord的脚本使用

ltop.sh

#!/bin/bash
./logstashd.sh status
top -p $(./logstashd.sh status | awk '{print $4}' | awk -F',' '{print $1}' | tr '\n' ',' | sed 's/,$//g')

进程占用cpu检测脚本

#!/bin/bash
BASEDIR=$(dirname $0)
cd $BASEDIR
CURRENT_DIR=`pwd`

exec >> /tmp/log/monitor.log 2>&1
echo "=============================================="
date
function check() {
    PNAME=$1
    PID=$2
    CPU_USE=$(ps -p $PID -o %cpu | sed -n '2p')
    INT_CPU_USE=$(printf "%.0f\n" $CPU_USE)
    echo $PNAME" - "$CPU_USE" - "$INT_CPU_USE

    if [ $INT_CPU_USE -gt 85 ]
    then
       echo "$PNAME cpu usage greater than 85%,do restart"
       ./logstashd.sh restart $PNAME
    fi
}
export -f check
./logstashd.sh status | awk '{print "-", $1, $4}' | awk -F',' '{print $1}' | xargs -n3 bash -c 'check $@'

数据盘满了导致集群状态yellow

机器节点本身有1T 硬盘, 由两块盘组成, 配置es的时候, 数据分别写到了两个盘上, 然后有一天集群状态告警了

"status" : "yellow",

查看es的日志

[2016-03-21 12:43:45,934][INFO ][cluster.routing.allocation.decider] [node_01] low disk watermark [85%] exceeded
on [AvemqKN-RGKy68zJXUapBg][node_01][/data/LogNewData/xxx/nodes/0] free: 75.5gb[14.1%], replicas will not be assigned to this node

处理: 腾磁盘空间出来, es会自动检测恢复

PS: 磁盘大小要预估好

查看redis中队列的堆积

历史遗留问题, 有些节点采集发送到redis的key, 在indexer阶段并没有被消费, 导致越堆越多….

这时候, 可以通过redis查下哪些队列堆积了

bin/redis-cli -h 127.0.0.1 -p 6379 -a blueking_log --bigkeys

需要redis版本支持bigkeys => This is a “new” feature beginning with 2.8

解析失败丢弃及黑名单实现

grok解析失败, 丢弃

if ("_grokparsefailure" in [tags]) {
    drop {}
}

有时候, 需要禁止采集某些文件, 但由于file类型的exclude只能用文件名, 而没有更强大的规则, 所以只能采集进来再丢弃, 此时, 可以根据路径grok解析出关键字, 然后判断丢弃

if ([keyworod] in ["data", "not_exists"])
{
    drop {}
}

启动限制使用的worker数

默认情况, 有可能把所有cpu跑满, 这时候, 可以专门加下

-w, --pipeline-workers COUNT  Sets the number of pipeline workers to run. (default: 24)

logstash agent -f conf/xxx.conf -w 2

几个简单脚本

health.sh

#!/bin/bash
curl 'http://127.0.0.1:9200/_cluster/health?pretty=true'

indices.sh

#!/bin/bash
curl 'http://127.0.0.1:9200/_cat/indices?v' | sort -k 3

[分享]Python源码剖析-数据结构

Tue, 01 Mar 2016 08:00:00 +0800

一些Centos Python生产环境的部署命令

Thu, 18 Feb 2016 08:00:00 +0800

Just notes

拿到一台干净的centos之后, 初始化Python环境, 一些命令和问题记录而已

可以搞成脚本自动初始化, 当然, 用docker更好

基础环境

1. 创建用户

sudo adduser newuser
sudo passwd newuser

# 设置授权不需要输入密码
sudo /usr/sbin/visudo
newuser       ALL=NOPASSWD: ALL

2. EPEL(Fedora Extra Packages for Enterprise Linux repository )

参考文档

wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
sudo rpm -Uvh epel-release-6*.rpm

3. 加ius源

包地址

wget http://dl.iuscommunity.org/pub/ius/stable/CentOS/6/x86_64/ius-release-1.0-13.ius.centos6.noarch.rpm
sudo rpm -Uvh ius-release-1.0-13.ius.centos6.noarch.rpm

4. 安装python2.7 / python3 / pip

sudo yum install python27
sudo yum install python27-devel

then

curl https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py | sudo /usr/bin/python2.7 -

# pip
curl https://raw.githubusercontent.com/pypa/pip/master/contrib/get-pip.py | sudo /usr/bin/python2.7 -

extra: install python3

sudo yum install python34u python34u-devel

5. virtualenv

sudo pip install virtualenv

6. gen ssh key

ssh-keygen -t rsa

add ~/.ssh/id_rsa.pub to git or github

一些服务

1. install git

sudo yum install git

2. mysql

sudo yum install mysql
sudo yum install mysql-devel* -y
sudo yum install mysql-server
sudo /sbin/service mysqld start

3. redis

sudo yum install redis

4. rabbitmq

sudo yum install rabbitmq-server

问题

[Errno 14] Peer cert cannot be verified or peer cert invalid

add “sslverify=false” in /etc/yum.conf

pip error: ImportError: cannot import name HTTPSHandler

yum install openssl openssl-devel -y

see in sof

MySQL-python

    _mysql.c:2642: error: initializer element is not constant
    _mysql.c:2642: error: (near initialization for ‘_mysql_ResultObject_memberlist[0].offset’)
    _mysql.c: In function ‘_mysql_ConnectionObject_getattr’:
    _mysql.c:2666: error: ‘_mysql_ConnectionObject’ has no member named ‘open’
    error: command 'gcc' failed with exit status 1

    ----------------------------------------
Command "/data/home/alarm/env/bin/python -c "import setuptools, tokenize;__file__='/tmp/pip-build-HgXAQT/MySQL-python/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-kx2cSu-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-build-HgXAQT/MySQL-python

处理: yum install mysql-devel

摘录<<6个月学会任何一种外语>>

Wed, 17 Feb 2016 08:00:00 +0800

在高铁上顺手刷完的一本书, 学习英语的方法论吧, 和学习编程有很多类似的地方, 互相印证.

还是值得一读的, 建议想掌握英文的同学买一本读一读

额, 英文这个问题困扰了我很久, 当然, 学习的主要目的是能更快更好的读懂文档以及进行一些基本交流(其实是为了刷电影美剧更方便些ORZ)

从去年开始就实行泡脑子的策略, 上下班各半个小时, 反复在听老友记十季的音频(安利app: 喜马拉雅). 然后固定在刷几部美剧, 买了本英文著作一字一句反复读中, 也开始在国外的论坛提问题, 发言, 用kindle开启生词模式在刷书. 当然, 俺的英文还是别别扭扭的…..

程序员的一大优势是, 文档/搜索, 基本都是英文的, 这个环境还是不错的, 另外, mac/iphone/ipad全部切成英文系统, 取词软件全开, 哈哈哈…..

然而, 还是不会说啊…..痛定思痛

以下读书摘要

观点

本书的观点

我特别主张自然规律，你越能理解和运用自然规律，你就越能成功
一个大脑健全的成年人完全有能力在6个月内从0掌握任何一种外语！
只要掌握规律，跟随规律去练习，一个人能做到的结果，任何人都能做到！

长期误解的错误的观点

有语言天赋的人才能学会外语
到国外待一段时间就能学会外语

掌握一种外语的标准

（1）你已经掌握了有关语言的最高频单词和词组，你能听懂，也能自己独立使用。在外语里边，掌握1000个最高频词，完全满足日常生活沟通所需的85%，3000个高频词可以覆盖日常沟通、工作及商务交流的98%以上。
（2）你完全可以很自然地使用你已经会的词组和单词，来创造你想说的任何句子，沟通你想表达的意思。当然，有时候你会找不到最确切和最巧妙的说法，但是你完全有能力找到能用的词来表达你想说的东西。
（3）听到陌生单词的时候，你会轻松地邀请别人解释给你听。而在这个过程当中，你完全有能力用外语来了解和接受这个新的概念。同时，你也有能力吸收这个概念带给你的生词。
（4）你的发音已经接近母语者。可能有的地方不是100%一样，但是这些绝对不会对你的沟通造成阻碍。
（5）你说外语的节奏、速度、轻重、停顿等，已经完全符合外语母语者的习惯，而且你在说的时候，总是感到很自然。你也会很恰当地用礼节和最普遍的感叹方式来进行日常“共鸣”，从而达到友好沟通的目的。
（6）你已经完全掌握了新的肢体语言的表达方式，包括一些面部表情、不同手势等。
（7）你已经建立了语感，在肚子里能知道哪些说法算是大家都认同的，也会感觉到哪些说法有一点儿偏离大家习惯的规矩。
（8）同时，为了学得更快，你也要懂得累了就休息。

学会外语的五项核心原则

从和你有密切关联的外语内容学起: 只要信息跟你个人没有重要关联，你就自然会觉得没有重要意义，因此不会给注意力。不给注意力的自然结果是记不得、学得慢甚至学不会。反之，任何对你本人有重要意义的信息，都会引起你的注意，并且当你可以给它足够注意力时，你就会自然而然学得特别快 => 结论: 为了把外语学好，你要找到这门外语跟你的重要关联。在学习时，你一定要选择跟自己的兴趣、动力有重要关联的外语内容

和学习技术挺类似, 技术深入以及眼界扩展, 从自己工作内容相关的东西开始才能事半功倍, 才能有效率

把外语当成沟通工具: 1. 把外语当成工具，会让你通过“用”来学外语，而不是先学后用. 把外语当成沟通工具的第一个必然结果是，只要你会一点，就会马上去用，从而体验这个工具发挥的效力。2. 把外语当成工具，会让你从功能出发，把形式放在后面学通过用外语来学外语的关键，是把自己的注意力先放在单词和词组的功能。这样，你会先用功能最明显的几个单词和词组来沟通，不让形式成为卡住自己学习的节点。3. 把外语当成工具，会让你自然接受多种说法，因此不拘泥于一个“标准答案” 4. 把外语当成工具，可以获取“反馈”带来的巨大帮助，因此效果好

做技术的这种机会还是比较多的. 从实践中学习, 在实践中验证理论.

理解了含义，自然能“获取”外语: 1. 可理解输入就是首先理解含义，然后下意识自动“获取”外语的过程。为了把你的外语学习速度加快，你需要在学习的过程中，给自己创造可理解输入的条件。2. 相信自己的潜意识学外语的能力
生理训练为主: 要学好外语，更重要的是要进行合适的生理训练，也就是说，外语学习的一个非常重要的部分，是训练大脑神经和外语肌肉。与练健美体操一样，练好外语的过程是一个肌肉训练的过程。1. 一定要用足够时间锻炼耳朵里的外语听觉神经！ 2. 发音训练绝对是肌肉训练的一个过程，因此要用体育训练的思路，指导自己找对路，这包括经常练，同时在练习的过程中注意动作的准确度。3. 创造外语条件反射！
掌握好心理状态: 用深度放松的状态来学习, 保持良好学习状态的另外一个重要因素，就是管理自己的渴望。必须开心忍受听不懂的阶段

学会外语的七个关键行为

多听——快速长好“外语DNA”: “泡脑子”表面的意思很简单，就是说要把自己的大脑“泡”在外语的声音里。除此之外，也有一些自我管理的方式和态度方面的问题需要注意，这样才能把“泡脑子”的作用发挥到极致。
先认识含义，后明白词: 作为学外语的成年人，也必须运用这个基本原理。不管怎么样，要把注意力先放在明白含义上，在这个基础上，你的大脑就很容易吸收你正在学的语言。换句话说，为了学会外语，要先懂意思，不是为了懂意思要先学会外语！肢体语言/整体环境和场景/通过已知”获取”未知/
大胆组合，大量去用
从核心高频内容开始学起: 为了把英语学得透彻，并且达到完全像母语者一样，根本不需要学那么多，更不需要同时什么都学，只需要把注意力放在外语的核心，掌握外语的高频词即可。所谓高频词就是沟通中出现频率高的外语单词，高频词是外语沟通的核心。所以，学到8000个单词以后，你的英文水平已经和普通的英语母语者一样好！外语学习内容贵精不贵多，学习的过程一定要遵守质量第一，数量第二的原则的
找一个好的外语家长
掌握发音的绝招: 除了听声音并调整自己面部肌肉之外，练发音的时候，还有一个“绝招”能用，就是“看脸说话”，意思是模仿外语母语者的面部和口型来练发音。
一个盒子两条路（Same Box-Different Path）: 我相信你很清楚，为了真正会外语，迟早必须懂得用外语思考。也就是说，自己的大脑能够直接将头脑中的意义联结到外语的声音。根本不需要经过中文翻译. 只有把外语的声音和内心的画面含义联结到一起，才是下意识高效率的学习，也就是用外语沟通的时候，自己沟通的感觉和效果与说母语一样。其实所谓“外语思维”就是这个意思——听到外语，在头脑中看到画面，同时注意到自己的感觉，说话时也是直接从画面和感觉联结到外语. “同一个盒子，两条路”的主要含义，来自于我们对人类大脑处理信息的科学认识。人对世界的认识和记忆，最主要来源不是文字或语言，更基层的，是神经层面的5种感觉，包括：视觉、听觉、触觉、嗅觉和味觉。方法: 故意创造和运用画面/用比喻找到含义的本质/找到沟通的对象, 用外语交流/

通过已知获取未知, 有点类似如何高效学习中提到的观点, 建立高速公路, 建立关联, 比喻.

还有, kindle中生词模式就是类似这样的….

外语家长, 其实类似mentor的角色, 虽然多年以来….还有, 实际的code review

具体的学习计划

自己看书吧, 有挺多借鉴的地方

不过, 对于我这个散漫闲人, 严格按部就班有些困难, 所以, 只能培养所谓的习惯, 侵占覆盖掉碎片时间, 同时把相关的方法论给践行了, 至于效果, 额, 过段时间看看……

一些书中提到的习惯

习惯一：开始用自己的右脑，调整到每天进入英语频道。
习惯二：想到任何关于英语问题的时候，自动想起如何用英语发问。
习惯三：把自己的耳朵和嘴巴连接起来，变成一个“发音准确度反馈循环”。
习惯四：把英语声音直接连接到脑海中的画面和感觉。
习惯五：把玩词变成每天的习惯和乐趣。拼凑词，创造含义。
习惯六：完全建立自言自语的习惯
习惯七：每天用英语开口说话，进行真实沟通。
习惯八：随时开口练习发音。

ELK 维护的一些点

Tue, 16 Feb 2016 08:00:00 +0800

去年入职新公司之后, 负责维护平台的elk

这套东西是2013年搭建的, 年久失修, 所以做了个方案, 开始了批量升级

将logstash从1.3升级到2.1, 将elasticsearch从1.4.1升级到2.0

期间踩了很多坑, 搞了一个多月, 总算搞完

从纯手工落后隔三差五有人找查问题的自行车, 改成自动化最新版本新架构运维便捷上了两个月无人反馈的, 额, 小汽车:) - 集成安装包/shell脚本/fabric实现部署/升级/增删/加黑名单等等功能

每天日志量大概10G上下, 几十个采集端, 两个redis, 两个indexer, 两台es机器扛起

以下, 不那么严谨地, 记录一些遇到的问题

1. logstash升级策略

logstash1.3到2.x, 变化点还是很多的

所以, 首先第一步要去阅读官方文档, 将所有change log过一遍, 对一些关键性的东西进行了解, 比如, 干掉了哪些语法(旧的功能需要如何实现), 哪些语法有变更, 新增了哪些特性等.

然后, 将线上不同类型agent的配置文件拉下来, 先, 归类, 然后, 开始改-测-改-测-直到测试通过

bin/logstash agent -t -f test.conf

直到, 语法验证通过

现在要做的是, 验证数据正确性

从线上拉取对应日志, 启动, 查看输出

output {
    stdout{
        debug => true
    }
}

这里需要验证的是, 1. 过滤, 该过滤的过滤了 2. 转换, 该转换的转换了 3.新增, 新增字段

注意, 测试时, 使用逻辑分支覆盖到所有配置文件中的分支即可.

然后, 可以挑一台机器, 停老的服务, 部署新的服务进行测试

建议, 部署agent的时候, 如果读的是文件, 建议配置sincedb_path 这样假设下次升级, 就可以从老的服务最后读取的位置开始了

input {
    file {
        path => ["/data/logs/*.log"]
        sincedb_path => "/data/LogNew/logstash/sincedb/celery.sincedb"
    }
}

2. elasticsearch升级的策略

elasticsearch从1.4到2.0, 部署上变化不大, 变化最大的是存储doc的schema变了……

使用原来的语法查询, 发现查不到, 因为字段名以及嵌套层级完全不一样了, 这里, 要修改查询端, 兼容新老版本的格式

{'from': 0,
 'query': {'filtered': {'filter': {'bool': {'must': [{'bool': {'should': [{'term': {'type': 'app'}},
                                                                          {'term': {'@type': 'app'}}]}},
                                                     {'bool': {'should': [{'term': {'log_level': u'error'}},
                                                                          {'term': {'@fields.log_level': u'error'}}]}},
                                                     {'range': {'@timestamp': {'gt': 'now-5h'}}},
                                                     {'bool': {'should': [{'term': {'log_type': u'celery'}},
                                                                          {'term': {'@fields.log_type': u'celery'}}]}}]}}}},
 'size': 100,
 'sort': [{'@timestamp': 'desc'}]}

另一个是, 取到数据进行解析的时候, 发现解析逻辑跪了, 没办法, 返回的json也完全变了, 这里, 要修改解析逻辑, 兼容新老版本格式

for hit in log_hits:
    try:
        source = hit.get('_source')
        if '@fields' in source:
            log = source.get('@fields', {})
        else:
            log = source

为了让用户感觉不到集群升级, 首先要做的就是上面两个变更

然后, 搭建新的集群, 最好找新的机器搭建(我在新的机器搭完才发现妈蛋硬盘才100G, 坑死, 无奈在老集群上搭新的集群, 硬盘1t)

ready, 所有节点起好维护好, 然后, 改indexer, 将同一份日志灌到两个集群

output {
    elasticsearch {
        hosts => ["10.1.1.1:9100", "10.1.1.2:9100"]
    }
    elasticsearch {
        hosts => ["10.1.1.1:9110", "10.1.1.2:9110"]
    }
}

简单测试下, 没问题就放着甭管了, 等数据攒齐了….

数据够了, 就, 停indexer, 停老集群, 停新集群, 改新集群端口, 起来….同时去掉indexer只输出到新的集群, 起来……测试, 切换完毕, 收工吧.

优化点: 集成安装包和supervisord

额, logstash和es, 如果要配置节点, 其实还是挺蛋疼的

要做的, 就是, logstash+不同类型配置文件+运维脚本, 达成一个包

然后, 如果要部署一台机器, 扔上去一键执行安装, 测试, 启动即可

例如, 运维脚本 logstashd.sh

#!/bin/bash

BASEDIR=$(dirname $0)
cd $BASEDIR
CURRENT_DIR=`pwd`

function help_msg() {
    echo "===================== usage ====================="
    echo "./logstashd.sh  - enter command line"
    echo "./logstashd.sh status - show all configured process"
    echo "./logstashd.sh start ${name} - start program"
    echo "./logstashd.sh stop ${name} - stop program"
    echo "./logstashd.sh restart ${name} - restart program"
    echo "./logstashd.sh reread && ./logstashd.sh update - update config and just update the modified programs"
    echo "./logstashd.sh reload - reload config files and restart all programs(stopeed not included)"
    echo "================================================="
    echo ""
}

if [ "${1}" = "-h" -o "${1}" = "--help" ]
then
    help_msg
    exit 0
fi

SUPERVISORCTL='/data/LogNew/python27/bin/supervisorctl'

CONFIG_FILE_PATH="${CURRENT_DIR}/conf/supervisord.conf"

$SUPERVISORCTL -c $CONFIG_FILE_PATH $@

使用

./logstashd.sh
===================== usage =====================
./logstashd.sh  - enter command line
./logstashd.sh status - show all configured process
./logstashd.sh start  - start program
./logstashd.sh stop  - stop program
./logstashd.sh restart  - restart program
./logstashd.sh reread && ./logstashd.sh update - update config and just update the modified programs
./logstashd.sh reload - reload config files and restart all programs(stopeed not included)
=================================================

111_indexer                      RUNNING   pid 27058, uptime 1:25:10
indexer                          RUNNING   pid 24731, uptime 1:31:29
supervisor> restart indexer

这里, 我引入了stackless python (独立), 然后装pip/supervisord, 使用supervisord对logstash/es进程进行管理

使用supervisord管理进程, 有个注意点

默认supervisord相关的文件在

/tmp/supervisor*

而线上, 存在tmp被删/清理了情况, 导致要进行进程启停操作才发现,妈蛋找不到

处理方式 => 放到集成安装包的run目录下

注意点: logstash存在两个output时, 必须要保证二者的可用性

logstash indexer, 分别转发数据到两个不同的output

output {
    elasticsearch {
        hosts => ["10.1.1.1:8080", "10.1.1.2:8080"]
    }
    redis {
        host => "10.1.1.3"
        port => 6379
        password => "7oEsjqUNoTdgE4"
        data_type => "list"
        key => "log_queue"
        db => 0
        batch => true
    }
}

此时, 若是redis挂了, 则日志也不会刷到es中, 所以, 需要同时保证所有output的可用性

对于redis, 可以进行进程监控, 发现挂了的话, 告警并同时重启(可以crontab一分钟检查一次)

优化点: ELK增加agent_ip字段

需求: 在实际使用中, 有时候需要反向根据查询结果, 获知日志的来源机器

处理:

1.先获取ip

GetLanIp () {
     ## get associated LAN ip address
     ## usage: GetLanIp
     /sbin/ifconfig | awk '
         /eth/{
             getline;
             if (/inet addr:(172|10|192)\./) {
                 gsub(".*addr:|  *Bcast.*","");
                 print $0;
                 exit;
             }
         }'
     return 0
}

2.放入环境变量

ETH1_IP=10.1.1.1

3.修改logstash配置

注意, 这里是logstash2.x的语法

    environment {
        add_metadata_from_env => ["agent_ip", "ETH1_IP"]
        add_field => {"agent_ip" =>  "%{[@metadata][agent_ip]}" }
    }

问题: elk的utc问题

elasticsearch内部使用的是utc, 存储为long (milliseconds since the epoch) e.g. timestamp=1420070400000

可以看下 es 时间处理

logstash 接受了这种设定, 往es传数据的时候, 根据UTC, 每天00:00新建一个index

kibana也接受这种设定, 在查询和展示时根据用户的时区进行处理

问题描述

这导致了, 对于东八区, 2015-11-6日, 8点之前, 只有logstash-2015.11.05这个index, 到8点的时候, 创建新的index logstash-2015.11.06, 即, 对于我们这个时区的人来说, 一天的数据存在了两个index里面

同类问题 Elasticsearch doesn’t care about timezone and creates indexes with UTC

修正方案1: 修改logstash的数据时间

logstash团队对于支持localtime的问题, 不予修复讨论, 但是可以自行去修改logstash的代码

当然, 可以修改每个logstash indexer的时间, 但是会带来问题问题: 1. logstash都要修改getLocalTime 2.相对时间搜索 3. kibana等相关插件/组件要修正

运维/升级和后续使用上会有很多地雷

修正方案2: 不修正

接受这种设定, 学习kibana, 类似自行确定要搜索的index 对于00:00-08:00的, 程序处理使用昨天的indexer

所以, 更好的方式是, 不修正……原来不变的才是最好的

rolling restart

当存在配置变更时, 需要重启es集群, 不可能全部重启的, 这样会导致服务不可用….

所以, 要一个个重启

先执行

curl -XPUT 'http://localhost:9200/_cluster/settings' -d '
{
    "transient" : {
        "cluster.routing.allocation.enable" : "none"
    }
}'

然后, shutdown, 改配置, start

then : 一定要记得执行, 否则不会执行recovery…..会一直等着

curl -XPUT 'http://localhost:9200/_cluster/settings' -d '
{
    "transient" : {
        "cluster.routing.allocation.enable" : "all"
    }
}'

logstash文本解析配置grok语法

一个线上的工具, https://grokdebug.herokuapp.com/

挺好用的, 但是有时候变更频繁相应有些缓慢

暂时没有找到命令行工具

坑: GROK语法

上线后发现, 尼玛, 部分应用日志没有被采集

定位发现, 原来在grok的解析中使用了WORD

而 WORD: 不支持连字符和下划线

跪了, 需要自定义LOGFILENAME [a-z\-A-Z0-9_\.]+放到pattern中

然后, 搜索的时候, 尼玛, 也搜不到….语法要做处理, 使用raw, es建索引的时候自动拆掉了导致搜索不到

{'term': {'app_name.raw': 'nms-t'}}

做一些exclude

有时候需要做一些exclude, 去除比必要采集和监控的日志(进入采集逻辑纯粹是浪费cpu和内存)

例如, 目录树, 不要监控celery.log

logs
├── a
│   ├── a.log
│   ├── b.log
│   └── celery.log
└── b
    ├── c.log
        └── d.log

排除部分文件

file {
    path => ["/data/logs/*/*.log"]
    exclude => ["celery.log", ]
    sincedb_path => "/data/LogNew/logstash/sincedb/django.sincedb"
}

文档

一些相关用到的命令

查看plugin版本

https://www.elastic.co/guide/en/logstash/current/working-with-plugins.html

bin/plugin list --verbose

create empty index

curl -XPUT 'http://localhost:9100/logstash-2015.12.15/'

查看健康度

curl 'http://localhost:9100/_cluster/health?pretty=true'

查看indices

#!/bin/bash

curl 'http://localhost:9100/_cat/indices?v' | sort -k 3

删除30天前crontab脚本

#!/bin/bash

now=`date +%Y%m%d`
echo $now
days_30_before=`date -d "$now 31 days ago" +%Y.%m.%d`
echo $days_30_before
echo "http://10.1.1.1:9100/logstash-$days_30_before"
curl -XDELETE "http://10.1.1.1:9100/logstash-$days_30_before" > /dev/null 2>&1

尚未处理

logstash2.1 muline codec, 配置多个数据来源, 存在串的情况, 生产中大数据量有, 小规模没有复现….

好了, 先这些, 还有一些窝在某些目录下, 后续整理好了发

wklken

2016-02-16

也许是一个新的开始

Tue, 16 Feb 2016 08:00:00 +0800

也许是一个新的开始吧.

原先写blog都是深思熟虑, 偶尔发发微博, 以及几乎不发朋友圈…..

年后, 发现, 其实blog就是个个人吐吐槽, 以及一些积累的地方, 深思熟虑个蛋(好多笔记, 半成品等等蹲在wiki里不见天日, 也不见得有时间完善好)

所以, 打算开启话唠模式. 至于那些不是很"深思熟虑"的东西, 通过长时间不断迭代来优化吧, 然后会有一些吐槽什么的.

不大确定有多少人订阅了, 可以取关哈:)

从此, 不想太多, 看看今年的产出吧. 当然, 尽量保质保量.

从此文开始(够短吧)

2016-02-16 于深圳

一些vim的个性化配置

Wed, 03 Feb 2016 08:00:00 +0800

在咖啡馆kill time, 时间不多但实在无聊, 随便写写

入坑vim, 四年有余了

自从2012年将自己的配置发布到github后, 持续性的维护着, 逐步解决一些使用中的痛点, 反直觉的东西, 慢慢形成了现有的配置.

k-vim

以下, 就列下, 在k-vim中, 做了哪些配置, 下面这些在 vimrc 中都可以找到

首先, 一上来就把leader键改掉

" 修改leader键
let mapleader = ','
let g:mapleader = ','

移动时, 保留到底部的空间

" 在上下移动光标时，光标的上方或下方至少会保留显示的行数
set scrolloff=7

自定义代码折叠toggle

" 代码折叠自定义快捷键 zz
let g:FoldMethod = 0
map zz :call ToggleFold()
fun! ToggleFold()
    if g:FoldMethod == 0
        exe "normal! zM"
        let g:FoldMethod = 1
    else
        exe "normal! zR"
        let g:FoldMethod = 0
    endif
endfun

ctrl-n进行相对行号/绝对行号切换

" 相对行号: 行号变成相对，可以用 nj/nk 进行跳转
set relativenumber number
au FocusLost * :set norelativenumber number
au FocusGained * :set relativenumber
" 插入模式下用绝对行号, 普通模式下用相对
autocmd InsertEnter * :set norelativenumber number
autocmd InsertLeave * :set relativenumber
function! NumberToggle()
  if(&relativenumber == 1)
    set norelativenumber number
  else
    set relativenumber
  endif
endfunc
nnoremap  :call NumberToggle()

quickfix的使用, 回车跳转到报错点, s或v分屏打开

" In the quickfix window,  is used to jump to the error under the
" cursor, so undefine the mapping there.
autocmd BufReadPost quickfix nnoremap   
" quickfix window  s/v to open in split window,  ,gd/,jd => quickfix window => open it
autocmd BufReadPost quickfix nnoremap  v L
autocmd BufReadPost quickfix nnoremap  s K

打开vim, 自动定位到上次最后变更位置

" 打开自动定位到最后编辑的位置, 需要确认 .viminfo 当前用户可写
if has("autocmd")
  au BufReadPost * if line("'\"") > 1 && line("'\"") <= line("$") | exe "normal! g'\"" | endif
endif

干掉方向键, 强迫自己使用hjkl

" 关闭方向键, 强迫自己用 hjkl
map  
map  
map  
map

swap换行展示时, 使用hjkl体验更好

"Treat long lines as break lines (useful when moving around in them)
"se swap之后，同物理行上线直接跳
nnoremap k gk
nnoremap gk k
nnoremap j gj
nnoremap gj j

F键区的映射

" F2 行号开关，用于鼠标复制代码用
" 为方便复制，用开启/关闭行号显示:
function! HideNumber()
  if(&relativenumber == &number)
    set relativenumber! number!
  elseif(&number)
    set number!
  else
    set relativenumber!
  endif
  set number?
endfunc
nnoremap  :call HideNumber()

" F3 显示可打印字符开关
nnoremap  :set list! list?
" F4 换行开关
nnoremap  :set wrap! wrap?

set pastetoggle=            "    when in insert mode, press  to go to
                                "    paste mode, where you can paste mass data
                                "    that won't be autoindented

" disbale paste mode when leaving insert mode
au InsertLeave * set nopaste

" F6 语法开关，关闭语法可以加快大文件的展示
nnoremap  :exec exists('syntax_on') ? 'syn off' : 'syn on'

分屏窗口切换时, 直接使用ctrl-h/j/k/l

" 分屏窗口移动, Smart way to move between windows
map  j
map  k
map  h
map  l

多窗口编辑时, 临时放大某个窗口, 编辑完再切回原来的布局

" http://stackoverflow.com/questions/13194428/is-better-way-to-zoom-windows-in-vim-than-zoomwin
" Zoom / Restore window.
function! s:ZoomToggle() abort
    if exists('t:zoomed') && t:zoomed
        execute t:zoom_winrestcmd
        let t:zoomed = 0
    else
        let t:zoom_winrestcmd = winrestcmd()
        resize
        vertical resize
        let t:zoomed = 1
    endif
endfunction
command! ZoomToggle call s:ZoomToggle()
nnoremap  z :ZoomToggle

分号映射为冒号, 省得要进入命令模式需要按shift

" Map ; to : and save a million keystrokes 用于快速进入命令行
nnoremap ; :

H和L跳转到行首行末, 实在不想按0和$, 太远

" Go to home and end using capitalized directions
noremap H ^
noremap L $

命令行模式快捷键, ctrl-a/e跳转到行首行尾

" 命令行模式增强，ctrl - a到行首， -e 到行尾
cnoremap  
cnoremap  
cnoremap  
cnoremap

空格进入搜索

" 搜索相关
" Map  to / (search) and Ctrl- to ? (backwards search)
map  /
" 进入搜索Use sane regexes"
nnoremap / /\v
vnoremap / /\v

搜索时, 进入下一个上一个始终放在屏幕中间

" Keep search pattern at the center of the screen.
nnoremap  n nzz
nnoremap  N Nzz
nnoremap  * *zz
nnoremap  # #zz
nnoremap  g* g*zz

leader-/ 关闭掉上次搜索的高亮

" 去掉搜索高亮
noremap / :nohls

交换#和*, #更近

" switch # *
nnoremap # *
nnoremap * #

Python 写入注释#号时, 不每次都跳到行首

" for # indent, python文件中输入新行时#号注释不切回行首
autocmd BufNewFile,BufRead *.py inoremap # X#

buffer切换相关, 使用不多

" 切换前后buffer
nnoremap [b :bprevious
nnoremap ]b :bnext
" 使用方向键切换buffer
noremap  :bp
noremap  :bn

tab操作….看个人喜好, 不过自从用了crtlspace之后, 逐渐很少用了

" tab 操作
" http://vim.wikia.com/wiki/Alternative_tab_navigation
" http://stackoverflow.com/questions/2005214/switching-to-a-particular-tab-in-vim

" tab切换
map th :tabfirst
map tl :tablast

map tj :tabnext
map tk :tabprev
map tn :tabnext
map tp :tabprev

map te :tabedit
map td :tabclose
map tm :tabm

" normal模式下切换到确切的tab
noremap 1 1gt
noremap 2 2gt
noremap 3 3gt
noremap 4 4gt
noremap 5 5gt
noremap 6 6gt
noremap 7 7gt
noremap 8 8gt
noremap 9 9gt
noremap 0 :tablast

" Toggles between the active and last active tab "
" The first tab is always 1 "
let g:last_active_tab = 1
" nnoremap gt :execute 'tabnext ' . g:last_active_tab
" nnoremap   :execute 'tabnext ' . g:last_active_tab
" vnoremap   :execute 'tabnext ' . g:last_active_tab
nnoremap  tt :execute 'tabnext ' . g:last_active_tab
autocmd TabLeave * let g:last_active_tab = tabpagenr()

" 新建tab  Ctrl+t
nnoremap      :tabnew
inoremap      :tabnew

选中后, 调整缩进, 可能需要多次调整, 默认调整一次后退出了选中, 需要再次选.

这个变更, 保证调整缩进后, 还是选中状态

" 调整缩进后自动选中，方便再次操作
vnoremap <  >gv

复制动作的变更, Y, 复制到行末

" y$ -> Y Make Y behave like other capitals
map Y y$

" 复制选中区到系统剪切板中
vnoremap y "+y

选中全部/选中段落

" select all
map sa ggVG"

" select block
nnoremap v V`}

保存, 没权限的时候

" w!! to sudo & write a file
cmap w!! w !sudo tee >/dev/null %

使用kj, 替换ESC

" kj 替换 Esc
inoremap kj

调整Ctrl-e/y滚动

" 滚动Speed up scrolling of the viewport slightly
nnoremap  2
nnoremap  2

快捷保存和退出leader-q/w

" Quickly close the current window
nnoremap q :q

" Quickly save the current file
nnoremap w :w

交换

" 交换 ' `, 使得可以快速使用'跳到marked位置
nnoremap ' `
nnoremap ` '

变更U, 撤销重做的时候更快

" remap U to  for easier redo
nnoremap U

保存文件时, 自动移除多余空格

" 保存python文件时删除多余空格
fun! StripTrailingWhitespaces()
    let l = line(".")
    let c = col(".")
    %s/\s\+$//e
    call cursor(l, c)
endfun
autocmd FileType c,cpp,java,go,php,javascript,puppet,python,rust,twig,xml,yml,perl autocmd BufWritePre  :call StripTrailingWhitespaces()

shell和python文件新建时, 自动插入行头

" 定义函数AutoSetFileHead，自动插入文件头
autocmd BufNewFile *.sh,*.py exec ":call AutoSetFileHead()"
function! AutoSetFileHead()
    "如果文件类型为.sh文件
    if &filetype == 'sh'
        call setline(1, "\#!/bin/bash")
    endif

    "如果文件类型为python
    if &filetype == 'python'
        call setline(1, "\#!/usr/bin/env python")
        call append(1, "\# encoding: utf-8")
    endif

    normal G
    normal o
    normal o
endfunc

自定义一些高亮的关键字

" 设置可以高亮的关键字
if has("autocmd")
  " Highlight TODO, FIXME, NOTE, etc.
  if v:version > 701
    autocmd Syntax * call matchadd('Todo',  '\W\zs\(TODO\|FIXME\|CHANGED\|DONE\|XXX\|BUG\|HACK\)')
    autocmd Syntax * call matchadd('Debug', '\W\zs\(NOTE\|INFO\|IDEA\|NOTICE\)')
  endif
endif

其他一些设置

" 启动的时候不显示那个援助索马里儿童的提示
set shortmess=atI

" 设置 退出vim后，内容显示在终端屏幕, 可以用于查看和复制, 不需要可以去掉
" 好处：误删什么的，如果以前屏幕打开，可以找回
set t_ti= t_te=

" 鼠标暂不启用, 键盘党....
set mouse-=a

" 回车即选中当前项, 慎用
inoremap         pumvisible() ? "\" : "\"

读书笔记-调试九法

Sun, 29 Nov 2015 08:00:00 +0800

去年十一月份, 写过一篇blog, 讲了一些自己平时进行代码调试的观点, 列了21条

关于代码调试de那些事

上周多看上买了这本书, 花了两小时读完, 做下笔记, 发现很多观点其实是类似的.

这本书是九条原则, 即方法论, 了解和学习, 在实践中遵守, 有利于提升自己调试的效率:)

1. 理解系统

你必须掌握系统的工作原理以及它是如何设计的。在某些情况下，还要知道为什么这样设计。如果你没有理解系统中的某个部分，那么这通常就是出问题的地方。（这不仅仅是“墨菲定律”的问题，如果你不能理解你所设计的系统，你的工作可能会变得一团糟。）

理解是怎么设计的, 机制, 原理, 需求等等, 面对的东西才是一个白盒.

理解系统的基本方法就是阅读手册

手册, 手册, 很多时候, 我们并不能抑制住自己, 去编码, 去调试, 去解决问题, 而忽略了一些重要的东西, 例如: 文档, 我们总以为自己了解一切, 很多时候很诡异的问题查查文档, 才发现, 原来文档有说明:)

或者, 跳过去看源码也是不错的选择

理解了你自己的系统后，还会获得一个额外的好处。当你找到bug时，必须在不破坏其他地方的前提下修复它们。理解系统行为是不破坏系统的第一步。

有个段子, 修了一个, 结果改出了3个bug…只有对系统足够了解, 才能修复而不破坏

人们在调试的时候，通常都不会彻底地阅读系统手册。他们采取跳读的方式，查看他们认为重要的一些章节，但问题的线索可能就隐藏在被略过的那些章节中

有时是这样的, 但是可能时间有限, 这个没法子, 只能在闲时, 多多阅读, 例如, 隔段时间回去浏览一遍

知道什么是正常的

什么是正常的, 什么是异常的?

知道工作流程, 当你尝试寻找bug时，必须知道要查找的路线

不多说, 捞数据, 追数据, 基本功

了解你的工具

要修车, 有趁手的工具才能更高效地解决问题

2. 制造失败

关键是在发生失败的时候要看到它

日志, 现场, 栈等

“当你发现一个故障时该怎么办？” “试着让它再次发生。”

复现

仔细观察你做了什么，然后再做一次，并且记下你做的每个步骤。然后，按照你自己所写的步骤去做，确定这样做确实导致了错误。

复现的步骤

要引发失败, 而不是模拟失败……如果你猜测失败机理，模拟往往不会成功。原因通常有两个，要么你的猜测是错误的；要么测试改变了条件，模拟的系统可以正确工作，或者更糟，发生新的错误，因而分散了你对正在查找的问题的注意力……注意，不要用一个看似完全相同（而实际上不同）的环境来代替并希望看到相同的错误

关注问题本身, 不要错误的转移到了猜测的东西

仔细观察失败

仔细观察失败! 仔细观察! 仔细….

是已修复bug，还是仅仅由于运气好，它不再发生了

你必须确认这一点

永远不要丢掉调试工具

调试工具, 不要当成一次性的工具用完即仍, 可能是错误的

3. 不要想, 而要看

亲眼看到底层的失败是非常重要的。如果你猜测失败是如何发生的，那常常会修复一些根本不是bug的问题。这样的修复不仅不会解决问题，而且还会浪费时间和金钱，甚至会破坏其他地方。请记住，不要这样做。

不要猜测

观察是很难的

的确很难

你必须仔细观察，找到足够多的问题细节，才能调试它……如果你不能留意实际情况发生的全过程，那么你极有可能曲解很多问题。你猜测某个地方出了问题，于是修复它，但实际上错误发生在另一个地方……一定要亲眼看到实际错误是如何发生的。观察往往比猜测能够更快地找到问题。因为猜测虽然看起来是捷径，但这条捷径并不会带你找到问题的根源。

观察而不是猜测

在停下来思考问题之前，对细节的观察应该到什么程度才合适呢？简单的答案是：“一直观察，直到把问题的原因锁定在几种可能性之内。”

海森堡测不准原理: 换言之，测试工具影响了被测系统……。任何插装都可能对系统造成影响，只是程度不同而已

插装, 类似于工具的调试模式, 会影响系统, 所以要注意

4. 分而治之

缩小搜索范围……在查找问题时，“分而治之”实际上是第一条需要使用的原则。事实上，在查找问题时它也是唯一需要应用的规则。所有其他规则都只是帮助你遵循这条规则。分而治之是调试的核心，很多人都知道它，但很多人都没有遵守它，这也正是我写本章的原因。

二分法

确定范围…你必须知道搜索范围，而且必须知道在一端一切正常，而在另一端出现了问题…..从有问题的支路开始查找问题……

原则

如果同时出现了多个问题，当你确实查明了其中的一个问题时，应该立即修复它，然后再查找其他问题……有时修复了一个问题，另一个问题也解决了，两个问题实际上是同一个bug

是有这种情况

5. 一次只改一个地方

使用步枪，而不要用散弹枪……一次只改一个地方……此外，如果你真的看到了错误，应该只修复这个地方

这点很重要

如果你在两个测试之间更改了很多代码，或者为两个测试设置了不同的环境，那么这两个测试将很难对比。它们之间有很多差别并不是由bug引起的，而你必须不断地解释这些差别。你必须把它们之间的差别减少到只与bug有关。排除其他的干扰因素

自从上一次能够正常工作以来你更改了什么……有时，正常的系统和错误的系统之间的区别是由于一项更改造成的。做了更改之后，正常的系统开始出现故障。一种非常有效的办法是找出第一个导致系统出错的版本，尽管这可能需要连续测试原来的版本，直到找到没有故障的版本

大部分问题都是出现在最近一次修改

6. 保持审计跟踪

有时看起来最不起眼的事情实际上却是导致发生bug的关键……因此，你必须记录下每一件事情，不起眼的事情可能会很重要

细节, 步骤

记下你的每步操作、顺序和结果

还是步骤

魔鬼隐藏在细节中

细节

在细节方面，永远都不要相信你的记忆，而要把它写下来。如果你相信你的记忆，将会制造很多麻烦。你会忘掉一些你认为不重要的细节，当然，这些细节将会被证明是非常重要的。你会忘掉一些在你看来不重要的细节，而这些细节对于后来解决另一个不同问题的人可能很重要。除了口头表述以外，你无法将信息传递给别人，而这会浪费所有人的时间。

7. 检查插头

怀疑自己的假设……当我们看到一个问题时，通常在某个特定位置看到了问题，但导致这个问题的原因却在上游或者是一个基础性的问题。系统不具备正确操作的条件，于是出现了非常奇怪的行为。当你看到完全来自另一个世界的问题时，应该停下来，看看你是不是还在地球上

从头开始检查

8. 获得全新观点

寻求帮助: 向别人寻求帮助至少有3个原因（还不算把整个问题甩给别人）：获得全新观点、专业知识和经验。而且，人们通常很愿意帮忙，因为这给了他们一个证明自己很聪明的机会

事实上，有时向别人解释问题也会使你有全新的认识，之后你自己就解决了问题

小黄鸭调试法

报告症状, 而不是理论: 让他提出自己的观点。他们的观点可能与你的观点相符，也可能全然不同，而这正是你想要的

9.如果你不修复bug, 它将依然存在

检查问题确实已被修复

bug 从来不会自己消失

这段时间的一些想法

Sun, 08 Nov 2015 08:00:00 +0800

发现自己有一段时间没更新 blog 了, 写一写吧, 至于技术方面的东西, 后面慢慢发吧:)

这一年经历了很多事情, 休息了一百天, 然后找工作, 入职.

入职期间还有些波折, offer那边说发了我这边却一直没收到, 还有确认入职事宜后没有发入职通知, 不过波波折折, 也算入职了, 三周, 到了深圳的加班圣地, 开启新的副本.

工作四年多了, 这是第四家公司了, 这四年发生了很多事情, 阿里上市了, 快播消失了, 甜品也歇业了, 刚到企鹅, 新生, 归零心态, 逐渐适应中, 算是一个新的开始, 重新审视自己, 审视工作, 审视学习, 审视生活, 以刚入行时的状态, 重新开始这趟征程.

总之, 这许多年, 是一些经历, 做了很多事情, 结识了很多人. 逐步形成了自己现在的样子.

尽量写得不像鸡汤, 很多东西还是要自己慢慢去感受体悟, 诸君共勉.

我只是一个普通人

刚毕业那会, 初生牛犊, 总想着去做一些牛逼的事情, 学一些给力的东西, 变得强大, 变成自己想象中的牛人

而, 后来这些年, 逐渐对自己, 对生活, 以及对这整个世界, 有了新的认识.

当然, 也碰到了很多人, 碰到了很多事. 期间感受过智商被碾压, 感受过业务成就技术的喜悦, 也感受过业务夭折的无奈.

最终, 有了自己的定位.

我只是个普通人, 智商不高不低, 资质一般, 没有所谓的天赋异禀.

当然, 有天才的存在, 而对于普通人来说, 只能, 靠着自己的努力一点点慢慢地成长, 变得强大.

勤能补拙? 答案是否定的, 普通人的天赋和精力有限, 想明白自己感兴趣的, 想做的是什么, 然后投入进去, 坚持下来, 也就是了. 把有限精力浪费在无限的地方上是非常愚蠢的.

普通人做普通事, 很多时候, 选择更重要, 运气也很重要:) 所以, 思考, 投入, 坚持, 每天朝着目标前进, 这就够了, 你会发现, 你比以前的自己更加强大.

战线太长有好有坏, 但大多数时候, 需要关注跟自己工作相关的东西

工作四年多, 中间有两年, 走了弯路吧感觉.

耗费了大量的时间, 每天晚上及周末, 去接触, 所谓的学习各种技术, 而绝大多数, 在自己工作中并没有用到.

战线太长, 好处就是, 可能视野广了许多, 对很多事情有了新的看法, 也逐渐能归纳得到一些共性.

缺点嘛, 很明显, 太耗费时间, 而且中间绝大多数成了沉没成本. 学了忘忘了学, 重复太多.

其实最佳的策略应该是, 从日常工作入手, 工作中接触的各种事情, 遇到的各种问题, 涉及的各种技术栈, 以点带面, 深挖和发散, 这就会占用掉大部分时间和经历了, 而事实也证明, 目前自己受益最大的, 反而是这些东西.

至于其他, 自己感兴趣, 去学, 去用.

不要为了学而学, 学以致用.

收集资料没什么用, 善用搜索, 另外, 记得踩过的坑, 以及, 深挖和扩展

刚毕业那会, 硬盘上收集了很多java的资料. 后来, 右键删了>_<

刷了几年微博, 收藏了很多东西, 估计有几千条, 然而, 再也没去看过.

买了很多书, 最终却发现, 只看了一半多点.

现在网络那么发达, 资源过载的年代, 其实资源永远触手可及, 并不需要花时间去下载/分类/储存.

而很多人, 往往会将整理作为主业, 而不是学习和吸收. 花了大量时间整理得到一套看似庞大的东西.

其实我在想, 看大家很多mark, 不知道有多少人会再去看过.

知识管理, 分级, 自己积累沉淀得到的东西, 一级, 工作涉及的东西, 二级, 相关领域自己感兴趣的东西, 三级, 杂七杂八八卦等等, 四级.

完全可以用wiki/evernote/pocket等工具, 自行分级

重要的是, 搜索, 用到的时候, 可以在最短的时间内汇集, 掌握和使用.

分级+搜索

很遗憾, 看很多技术书或许没什么用

这些年, 看了很多书, 刚开始都是买技术的, 后来给自己定了个规矩, 买一本技术要对应买一本非技术.

后来的后来, 开始用kindle, 然后发现看技术书还是duokan来得舒服, 毕竟用pad看大一些:)

市面上绝大多数, 90%, 可以算是入门书籍, 剩下7%, 算是进阶, 然后, 3%才是经典.

然而 ,很多时候, 作为初学者, 看经典一般是自虐的过程, 大多数需要从一本好的入门书开始.

而入门, 需要自己挑选, 数量庞大, 有点类似快销品, 读完入门了, 再也不会看第二遍.

所以后来我的原则变成了, 经典书, 买纸质, 反复读, 而其他的, 通过文档+电子书的形式, 快速学习入门.

看书, 得到一些东西, 想法, 观点等等, 记录, 便够了.

虽然很多书没什么用 ,但是, 你总得找到, 并读完那些有用的书

数量的多少, 并没有什么用. 例如所谓的成功学的书籍, 一目十行一本书刷完花不了多久

但是一本书, 只要能学到一点, 那便是好的.

有人不买书, 说是买了大部分也没读, 我的观点是, 你不买, 一年到头一本书也没读, 但是你买书, 假设买了十本, 只读了两本, 那也比没读好吧.

另外, 买书要谨慎筛选, 花时间去甄别, 然后, 读书要快, 趁着热情还在秒掉, 最后, 要做笔记, 哪怕只是摘录(后续重读你会感谢自己的摘录和笔记的)

学会如何分析问题, 解决问题

工作这些年, 其实发现, 很多东西是通的.

例如, 学一门语言, 深入下去, 再深入下去, 切另一门的时候, 发现其实有很多共性, 比什么都是皮毛好多了.

所以, 没必要纠结自己什么东西还不会.

而这些年, 最大的感受是, 写代码, 无非是分析问题, 解决问题.

而我们要做的, 就是学会这些, 从书本, 从他人, 从自己的经验中去学习, 掌握

学会从一点一滴开始, 优化自己的生活

不管是工作, 生活

例如, 学习 GTD, 学习番茄时间工作法, 学习某个工具的使用

学会怎么快速搜索, 从很多同类 app 中挑选适合自己的

定制自己的环境, 符合自己操作习惯的东西

每次, 发现重复或者比较繁琐蛋疼的事情发生了, 记录下来, 如果可以花点时间一劳永逸, 那花这些时间是值得的. 至于解决方案, 会google就能解决绝大多数的问题.

极简的生活

每个人有自己的选择, 不过我还是倾向于活得简单些.

天生喜欢逻辑, 不喜欢复杂的不可量化的东西. 所以所谓的情商方面 , 低了一些.

生活是自己的, 过成自己想要过的样子便好. 不活在别人的看法里, 不活在别人的嘴里.

自己快乐, 才是真的快乐不是么?

极简主义, 虽然还做不到不以物喜不以己悲的境界, 但是, 简简单单的生活, 带来的是简简单单的快乐.

写日记吧

度过了很闲很闲的三个月

也度过了很忙很忙的三周

发现, 人的记忆, 并不是很靠谱, 曾几何时我能记得过去一周或者一个月, 每天都怎么过的, 而现在, 却发现, 有时候都想不起来昨天怎么过的

或许老了吧, 但是主要问题还是, 这个世界熟悉之后, 我们的生活成了"日常", 每天过得模式化了, 太过相似, 以至于很难记录.

所以, 写日记吧, 电子或者纸笔, 即使是流水账也好, 否则过往的时光, 很容易被压缩成一小段重复的记忆.

其实, 每天都是新的一天, 善于发现各种细节, 行走得慢些, 多看看, 多想想.

日记里,写写流水, 吐吐槽, 反思反思, 定期翻一翻.

现在, 即使回来再累, 也要睡前花点时间写写:), 已坚持快两个月了

定期总结

这个还是很重要的, 可以暴露很多问题, 例如自己是不是跑偏了……

按自己的习惯, 写写总结, 算是一种回顾, 也是对未来的一些计划.

活在当下

不为过去而懊悔, 不为未来而担忧

昨天已经过去, 时间已经流逝, 懊悔昨天没有什么作用, 想一想, 写写总结, 记录下哪些后面可以避免或者搞定, 然后去睡觉

未来的事情, 来了再说, 在这之前, 准备好就行, 再多的焦虑也是无用, 担忧得睡不着对明天一点作用都没有

快乐也是一天, 不快乐也是一天, 那就快快乐乐的呗

每天过得充实, 每天学到一些东西, 感受到一些东西, 有所进步, 就够了

不乱于心, 不困于情, 不念过去, 不畏将来

如果发现自己得了晚睡症, 那就要反思下了, 自己为什么不能让这一天结束而非要拖到第二天呢?

2015-11-08 于深圳

wklken

Python 源码阅读 - 垃圾回收机制

Tue, 29 Sep 2015 08:00:00 +0800

概述

无论何种垃圾收集机制, 一般都是两阶段: 垃圾检测和垃圾回收.

在Python中, 大多数对象的生命周期都是通过对象的引用计数来管理的.

问题: 但是存在循环引用的问题: a 引用 b, b 引用 a, 导致每一个对象的引用计数都不为0, 所占用的内存永远不会被回收

要解决循环引用: 必需引入其他垃圾收集技术来打破循环引用. Python中使用了标记-清除以及分代收集

即, Python 中垃圾回收机制: 引用计数(主要), 标记清除, 分代收集(辅助)

引用计数

引用计数, 意味着必须在每次分配和释放内存的时候, 加入管理引用计数的动作

引用计数的优点: 最直观最简单, 实时性, 任何内存, 一旦没有指向它的引用, 就会立即被回收

计数存储

回顾 Python 的对象

e.g. 引用计数增加以及减少

>>> from sys import getrefcount
>>>
>>> a = [1, 2, 3]
>>> getrefcount(a)
2
>>> b = a
>>> getrefcount(a)
3
>>> del b
>>> getrefcount(a)
2

计数增加

增加对象引用计数, refcnt incr

#define Py_INCREF(op) (                         \
	_Py_INC_REFTOTAL  _Py_REF_DEBUG_COMMA       \
	((PyObject*)(op))->ob_refcnt++)

计数减少

减少对象引用计数, refcnt desc

#define _Py_DEC_REFTOTAL        _Py_RefTotal--
#define _Py_REF_DEBUG_COMMA     ,

#define Py_DECREF(op)                                   \
	do {                                                \
		if (_Py_DEC_REFTOTAL  _Py_REF_DEBUG_COMMA       \
		--((PyObject*)(op))->ob_refcnt != 0)            \
			_Py_CHECK_REFCNT(op)                        \
		else                                            \
		_Py_Dealloc((PyObject *)(op));                  \
	} while (0)

即, 发现refcnt变成0的时候, 会调用_Py_Dealloc

PyAPI_FUNC(void) _Py_Dealloc(PyObject *);
#define _Py_REF_DEBUG_COMMA     ,

#define _Py_Dealloc(op) (                               \
	_Py_INC_TPFREES(op) _Py_COUNT_ALLOCS_COMMA          \
	(*Py_TYPE(op)->tp_dealloc)((PyObject *)(op)))
#endif /* !Py_TRACE_REFS */

会调用各自类型的tp_dealloc

例如dict

PyTypeObject PyDict_Type = {
    PyVarObject_HEAD_INIT(&PyType_Type, 0)
    "dict",
    sizeof(PyDictObject),
    0,
    (destructor)dict_dealloc,                   /* tp_dealloc */
    ....
}


static void
dict_dealloc(register PyDictObject *mp)
{
    .....
    // 如果满足条件, 放入到缓冲池freelist中
    if (numfree < PyDict_MAXFREELIST && Py_TYPE(mp) == &PyDict_Type)
        free_list[numfree++] = mp;
    // 否则, 调用tp_free
    else
        Py_TYPE(mp)->tp_free((PyObject *)mp);
    Py_TRASHCAN_SAFE_END(mp)
}

Python基本类型的tp_dealloc, 通常都会与各自的缓冲池机制相关, 释放会优先放入缓冲池中(对应的分配会优先从缓冲池取). 这个内存分配与回收同缓冲池机制相关

当无法放入缓冲池时, 会调用各自类型的tp_free

int, 比较特殊

// int, 通用整数对象缓冲池机制
      (freefunc)int_free,                         /* tp_free */

string

// string
    PyObject_Del,                               /* tp_free */

dict/tuple/list

    PyObject_GC_Del,                            /* tp_free */

然后, 我们再回头看, 自定义对象的tp_free

PyTypeObject PyType_Type = {
    PyVarObject_HEAD_INIT(&PyType_Type, 0)
    "type",                                     /* tp_name */
    ...
    PyObject_GC_Del,                            /* tp_free */
};

即, 最终, 当计数变为0, 触发内存回收动作. 涉及函数PyObject_Del和PyObject_GC_Del, 并且, 自定义类以及容器类型(dict/list/tuple/set等)使用的都是后者PyObject_GC_Del.

内存回收 PyObject_Del / PyObject_GC_Del

如果引用计数=0:

1. 放入缓冲池
2. 真正销毁, PyObject_Del/PyObject_GC_Del内存操作

这两个操作都是进行内存级别的操作

PyObject_Del

PyObject_Del(op) releases the memory allocated for an object. It does not run a destructor – it only frees the memory. PyObject_Free is identical.

这块删除, PyObject_Free 涉及到了Python底层内存的分配和管理机制, 具体见前面的博文

PyObject_GC_Del

void
PyObject_GC_Del(void *op)
{
	PyGC_Head *g = AS_GC(op);

	// Returns true if a given object is tracked
	if (IS_TRACKED(op))
		// 从跟踪链表中移除
		gc_list_remove(g);
	if (generations[0].count > 0) {
		generations[0].count--;
	}
	PyObject_FREE(g);
}

IS_TRACKED 涉及到标记-清除的机制

generations 涉及到了分代回收

PyObject_FREE, 则和Python底层内存池机制相关

标记-清除

问题: 什么对象可能产生循环引用?

只需要关注关注可能产生循环引用的对象

PyIntObject/PyStringObject等不可能

Python中的循环引用总是发生在container对象之间, 所谓containser对象即是内部可持有对其他对象的引用: list/dict/class/instance等等

垃圾收集带来的开销依赖于container对象的数量, 必需跟踪所创建的每一个container对象, 并将这些对象组织到一个集合中.

可收集对象链表

可收集对象链表: 将需要被收集和跟踪的container, 放到可收集的链表中

任何一个python对象都分为两部分: PyObject_HEAD + 对象本身数据

/* PyObject_HEAD defines the initial segment of every PyObject. */
#define PyObject_HEAD                   \
    _PyObject_HEAD_EXTRA                \
    Py_ssize_t ob_refcnt;               \
    struct _typeobject *ob_type;

//----------------------------------------------------

  #define _PyObject_HEAD_EXTRA            \
      struct _object *_ob_next;           \
      struct _object *_ob_prev;

// 双向链表结构, 垃圾回收

可收集对象链表

Modules/gcmodule.c

/* GC information is stored BEFORE the object structure. */
typedef union _gc_head {
    struct {
        // 建立链表需要的前后指针
        union _gc_head *gc_next;
        union _gc_head *gc_prev;
        // 在初始化时会被初始化为 GC_UNTRACED
        Py_ssize_t gc_refs;
    } gc;
    long double dummy;  /* force worst-case alignment */
} PyGC_Head;

创建container的过程: container对象 = pyGC_Head | PyObject_HEAD | Container Object

PyObject *
_PyObject_GC_New(PyTypeObject *tp)
{
    PyObject *op = _PyObject_GC_Malloc(_PyObject_SIZE(tp));
    if (op != NULL)
        op = PyObject_INIT(op, tp);
    return op;
}

=> _PyObject_GC_Malloc

#define _PyGC_REFS_UNTRACKED                    (-2)
#define GC_UNTRACKED                    _PyGC_REFS_UNTRACKED

PyObject *
_PyObject_GC_Malloc(size_t basicsize)
{
    PyObject *op;
    PyGC_Head *g;
    if (basicsize > PY_SSIZE_T_MAX - sizeof(PyGC_Head))
        return PyErr_NoMemory();

    // 为 对象本身+PyGC_Head申请内存, 注意分配的size
    g = (PyGC_Head *)PyObject_MALLOC(
        sizeof(PyGC_Head) + basicsize);
    if (g == NULL)
        return PyErr_NoMemory();

    // 初始化 GC_UNTRACED
    g->gc.gc_refs = GC_UNTRACKED;
    generations[0].count++; /* number of allocated GC objects */

    // 如果大于阈值, 执行分代回收
    if (generations[0].count > generations[0].threshold &&
        enabled &&
        generations[0].threshold &&
        !collecting &&
        !PyErr_Occurred()) {

        collecting = 1;
        collect_generations();
        collecting = 0;
    }
    op = FROM_GC(g);
    return op;
}

PyObject_HEAD and PyGC_HEAD

注意, FROM_GC和AS_GC用于 PyObject_HEAD <=> PyGC_HEAD地址相互转换

// => Modules/gcmodule.c

/* Get an object's GC head */
#define AS_GC(o) ((PyGC_Head *)(o)-1)

/* Get the object given the GC head */
#define FROM_GC(g) ((PyObject *)(((PyGC_Head *)g)+1))

// => objimpl.h

#define _Py_AS_GC(o) ((PyGC_Head *)(o)-1)

问题: 什么时候将container放到这个对象链表中

e.g list

// => listobject.c

PyObject *
PyList_New(Py_ssize_t size)
{
    PyListObject *op;
    op = PyObject_GC_New(PyListObject, &PyList_Type);
    _PyObject_GC_TRACK(op);
    return (PyObject *) op;
}

// =>  _PyObject_GC_TRACK

// objimpl.h
// 加入到可收集对象链表中

#define _PyObject_GC_TRACK(o) do { \
    PyGC_Head *g = _Py_AS_GC(o); \
    if (g->gc.gc_refs != _PyGC_REFS_UNTRACKED) \
        Py_FatalError("GC object already tracked"); \
    g->gc.gc_refs = _PyGC_REFS_REACHABLE; \
    g->gc.gc_next = _PyGC_generation0; \
    g->gc.gc_prev = _PyGC_generation0->gc.gc_prev; \
    g->gc.gc_prev->gc.gc_next = g; \
    _PyGC_generation0->gc.gc_prev = g; \
    } while (0);

问题: 什么时候将container从这个对象链表中摘除

// Objects/listobject.c

static void
list_dealloc(PyListObject *op)
{
    Py_ssize_t i;
    PyObject_GC_UnTrack(op);
    .....
}

// => PyObject_GC_UnTrack => _PyObject_GC_UNTRACK

// 对象销毁的时候
#define _PyObject_GC_UNTRACK(o) do { \
    PyGC_Head *g = _Py_AS_GC(o); \
    assert(g->gc.gc_refs != _PyGC_REFS_UNTRACKED); \
    g->gc.gc_refs = _PyGC_REFS_UNTRACKED; \
    g->gc.gc_prev->gc.gc_next = g->gc.gc_next; \
    g->gc.gc_next->gc.gc_prev = g->gc.gc_prev; \
    g->gc.gc_next = NULL; \
    } while (0);

问题: 如何进行标记-清除

现在, 我们得到了一个链表

Python将自己的垃圾收集限制在这个链表上, 循环引用一定发生在这个链表的一群独享之间.

0. 概览

_PyObject_GC_Malloc 分配内存时, 发现超过阈值, 此时, 会触发gc, collect_generations 然后调用collect, collect包含标记-清除逻辑

gcmodule.c

  /* This is the main function.  Read this to understand how the
   * collection process works. */
  static Py_ssize_t
  collect(int generation)
  {
    // 第1步: 将所有比 当前代 年轻的代中的对象 都放到 当前代 的对象链表中
    /* merge younger generations with one we are currently collecting */
    for (i = 0; i < generation; i++) {
        gc_list_merge(GEN_HEAD(i), GEN_HEAD(generation));
    }


    // 第2步
    update_refs(young);
    // 第3步
    subtract_refs(young);

    // 第4步
    gc_list_init(&unreachable);
    move_unreachable(young, &unreachable);

    // 第5步
      /* Move reachable objects to next generation. */
      if (young != old) {
          if (generation == NUM_GENERATIONS - 2) {
              long_lived_pending += gc_list_size(young);
          }
          gc_list_merge(young, old);
      }
      else {
          /* We only untrack dicts in full collections, to avoid quadratic
             dict build-up. See issue #14775. */
          untrack_dicts(young);
          long_lived_pending = 0;
          long_lived_total = gc_list_size(young);
      }

    // 第6步
      delete_garbage(&unreachable, old);

  }

1. 第一步: gc_list_merge

将所有比当前代年轻的代中的对象都放到当前代的对象链表中

// => gc_list_merge

// 执行拷贝而已
/* append list `from` onto list `to`; `from` becomes an empty list */
static void
gc_list_merge(PyGC_Head *from, PyGC_Head *to)
{
    PyGC_Head *tail;
    assert(from != to);
    if (!gc_list_is_empty(from)) {
        tail = to->gc.gc_prev;
        tail->gc.gc_next = from->gc.gc_next;
        tail->gc.gc_next->gc.gc_prev = tail;
        to->gc.gc_prev = from->gc.gc_prev;
        to->gc.gc_prev->gc.gc_next = to;
    }
    // 清空
    gc_list_init(from);
}

=>

static void
gc_list_init(PyGC_Head *list)
{
    list->gc.gc_prev = list;
    list->gc.gc_next = list;
}

即, 此刻, 所有待进行处理的对象都集中在同一个链表中

处理,

其逻辑是, 要去除循环引用, 得到有效引用计数

有效引用计数: 将循环引用的计数去除, 最终得到的 => 将环从引用中摘除, 各自引用计数数值-1

实际操作, 并不要直接修改对象的 ob_refcnt, 而是修改其副本, PyGC_Head中的gc.gc_ref

2. 第二步: update_refs

遍历对象链表, 将每个对象的gc.gc_ref值设置为ob_refcnt

// => gcmodule.c

static void
update_refs(PyGC_Head *containers)
{
    PyGC_Head *gc = containers->gc.gc_next;
    for (; gc != containers; gc = gc->gc.gc_next) {
        assert(gc->gc.gc_refs == GC_REACHABLE);
        gc->gc.gc_refs = Py_REFCNT(FROM_GC(gc));
        /* Python's cyclic gc should never see an incoming refcount
         * of 0:  if something decref'ed to 0, it should have been
         * deallocated immediately at that time.
         * Possible cause (if the assert triggers):  a tp_dealloc
         * routine left a gc-aware object tracked during its teardown
         * phase, and did something-- or allowed something to happen --
         * that called back into Python.  gc can trigger then, and may
         * see the still-tracked dying object.  Before this assert
         * was added, such mistakes went on to allow gc to try to
         * delete the object again.  In a debug build, that caused
         * a mysterious segfault, when _Py_ForgetReference tried
         * to remove the object from the doubly-linked list of all
         * objects a second time.  In a release build, an actual
         * double deallocation occurred, which leads to corruption
         * of the allocator's internal bookkeeping pointers.  That's
         * so serious that maybe this should be a release-build
         * check instead of an assert?
         */
        assert(gc->gc.gc_refs != 0);
    }
}

3. 第三步: 计算有效引用计数

  /* A traversal callback for subtract_refs. */
  static int
  visit_decref(PyObject *op, void *data)
  {
      assert(op != NULL);
      // 判断op指向的对象是否是被垃圾收集监控的, 对象的type对象中有Py_TPFLAGS_HAVE_GC符号
      if (PyObject_IS_GC(op)) {
          PyGC_Head *gc = AS_GC(op);
          /* We're only interested in gc_refs for objects in the
           * generation being collected, which can be recognized
           * because only they have positive gc_refs.
           */
          assert(gc->gc.gc_refs != 0); /* else refcount was too small */
          if (gc->gc.gc_refs > 0)
              gc->gc.gc_refs--;  // -1
      }
      return 0;
  }


  /* Subtract internal references from gc_refs.  After this, gc_refs is >= 0
   * for all objects in containers, and is GC_REACHABLE for all tracked gc
   * objects not in containers.  The ones with gc_refs > 0 are directly
   * reachable from outside containers, and so can't be collected.
   */
  static void
  subtract_refs(PyGC_Head *containers)
  {
      traverseproc traverse;
      PyGC_Head *gc = containers->gc.gc_next;
      // 遍历链表
      for (; gc != containers; gc=gc->gc.gc_next) {
          // 与特定的类型相关, 得到类型对应的traverse函数
          traverse = Py_TYPE(FROM_GC(gc))->tp_traverse;
          // 调用
          (void) traverse(FROM_GC(gc),
                         (visitproc)visit_decref, // 回调形式传入
                         NULL);
      }
  }

我们可以看看dictobject的traverse函数

  static int
  dict_traverse(PyObject *op, visitproc visit, void *arg)
  {
      Py_ssize_t i = 0;
      PyObject *pk;
      PyObject *pv;

      // 遍历所有键和值
      while (PyDict_Next(op, &i, &pk, &pv)) {
          Py_VISIT(pk);
          Py_VISIT(pv);
      }
      return 0;
  }

逻辑大概是: 遍历容器对象里面的所有对象, 通过visit_decref将这些对象的引用计数都-1,

最终, 遍历完链表之后, 整个可收集对象链表中所有container对象之间的循环引用都被去掉了

4. 第四步: 垃圾标记

move_unreachable, 将可收集对象链表中, 根据有效引用计数不等于0(root对象) 和等于0(非root对象, 垃圾, 可回收), 一分为二

 /* Move the unreachable objects from young to unreachable.  After this,
   * all objects in young have gc_refs = GC_REACHABLE, and all objects in
   * unreachable have gc_refs = GC_TENTATIVELY_UNREACHABLE.  All tracked
   * gc objects not in young or unreachable still have gc_refs = GC_REACHABLE.
   * All objects in young after this are directly or indirectly reachable
   * from outside the original young; and all objects in unreachable are
   * not.
   */
  static void
  move_unreachable(PyGC_Head *young, PyGC_Head *unreachable)
  {
      PyGC_Head *gc = young->gc.gc_next;

      /* Invariants:  all objects "to the left" of us in young have gc_refs
       * = GC_REACHABLE, and are indeed reachable (directly or indirectly)
       * from outside the young list as it was at entry.  All other objects
       * from the original young "to the left" of us are in unreachable now,
       * and have gc_refs = GC_TENTATIVELY_UNREACHABLE.  All objects to the
       * left of us in 'young' now have been scanned, and no objects here
       * or to the right have been scanned yet.
       */

      while (gc != young) {
          PyGC_Head *next;

          // 对于root object,
          if (gc->gc.gc_refs) {
              /* gc is definitely reachable from outside the
               * original 'young'.  Mark it as such, and traverse
               * its pointers to find any other objects that may
               * be directly reachable from it.  Note that the
               * call to tp_traverse may append objects to young,
               * so we have to wait until it returns to determine
               * the next object to visit.
               */
              PyObject *op = FROM_GC(gc);
              traverseproc traverse = Py_TYPE(op)->tp_traverse;
              assert(gc->gc.gc_refs > 0);
              // 设置其gc->gc.gc_refs = GC_REACHABLE
              gc->gc.gc_refs = GC_REACHABLE;

              // 注意这里逻辑, visit_reachable, 意图是?
              (void) traverse(op,
                              (visitproc)visit_reachable,
                              (void *)young);
              next = gc->gc.gc_next;
              if (PyTuple_CheckExact(op)) {
                  _PyTuple_MaybeUntrack(op);
              }
          }
          // 有效引用计数=0, 非root对象, 移动到unreachable链表中
          else {
              /* This *may* be unreachable.  To make progress,
               * assume it is.  gc isn't directly reachable from
               * any object we've already traversed, but may be
               * reachable from an object we haven't gotten to yet.
               * visit_reachable will eventually move gc back into
               * young if that's so, and we'll see it again.
               */
              next = gc->gc.gc_next;
              gc_list_move(gc, unreachable);
              gc->gc.gc_refs = GC_TENTATIVELY_UNREACHABLE;
          }
          gc = next;
      }
  }

5. 第五步: 将存活对象放入下一代

      /* Move reachable objects to next generation. */
      if (young != old) {
          if (generation == NUM_GENERATIONS - 2) {
              long_lived_pending += gc_list_size(young);
          }
          gc_list_merge(young, old);
      }
      else {
          /* We only untrack dicts in full collections, to avoid quadratic
             dict build-up. See issue #14775. */
          untrack_dicts(young);
          long_lived_pending = 0;
          long_lived_total = gc_list_size(young);
      }

6. 第六步: 执行回收

gcmoudle.c

  static int
  gc_list_is_empty(PyGC_Head *list)
  {
      return (list->gc.gc_next == list);
  }


  /* Break reference cycles by clearing the containers involved.  This is
   * tricky business as the lists can be changing and we don't know which
   * objects may be freed.  It is possible I screwed something up here.
   */
  static void
  delete_garbage(PyGC_Head *collectable, PyGC_Head *old)
  {
      inquiry clear;

      // 遍历
      while (!gc_list_is_empty(collectable)) {
          PyGC_Head *gc = collectable->gc.gc_next;
          // 得到对象
          PyObject *op = FROM_GC(gc);

          assert(IS_TENTATIVELY_UNREACHABLE(op));
          if (debug & DEBUG_SAVEALL) {
              PyList_Append(garbage, op);
          }
          else {
              // 清引用
              if ((clear = Py_TYPE(op)->tp_clear) != NULL) {
                  Py_INCREF(op);
                  // 这个操作会调整container对象中每个引用所有对象的引用计数, 从而完成打破循环的最终目标
                  clear(op);
                  Py_DECREF(op);
              }
          }

          // 重新送回到reachable链表.
          // 原因: 在进行clear动作, 如果成功, 会把自己从垃圾收集机制维护的链表中摘除, 由于某些原因, 对象可能在clear的时候, 没有成功完成必要动作, 还不能被销毁, 所以放回去
          if (collectable->gc.gc_next == gc) {
              /* object is still alive, move it, it may die later */
              gc_list_move(gc, old);
              gc->gc.gc_refs = GC_REACHABLE;
          }
      }
  }

=> 来看下, list的clear

static int
list_clear(PyListObject *a)
{
    Py_ssize_t i;
    PyObject **item = a->ob_item;
    if (item != NULL) {
        /* Because XDECREF can recursively invoke operations on
           this list, we make it empty first. */
        i = Py_SIZE(a);
        Py_SIZE(a) = 0;
        a->ob_item = NULL;
        a->allocated = 0;
        while (--i >= 0) {
            // 减引用
            Py_XDECREF(item[i]);
        }
        PyMem_FREE(item);
    }
    /* Never fails; the return value can be ignored.
       Note that there is no guarantee that the list is actually empty
       at this point, because XDECREF may have populated it again! */
    return 0;
}


// e.g. 处理list3, 调用其list_clear, 减少list4的引用计数, list4.ob_refcnt=0, 引发对象销毁, 调用list4的list_dealloc


static void
list_dealloc(PyListObject *op)
{
    Py_ssize_t i;
    PyObject_GC_UnTrack(op);  //  从可收集对象链表中去除, 会影响到list4所引用所有对象的引用计数, => list3.refcnt=0, list3的销毁动作也被触发

    Py_TRASHCAN_SAFE_BEGIN(op)
    if (op->ob_item != NULL) {
        /* Do it backwards, for Christian Tismer.
           There's a simple test case where somehow this reduces
           thrashing when a *very* large list is created and
           immediately deleted. */
        i = Py_SIZE(op);
        while (--i >= 0) {
            Py_XDECREF(op->ob_item[i]);
        }
        PyMem_FREE(op->ob_item);
    }
    if (numfree < PyList_MAXFREELIST && PyList_CheckExact(op))
        free_list[numfree++] = op;
    else
        Py_TYPE(op)->tp_free((PyObject *)op);
    Py_TRASHCAN_SAFE_END(op)
}

7. gc逻辑

分配内存
-> 发现超过阈值了
-> 触发垃圾回收
-> 将所有可收集对象链表放到一起
-> 遍历, 计算有效引用计数
-> 分成 有效引用计数=0 和 有效引用计数 > 0 两个集合
-> 大于0的, 放入到更老一代
-> =0的, 执行回收
-> 回收遍历容器内的各个元素, 减掉对应元素引用计数(破掉循环引用)
-> 执行-1的逻辑, 若发现对象引用计数=0, 触发内存回收
-> python底层内存管理机制回收内存

分代回收

分代收集: 以空间换时间

思想: 将系统中的所有内存块根据其存货的时间划分为不同的集合, 每个集合就成为一个"代", 垃圾收集的频率随着"代"的存活时间的增大而减小(活得越长的对象, 就越不可能是垃圾, 就应该减少去收集的频率)

Python中, 引入了分代收集, 总共三个"代". Python 中, 一个代就是一个链表, 所有属于同一"代"的内存块都链接在同一个链表中

表头数据结构

gcmodule.c


  struct gc_generation {
      PyGC_Head head;
      int threshold; /* collection threshold */  // 阈值
      int count; /* count of allocations or collections of younger
                    generations */    // 实时个数
  };

三个代的定义

  #define NUM_GENERATIONS 3
  #define GEN_HEAD(n) (&generations[n].head)

  //  三代都放到这个数组中
  /* linked lists of container objects */
  static struct gc_generation generations[NUM_GENERATIONS] = {
      /* PyGC_Head,                               threshold,      count */
      {{{GEN_HEAD(0), GEN_HEAD(0), 0}},           700,            0},    //700个container, 超过立即触发垃圾回收机制
      {{{GEN_HEAD(1), GEN_HEAD(1), 0}},           10,             0},    // 10个
      {{{GEN_HEAD(2), GEN_HEAD(2), 0}},           10,             0},    // 10个
  };

  PyGC_Head *_PyGC_generation0 = GEN_HEAD(0);

超过阈值, 触发垃圾回收

 PyObject *
  _PyObject_GC_Malloc(size_t basicsize)
  {
      // 执行分配
      ....
      generations[0].count++; /* number of allocated GC objects */  //增加一个
      if (generations[0].count > generations[0].threshold && // 发现大于预支了
          enabled &&
          generations[0].threshold &&
          !collecting &&
          !PyErr_Occurred())
          {
              collecting = 1;
              collect_generations();  //  执行收集
              collecting = 0;
          }
      op = FROM_GC(g);
      return op;
  }

=> collect_generations

  static Py_ssize_t
  collect_generations(void)
  {
      int i;
      Py_ssize_t n = 0;

      /* Find the oldest generation (highest numbered) where the count
       * exceeds the threshold.  Objects in the that generation and
       * generations younger than it will be collected. */

      // 从最老的一代, 开始回收
      for (i = NUM_GENERATIONS-1; i >= 0; i--) {  // 遍历所有generation
          if (generations[i].count > generations[i].threshold) {  // 如果超过了阈值
              /* Avoid quadratic performance degradation in number
                 of tracked objects. See comments at the beginning
                 of this file, and issue #4074.
              */
              if (i == NUM_GENERATIONS - 1
                  && long_lived_pending < long_lived_total / 4)
                  continue;
              n = collect(i); // 执行收集
              break;  // notice: break了
          }
      }
      return n;
  }

Python 中的gc模块

gc模块, 提供了观察和手动使用gc的接口

import gc

gc.set_debug(gc.DEBUG_STATS | gc.DEBUG_LEAK)

gc.collect()

注意__del__给gc带来的影响

我为什么要写博客

Sat, 26 Sep 2015 08:00:00 +0800

从七月中旬, 到八月底, 彻彻底底休息了一个半月, 九月初开始找工作, 目测国庆节后才能完成入职开始干活.

周期略长, 主要节点不好, 哎

最近在想一个问题, 我为什么要写博客?

开始写博客, 是在大学期间吧, 当时用的是新浪博客, 写了很多杂七杂八生活的点点滴滴, 临毕业前, 应该是刚从北京实习回学校, 2011年的4月1日(没错是愚人节), 注册了CSDN, 开始了写技术博客

13年7月从 CSDN 迁移走, 到了独立博客, 主要是那时候CSDN不支持markdown, 而且感觉自己维护一个更为便利些, 便买了主机, 申请了域名, 开始了独立博客的时光.

到现在, 也有两年了吧.

现在博客, 每个月UV大概1W的样子. 没有任何推广渠道, 全靠用户回访以及搜索引擎带来的流量.

偶尔隔一阵, 便会收到一份donation, 虽不多, 但是每次都会觉得很开心, 就像是隔一阵的惊喜, 也算是给自己的坚持注入了一些动力, 再次感谢各位:)

回去看了下CSDN, 访问接近90W 次, 排名834……已经放弃维护好久了(两年多了), CSDN 留下了我那一两年青葱的时光.

很快, 工作四年多了, 时间是把杀猪刀, 改变了很多东西.

工作四年, 经历了三家公司, 不幸的是后面两家夭折了, 庆幸的是, 做了很多事情, 认识了很多朋友.

做的事情多, 杂, 也接触了很多东西, 感觉遗憾的是没能完完整整地经历一个公司的发展, 或者一套系统的进化过程.

四年, 改变了很多, 唯独没变的, 是偶尔会更新下博客, 输出一些东西, 吐吐槽神马的.

写博客的目的, 对我来说, 不外乎如是:

记录

活得越久, 越发现记忆的不靠谱.

很难会到过去某一刻, 某个时期的所思所想, 当时的心境, 当时的境遇.

所以, 记录, 写一写小结, 阶段性看看, 过去无知/青葱的自己, 也是必须的.

当然, 更有效的做法是, 每天坚持写写日记

有一些坑, 自己踩过就好……

而有一些观点, 可以发出来一起看看, 或多或少得到一些感受

梳理思路

我主要的知识管理工具是gollum, 以及evernote作为辅助, 在工作以及学习的过程中, 会碰到某个问题的方方面面, 各种细节, 散而且乱, 分布在不同地方, 而发个博客出来, 主要是可以花一两个小时, 对某块进行汇总, 然后重新梳理, 得到一个较为完整的内容, 顺手从笔记中清掉.

总之, 类似于一个精粹的过程.

还有, 例如在读python源码的时候, 读源码, 做笔记, 写注释, 同时还要参考书籍和文档, 往往当时读懂了, 觉得很清晰, 但是过阵子再回去看下, 面对一堆杂乱无从下手, 而出博文的过程, 会顺着思路走, 绘制一些结构图流程图, 再回头看的时候, 往往几分钟就能全盘了然

搜索

gollum和evernote的搜索其实做的都还不错, 但是有时候搜一个点, 得到不止一篇的结果, 往往要点好多次才能找到, 而发博文后, 顺手笔记中清掉, 此时在脑中已经有个印象, 某个点我详细写过什么东西, 那么剩下的只是一键打开博客, 找到那篇文章即可.

另一个好处是, gollum和evernote是本地的, 在别人电脑上处理问题的时候, 博客反正到哪都能访问到

写博的过程, 更多的是自己记录, 思考, 成长的过程, 坚持下来, 感觉还是收获颇多.

明确目的, 不要把这个写博客的日常变成功利, 其实这次找工作的过程发现, 写博客或许加分了, 但是就是过简历那个环节而已, 太过功利会没必要, 花费大量时间并不值得. 更多的是, 做事情, 把事情做好, 然后得到一些积累和感悟, 而不是反之.

PS: 其实github开源也是一样, 做自己感兴趣的事情, 而不是去为了开源而开源

后续, 会主要关注两方面, 一块是偏底层的东西, 构建基础的知识体系, 另一块是做业务/项目过程中的总结.

编码不易, 且行且珍惜, 共勉

wklken

2015-09-26 于深圳

APUE笔记-第一章 UNIX基础知识

Wed, 23 Sep 2015 08:00:00 +0800

最近在找工作, 额, 从七月份一直休息到九月初, 开始找, 结果发现快到十月了, 节点不是很好, 要过两个节, 所以估计入职什么的要到节后了>_<#

这几个月也在思考一些东西, 顺手也解决掉了Python源码剖析, 目前在逐步梳理笔记

发现自己首次做笔记还是太杂太乱, 堆在wiki里面一大坨的感觉, 还是要梳理画图, 思路更清晰些, 静候吧, 还是十篇左右的样子

读APUE, 做法比较残忍, 把书切开, 拆成一章一章地装订, 方便携带和阅读, 最后发现画满了一堆东西

发现还是不方便自己查阅, 所以还是决定重读, 转成笔记, 放到博客上方便搜索/查阅

对了, 代码之前只是下了看到的时候run下, 这次重读写写注释, 放到github了, 链接

在此感谢作者W.Richard Stevens :) 这本书五星好评, 建议如果搞linux相关后端, 可以读下

第一章 UNIX基础知识

Unix体系结构: 内核与系统调用

内核(kernel): 严格意义上, 将操作系统定义为一种软件, 它控制计算机硬件资源, 提供程序运行环境(相对较小, 位于环境的中心)

系统调用(system call): 内核的接口

关系: 公用函数库构建在系统调用接口之上, 应用软件既可以使用公用函数库, 也可以使用系统调用

登陆

口令文件/etc/passwd, 七个字段,冒号分隔

登录名:加密口令:数值用户 ID: 数值组 ID: 注释字段:起始目录:shell

加密口令已经转移到另一个文件

shell: 一个命令行解释器, 它读取用户输入, 然后执行命令

Linux 默认shell是Bourne-again shell

文件和目录

文件系统: 目录和文件组成的一种层次接口, 目录的起点称为根(root), 其名字是\\

目录(directory)是一个包含许多目录项的文件

文件名(filename): 不能出现斜线/和空操作符null(好的习惯只使用印刷字符的一个子集作为文件名字符)

创建目录时, 会自动创建两个文件名, 当前目录. 以及父目录..

路径名(pathname): 一个或多个以斜线分割的文件名序列. 以斜线开头的是绝对路径(absolute pathname), 否则是相对路径(relative pathname)

ls.c源代码

#include "apue.h"
#include 

// 可编译执行
// apue.h, 包含某些标准头文件, 定义了很多常量及库函数

int
main(int argc, char *argv[])
{
    DIR                *dp;
    // 结构体
    struct dirent    *dirp;

    // 需要至少一个参数
    if (argc != 2)
        // apue.h自定义函数
        err_quit("usage: ls directory_name");

    // 赋值后判断, opendir返回指向 DIR 结构体的指针
    if ((dp = opendir(argv[1])) == NULL)
        // apue.h自定义函数err_sys
        err_sys("can't open %s", argv[1]);

    // 赋值后判断, 读每一项, 返回指向readdir结构的指针或null(没有目录项可读时)
    while ((dirp = readdir(dp)) != NULL)
        // 取出每个目录的名字
        printf("%s\n", dirp->d_name);

    closedir(dp);

    // 终止程序, 0正常结束, 1-255出错
    exit(0);
}

工作目录(working directory), 每个进程都有一个, 优势成为当前工作目录, 进程可以通过chdir函数更改其工作目录.

输入和输出

文件描述符(file descriptor), 一个小的负整数, 内核使用它标识一个特定进程正在访问的文件. 当内核打开或创建一个新文件时, 返回一个文件描述符, 在读写的时候使用

每当运行一个新程序时, 所有的shell都为其打开三个文件描述符: 标准输入(standard input), 标准输出(standard output)以及标准错误(standard error)

不用缓冲的I/O 函数open/read/write/lseek/close

mycat.c源码

#include "apue.h"

/* 缓冲区大小, 常量 */
#define    BUFFSIZE    4096

int
main(void)
{
    int     n;
    char    buf[BUFFSIZE];

    /* STDIN_FILENO/STDOUT_FILENO -> apue.h -> unisted.h, 标准输入文件描述符0/标准输出文件描述符1 */

    /* 从标准输入读, read返回读得的字节数, 读到末端返回0, 发生错误返回-1 */
    while ((n = read(STDIN_FILENO, buf, BUFFSIZE)) > 0)
        /* 写到标准输入 */
        if (write(STDOUT_FILENO, buf, n) != n)
            err_sys("write error");

    /* 发生错误 */
    if (n < 0)
        err_sys("read error");

    exit(0);
}

标准I/O函数: 提供了一种对不用缓冲 I/O 函数的带缓冲接口, 可以无需担心如何选取最佳的缓冲区大小

getputc.c源码

#include "apue.h"


/* stdin/stdout -> apue.h -> stdio.h 标准输入文件/标准输出文件 */
/* EOF为stdio.h中定义的常量 */

int
main(void)
{
    int c;

    /* 从标准输入中读入一个字符 */
    while ((c = getc(stdin)) != EOF)
        /* 输出到标准输出 */
        if (putc(c, stdout) == EOF)
            err_sys("output error");

    if (ferror(stdin))
        err_sys("input error");

    exit(0);
}

程序和进程

程序(program): 存放在磁盘上, 处于某个目录中的一个可执行文件.(使用6个exec函数中的一个有内核将程序读入存储器, 并使其执行)

进程(process): 程序的执行实例

进程ID(process ID), 每个进程都有一个唯一的数字标识符, 总是一非负整数

hello.c 源码

#include "apue.h"

int
main(void)
{
    /* getpid得到进程pid */
    printf("hello world from process ID %ld\n", (long)getpid());
    exit(0);
}

进程控制: 三个主要函数, fork/exec(六种变体)/waitpid

shell1.c 源码

#include "apue.h"
#include 


/* fork创建一个新进程, 它被调用一次(由父进程调用), 返回两次(在父进程中返回子进程的进程ID, 在子进程中返回0) */

int
main(void)
{
    char    buf[MAXLINE];    /* from apue.h */
    pid_t    pid;
    int        status;

    printf("%% ");    /* print prompt (printf requires %% to print %) */

    /* 读入一行, 每一行命令会产生一个子进程用于执行 */
    while (fgets(buf, MAXLINE, stdin) != NULL) {
        /* 去掉换行符 */
        if (buf[strlen(buf) - 1] == '\n')
            buf[strlen(buf) - 1] = 0; /* replace newline with null */

        /* 执行读入的命令 */
        /* fork创建一个子进程, 返回<0则表示fork发生了错误 */
        if ((pid = fork()) < 0) {
            err_sys("fork error");

        /* 对于子进程, fork返回的pid=0(父进程fork返回的pid>0) */
        } else if (pid == 0) {        /* child */

            /* 调用execlp以执行从标准输入读入的命令 */
            /* fork+exec组合, 是某些操作系统所称的产生(spawn)一个新的进程 */
            execlp(buf, buf, (char *)0);
            err_ret("couldn't execute: %s", buf);
            /* 退出 */
            exit(127);
        }

        /* 父进程, 等待子进程终止 */
        /* pid为子进程id, status为子进程终止状态(用于判断其实如何终止的) */
        /* parent */
        if ((pid = waitpid(pid, &status, 0)) < 0)
            err_sys("waitpid error");
        printf("%% ");
    }
    exit(0);

通常, 一个进程只有一个控制线程(thread), 同一时刻只执行一组机器指令.(对于某些问题, 如果不同部分各使用一个控制线程, 那么整个问题解决相对容易, 多个控制线程也能充分利用多处理器系统的并行性)

在一个进程内的所有线程共享同一地址空间/文件描述符/栈以及与进程相关的属性(所以各线程在访问共享数据时需要采取同步措施以避免不一致性)

线程也用 ID 标识, 但只在其所属进程内起作用

出错处理

UNIX 函数出错的时候, 常常返回一个负值, 而整型变量errno通常被设置为含有附加信息的一个值

errno.h中, 定义了符号errno以及可以赋予它的各种常量.(errno(3)手册中)

对于errno两条规则

1. 如果没有出错, 其值则不会被一个例程清楚, 因此, 仅当函数的返回值指明出错时, 才检验其值
2. 任一函数都不会将errno值设置为0, 在errnoh中定义的所有常量都不为0

testerror.c 源码

#include "apue.h"
#include 


/* strerror, 将errnum映射为一个出错信息字符串, 并且返回此字符串的指针 */
/* perror, 基于errno的当前值, 在标准出错上产生一条出错信息, 然后返回 */

int
main(int argc, char *argv[])
{
    /* 常量 EACCES / ENOENT */
    fprintf(stderr, "EACCES: %s\n", strerror(EACCES));
    errno = ENOENT;
    perror(argv[0]);
    exit(0);
}

出错恢复: errno.h中定义的各种出错分为致命性和非致命性两类.

致命性出错: 无法执行恢复动作, 最多只能在屏幕上打印一条出错信息, 或写入日志, 然后终止

非致命性出错: 可以较为妥善地处理

用户标识

用户ID(user ID), 数值, 系统中标识各个不同的用户, 每个用户唯一(用户不能更改其用户 ID)

用户 ID 为0的用户为根( root) 或超级用户(superuser)

组ID(group ID), 一个数值, 指定用户登陆名时同时指定的. 允许同组各个成员之间共享资源

组文件将组名映射为数字 ID, /etc/group

口令文件包含: 登录名 = 用户 ID 的映射

组文件包含: 组名 = 组ID 的映射

打印用户ID和组ID

uidgid.c 源码

#include "apue.h"

int
main(void)
{
    /* getuid / getgid */
    printf("uid = %d, gid = %d\n", getuid(), getgid());
    exit(0);
}

附加组ID

允许一个用户属于多个组, 最多16个.

信号

信号(signal): 通知进程已发生某种情况的一种技术.

e.g. 一个进程执行除法操作, 其除数为0, 则将名为SIGFPE的信号发给该进程

进程如何处理信号?

1. 忽略该信号
2. 按系统默认方式处理.
3. 提供一个函数, 信号发生时则调用该函数(捕捉信号)

信号捕捉

shell2.c 源码

#include "apue.h"
#include 

/* 声明信号处理函数 */
static void    sig_int(int);        /* our signal-catching function */

int
main(void)
{
    char    buf[MAXLINE];    /* from apue.h */
    pid_t    pid;
    int        status;


    /* signal函数, 指定SIGINT 到处理函数 sig_int */
    /* 机制, 类似于直接注册到了进程, 观察是否异常发生后捕获处理 */
    if (signal(SIGINT, sig_int) == SIG_ERR)
        err_sys("signal error");

    printf("%% ");    /* print prompt (printf requires %% to print %) */
    while (fgets(buf, MAXLINE, stdin) != NULL) {
        if (buf[strlen(buf) - 1] == '\n')
            buf[strlen(buf) - 1] = 0; /* replace newline with null */

        if ((pid = fork()) < 0) {
            err_sys("fork error");
        } else if (pid == 0) {        /* child */
            execlp(buf, buf, (char *)0);
            err_ret("couldn't execute: %s", buf);
            exit(127);
        }

        /* parent */
        if ((pid = waitpid(pid, &status, 0)) < 0)
            err_sys("waitpid error");
        printf("%% ");
    }
    exit(0);
}


/* 处理函数, 打印 */
void
sig_int(int signo)
{
    printf("interrupt\n%% ");
}

时间值

UNIX系统两种不同的时间值

日历时间, time_t, 从1970年1月1日00:00:00以来的国际标准时间UTC锁经过的秒数

进程时间, clock_t, CPU时间, 度量进程使用的中央处理器资源, 以始终滴答计算

Unix系统使用三个进程时间

1. 时钟时间, 总时间, real
2. 用户cpu时间, 执行用户指令耗时, user
3. 系统cpu时间, 执行内核程序耗时, sys

系统调用和库函数

所有操作系统都提供多种服务的入口点(系统调用), 程序由此想内核请求服务

UNIX所使用的技术是为每个系统调用在标准 C 库中设置一个具有同样名字的函数. 用户进程用标准 C 调用序列来调用这些函数, 然后函数又用系统所要求的技术调用相应的内核服务

系统调用通常提供一种最小接口，而库函数通常提供比较复杂的功能。

系统调用: 最小接口, 单一职责, 不可替换

C库函数: 复杂功能, 可替换, 可自行定义

Python源码阅读-闭包的实现

Fri, 04 Sep 2015 08:00:00 +0800

闭包

e.g.

def add(x):
    def do_add(value):
        return x + value
    return do_add

add_5 = add(5)
print add_5(1)  # 6
print add_5(2)  # 7

需要回答, 什么是闭包, CPython底层是如何实现的?

PyCodeObject

typedef struct {
    PyObject_HEAD
    int co_argcount;		/* #arguments, except *args */
    int co_nlocals;		    /* #local variables */
    int co_stacksize;		/* #entries needed for evaluation stack */
    int co_flags;		    /* CO_..., see below */
    PyObject *co_code;		/* instruction opcodes */
    PyObject *co_consts;	/* list (constants used) */
    PyObject *co_names;		/* list of strings (names used) */
    PyObject *co_varnames;	/* tuple of strings (local variable names) */

    // 保存使用了的外层作用域中的变量名集合 (编译时就知道的! 被嵌套的时候有用)
    PyObject *co_freevars;	/* tuple of strings (free variable names) */
    // 保存嵌套作用域中使用的变量名集合, (编译时就知道的! 包含嵌套函数时有用)
    PyObject *co_cellvars;      /* tuple of strings (cell variable names) */


    /* The rest doesn't count for hash/cmp */
    PyObject *co_filename;	/* string (where it was loaded from) */
    PyObject *co_name;		/* string (name, for reference) */
    int co_firstlineno;		/* first source line number */
    PyObject *co_lnotab;	/* string (encoding addr<->lineno mapping) See
				   Objects/lnotab_notes.txt for details. */
    void *co_zombieframe;     /* for optimization only (see frameobject.c) */
    PyObject *co_weakreflist;   /* to support weakrefs to code objects */
} PyCodeObject;

我们关注两个, co_freevars 和 co_cellvars

co_freevars, 保存使用了的外层作用域中的变量名集合 (编译时就知道的! 被嵌套的时候有用)

co_cellvars, 保存嵌套作用域中使用的变量名集合, (编译时就知道的! 包含嵌套函数时有用)

对于我们上面的那个示例, add是外层函数, do_add是嵌套函数, 我们可以通过func_code打印看看

def add(x):    # 外层函数
    # 外层函数, 没有使用了外层作用域变量, 被嵌套函数使用了'x'
    print add.func_code.co_freevars    # ()
    print add.func_code.co_cellvars    # ('x',)

    def do_add(value):  # 嵌套函数
        return x + value

    # 内层函数, 使用了外层作用域便令'x', 没有嵌套函数故嵌套作用域变量名集合空
    print do_add.func_code.co_freevars # ('x',)
    print do_add.func_code.co_cellvars # ()
    return do_add

此时图示

这时候, 只是记录了使用到的变量名, 标记下是否使用了外层的/被内层使用的变量

具体的值是在运行时确定的, 例如

add(5)

此时x=5, 这个是在add的名字空间里面的, 那么, x=5是怎么传递到嵌套函数内? 嵌套函数又是如何知晓x的值?

记住这两个问题, 然后我们首先来看一个新的数据结构

PyCellObject

  typedef struct {
    PyObject_HEAD
    PyObject *ob_ref;   /* Content of the cell or NULL when empty */ => 指向一个PyObject
  } PyCellObject;


  PyObject *
  PyCell_New(PyObject *obj)
  {
      PyCellObject *op;

      op = (PyCellObject *)PyObject_GC_New(PyCellObject, &PyCell_Type);
      if (op == NULL)
          return NULL;
      op->ob_ref = obj;  //建立关系
      Py_XINCREF(obj);

      _PyObject_GC_TRACK(op);
      return (PyObject *)op;
  }

这是个很简单的基本对象, 有一个ob_ref指向另一个PyObject, 仅此而已

图示

作用呢?

值的确认与传递过程

调用

add(5)

此时, 开始调用函数

CALL_FUNCTION

=> x = call_function(&sp, oparg);

=> x = fast_function(func, pp_stack, n, na, nk);

      return PyEval_EvalCodeEx(co, globals,
                               (PyObject *)NULL, (*pp_stack)-n, na,
                               (*pp_stack)-2*nk, nk, d, nd,
                               PyFunction_GET_CLOSURE(func));

=>

PyEval_EvalCodeEx

add(5), 此时其co_cellvars = ('x',) 非空, 将会执行的逻辑代码


      /* Allocate and initialize storage for cell vars, and copy free
         vars into frame.  This isn't too efficient right now. */
      if (PyTuple_GET_SIZE(co->co_cellvars)) {
          int i, j, nargs, found;
          char *cellname, *argname;
          PyObject *c;

          nargs = co->co_argcount;
          if (co->co_flags & CO_VARARGS)
              nargs++;
          if (co->co_flags & CO_VARKEYWORDS)
              nargs++;

          /* Initialize each cell var, taking into account
             cell vars that are initialized from arguments.

             Should arrange for the compiler to put cellvars
             that are arguments at the beginning of the cellvars
             list so that we can march over it more efficiently?
          */

          // for 循环遍历 co_cellvars = ('x', ), i = 0
          for (i = 0; i < PyTuple_GET_SIZE(co->co_cellvars); ++i) {

              // cellname = 'x'
              cellname = PyString_AS_STRING(
                  PyTuple_GET_ITEM(co->co_cellvars, i));
              found = 0;

              // 遍历函数的参数变量, narg=1, j=0
              for (j = 0; j < nargs; j++) {

                  // 访问当前名字空间
                  argname = PyString_AS_STRING(
                      PyTuple_GET_ITEM(co->co_varnames, j));

                  // 匹配上了
                  if (strcmp(cellname, argname) == 0) {

                      // new 一个 PyCellObject, ob_ref指向变量的PyObject
                      c = PyCell_New(GETLOCAL(j));
                      if (c == NULL)
                          goto fail;

                      // #define GETLOCAL(i)     (fastlocals[i])
                      // fastlocals = f->f_localsplus;
                      // 即 f->f_localsplus[co->co_nlocals + i] = c, 相当于放到下一层freevars变量
                      GETLOCAL(co->co_nlocals + i) = c;
                      found = 1;
                      break;
                  }
              }

              // 没有匹配, 给个指向NULL的PyCellObject, 先New一个对象占位
              if (found == 0) {
                  c = PyCell_New(NULL);
                  if (c == NULL)
                      goto fail;
                  SETLOCAL(co->co_nlocals + i, c); //注意内存地址
              }
          }
      }

逻辑即, 如果发现当前函数co_cellvars非空, 即表示存在被内层函数调用的变量, 那么遍历这个co_cellvars集合, 拿到集合中每个变量名在当前名字空间中的值, 然后放到当前函数的f->f_localsplus中.

这里, 我们可以知道x=5被放进去了

为什么放到f->f_localsplus中呢?

看看PyFrameObject

typedef struct _frame {
    PyObject_VAR_HEAD
    struct _frame *f_back;	/* previous frame, or NULL */
    PyCodeObject *f_code;	/* code segment */
    PyObject *f_builtins;	/* builtin symbol table (PyDictObject) */
    PyObject *f_globals;	/* global symbol table (PyDictObject) */
    PyObject *f_locals;		/* local symbol table (any mapping) */
    PyObject **f_valuestack;	/* points after the last local */
    /* Next free slot in f_valuestack.  Frame creation sets to f_valuestack.
       Frame evaluation usually NULLs it, but a frame that yields sets it
       to the current stack top. */
    PyObject **f_stacktop;
    PyObject *f_trace;		/* Trace function */

    /* If an exception is raised in this frame, the next three are used to
     * record the exception info (if any) originally in the thread state.  See
     * comments before set_exc_info() -- it's not obvious.
     * Invariant:  if _type is NULL, then so are _value and _traceback.
     * Desired invariant:  all three are NULL, or all three are non-NULL.  That
     * one isn't currently true, but "should be".
     */
    PyObject *f_exc_type, *f_exc_value, *f_exc_traceback;

    PyThreadState *f_tstate;
    int f_lasti;		/* Last instruction if called */
    /* Call PyFrame_GetLineNumber() instead of reading this field
       directly.  As of 2.3 f_lineno is only valid when tracing is
       active (i.e. when f_trace is set).  At other times we use
       PyCode_Addr2Line to calculate the line from the current
       bytecode index. */
    int f_lineno;		/* Current line number */
    int f_iblock;		/* index in f_blockstack */
    PyTryBlock f_blockstack[CO_MAXBLOCKS]; /* for try and loop blocks */
    PyObject *f_localsplus[1];	/* locals+stack, dynamically sized */
} PyFrameObject;

注意f_localsplus

f_localsplus为一个PyObject的指针数组，大小为1。

c语言中, 当申请一个大小超过sizeof(PyFrameObject)的结构体对象时，超过的部分就自动分配给f_localsplus

创建过程

在call_function的时候, new了一个PyFrameObject

f = PyFrame_New(tstate, co, globals, locals);

=>

PyFrameObject *
PyFrame_New(PyThreadState *tstate, PyCodeObject *code, PyObject *globals,
            PyObject *locals)
{
        Py_ssize_t extras, ncells, nfrees;
        ncells = PyTuple_GET_SIZE(code->co_cellvars);
        nfrees = PyTuple_GET_SIZE(code->co_freevars);
        extras = code->co_stacksize + code->co_nlocals + ncells +
            nfrees;

=>

f = PyObject_GC_NewVar(PyFrameObject, &PyFrame_Type, extras);

即

f_localsplus => 局部变量 + cell对象 + free对象 + 运行时栈

原因: 因为函数中的局部变量总是固定不变的, 在编译时就能确定局部变量使用的内存空间的位置, 也能确定访问局部变量的字节码应该如何访问内存, 有了这些信息, Python就能借助静态的方法实现局部变量, 而不是动态查找PyDictObject, 提高执行效率

示例函数的f_localsplus

看一下上面赋值用的宏定义

  fastlocals = f->f_localsplus;
  #define GETLOCAL(i)     (fastlocals[i])
  #define SETLOCAL(i, value)      do { PyObject *tmp = GETLOCAL(i); \
                                       GETLOCAL(i) = value; \
                                       Py_XDECREF(tmp); } while (0)

最终得到

接下去呢? CALL_FUNCTION最后怎么处理将cell传入嵌套函数?

传递

CALL_FUNCTION 完成new一个PyFrameObject之后,

最终执行这个frame

retval = PyEval_EvalFrameEx(f,0);

PyEval_EvalFrameEx

  PyObject *
  PyEval_EvalFrameEx(PyFrameObject *f, int throwflag)
  {

    fastlocals = f->f_localsplus;
    freevars = f->f_localsplus + co->co_nlocals;


=> 此时涉及op_code的执行了

查看一下dis的结果

def add(x):
    def do_add(value):
        return x + value
    return do_add

  5           0 LOAD_CLOSURE             0 (x)
              3 BUILD_TUPLE              1
              6 LOAD_CONST               1 (<code object do_add at 0x10c9cec30, file "a.py", line 5>)
              9 MAKE_CLOSURE             0
             12 STORE_FAST               1 (do_add)

  7          15 LOAD_FAST                1 (do_add)
             18 RETURN_VALUE

首先LOAD_CLOSURE 0

          case LOAD_CLOSURE:
              x = freevars[oparg];
              Py_INCREF(x);
              PUSH(x);
              if (x != NULL) continue;
              break;

入栈, 此时得到一个PyCellObject, 指向2, name='x'

LOAD_CLOSURE 在编译时会根据嵌套函数中 co_freevars, 决定了取得参数位置和个数

然后, BUILD_TUPLE, 将cell对象打包成tuple, 得到('x', )

然后, 开始, 载入嵌套函数do_add, 入栈

调用MAKE_CLOSURE

          case MAKE_CLOSURE:
          {
              v = POP(); /* code object */  // do_add函数
              x = PyFunction_New(v, f->f_globals); //绑定global名字空间
              // 到这里, 得到一个PyFunctionObject

              Py_DECREF(v);
              if (x != NULL) {
                  v = POP();   // 得到tuple, ('x', )

                  // 注意这里
                  if (PyFunction_SetClosure(x, v) != 0) {
                      /* Can't happen unless bytecode is corrupt. */
                      why = WHY_EXCEPTION;
                  }
                  Py_DECREF(v);
              }
              ......
          }

来关注一下 PyFunction_SetClosure

int
PyFunction_SetClosure(PyObject *op, PyObject *closure)
{
    ...
    Py_XDECREF(((PyFunctionObject *) op) -> func_closure);
    ((PyFunctionObject *) op) -> func_closure = closure;  // 注意这里
    return 0;
}

即do_add的 PyFunctionObject的func_closure指向一个tuple

注意: 这时候, 外层变量已经固定下来了!!!!!!

然后, 在嵌套函数被调用的时候

CALL_FUNCTION

=>

x = call_function(&sp, oparg);

=>

x = fast_function(func, pp_stack, n, na, nk);

=>

      return PyEval_EvalCodeEx(co, globals,
                               (PyObject *)NULL, (*pp_stack)-n, na,
                               (*pp_stack)-2*nk, nk, d, nd,
                               PyFunction_GET_CLOSURE(func));

看下PyFunction_GET_CLOSURE

  #define PyFunction_GET_CLOSURE(func) \
      (((PyFunctionObject *)func) -> func_closure)

然后, 进入 PyEval_EvalCodeEx, 注意这里的closure参数即上一步取出来的func_closure, 即外层函数传进来的tuple

  PyObject *
  PyEval_EvalCodeEx(PyCodeObject *co, PyObject *globals, PyObject *locals,
             PyObject **args, int argcount, PyObject **kws, int kwcount,
             PyObject **defs, int defcount, PyObject *closure)
{
      ......
      //  嵌套函数do_add, 使用到了外层函数的变量, 所以co->co_freevars非空, 这里得到 ('x', )
      if (PyTuple_GET_SIZE(co->co_freevars)) {
          int i;
          for (i = 0; i < PyTuple_GET_SIZE(co->co_freevars); ++i) {
              // 顺序是一致的
              PyObject *o = PyTuple_GET_ITEM(closure, i);
              Py_INCREF(o);
              // 放到freevars里面, 编译时已经确定了顺序
              // 在上一步多LOAD_CLOSURE => tuple 已经保证了顺序
              freevars[PyTuple_GET_SIZE(co->co_cellvars) + i] = o;
          }
      }
      ......

最后, 再来看一个闭包的dis

注意BUILD_TUPLE

def add(x, y):

    def do_add(value):
        return x + value

    def do_add2(value):
        return y + value

    def do_add3(value):
        return x + y + value

    return do_add

dis结果

 18           0 LOAD_CLOSURE             0 (x)
              3 BUILD_TUPLE              1
              6 LOAD_CONST               1 (<code object do_add at 0x10560dc30, file "a.py", line 18>)
              9 MAKE_CLOSURE             0
             12 STORE_FAST               2 (do_add)

 21          15 LOAD_CLOSURE             1 (y)
             18 BUILD_TUPLE              1
             21 LOAD_CONST               2 (<code object do_add2 at 0x10560d8b0, file "a.py", line 21>)
             24 MAKE_CLOSURE             0
             27 STORE_FAST               3 (do_add2)

 24          30 LOAD_CLOSURE             0 (x)
             33 LOAD_CLOSURE             1 (y)
             36 BUILD_TUPLE              2
             39 LOAD_CONST               3 (<code object do_add3 at 0x10560e3b0, file "a.py", line 24>)
             42 MAKE_CLOSURE             0
             45 STORE_FAST               4 (do_add3)

 32          48 LOAD_FAST                2 (do_add)
             51 RETURN_VALUE

Python源码阅读-内存管理机制(二)

Sat, 29 Aug 2015 20:54:00 +0800

Python 的内存分配策略

arena

arena: 多个pool聚合的结果

arena size

pool的大小默认值位4KB

arena的大小默认值256KB, 能放置 256/4=64 个pool

obmalloc.c中代码

#define ARENA_SIZE              (256 << 10)     /* 256KB */

arena 结构

一个完整的arena = arena_object + pool集合

typedef uchar block;

/* Record keeping for arenas. */
struct arena_object {
    /* The address of the arena, as returned by malloc.  Note that 0
     * will never be returned by a successful malloc, and is used
     * here to mark an arena_object that doesn't correspond to an
     * allocated arena.
     */
    uptr address;

    /* Pool-aligned pointer to the next pool to be carved off. */
    block* pool_address;

    /* The number of available pools in the arena:  free pools + never-
     * allocated pools.
     */
    uint nfreepools;

    /* The total number of pools in the arena, whether or not available. */
    uint ntotalpools;

    /* Singly-linked list of available pools. */
    // 单链表, 可用pool集合
    struct pool_header* freepools;

    /* Whenever this arena_object is not associated with an allocated
     * arena, the nextarena member is used to link all unassociated
     * arena_objects in the singly-linked `unused_arena_objects` list.
     * The prevarena member is unused in this case.
     *
     * When this arena_object is associated with an allocated arena
     * with at least one available pool, both members are used in the
     * doubly-linked `usable_arenas` list, which is maintained in
     * increasing order of `nfreepools` values.
     *
     * Else this arena_object is associated with an allocated arena
     * all of whose pools are in use.  `nextarena` and `prevarena`
     * are both meaningless in this case.
     */
    // arena链表
    struct arena_object* nextarena;
    struct arena_object* prevarena;
};

arena_object的作用

1. 与其他arena连接, 组成双向链表
2. 维护arena中可用的pool, 单链表
3. 其他信息

pool_header 与 arena_object

pool_header和管理的blocks内存是一块连续的内存 => pool_header被申请时, 其管理的block集合的内存一并被申请
arena_object和其管理的内存是分离的 => arena_object被申请时, 其管理的pool集合的内存没有被申请, 而是在某一时刻建立的联系

arena的两种状态

arena存在两种状态: 未使用(没有建立联系)/可用(建立了联系)

全局由两个链表维护着

/* The head of the singly-linked, NULL-terminated list of available
 * arena_objects.
 */
// 单链表
static struct arena_object* unused_arena_objects = NULL;

/* The head of the doubly-linked, NULL-terminated at each end, list of
 * arena_objects associated with arenas that have pools available.
 */
// 双向链表
static struct arena_object* usable_arenas = NULL;

arena的初始化

首先, 来看下初始化相关的一些参数定义

代码obmalloc.c

/* Array of objects used to track chunks of memory (arenas). */
// arena_object 数组
static struct arena_object* arenas = NULL;

/* Number of slots currently allocated in the `arenas` vector. */
// 当前arenas中管理的arena_object的个数, 初始化时=0
static uint maxarenas = 0;

/* How many arena_objects do we initially allocate?
 * 16 = can allocate 16 arenas = 16 * ARENA_SIZE = 4MB before growing the
 * `arenas` vector.
 */
// 初始化时申请的arena_object个数
#define INITIAL_ARENA_OBJECTS 16

/* Number of arenas allocated that haven't been free()'d. */
static size_t narenas_currently_allocated = 0;


/* The head of the singly-linked, NULL-terminated list of available
 * arena_objects.
 */
// 未使用状态arena的单链表
static struct arena_object* unused_arena_objects = NULL;

/* The head of the doubly-linked, NULL-terminated at each end, list of
 * arena_objects associated with arenas that have pools available.
 */
// 可用状态arena的双向链表
static struct arena_object* usable_arenas = NULL;

然后, 看下obmalloc.c中arena初始化的代码

/* Allocate a new arena.  If we run out of memory, return NULL.  Else
 * allocate a new arena, and return the address of an arena_object
 * describing the new arena.  It's expected that the caller will set
 * `usable_arenas` to the return value.
 */
static struct arena_object*
new_arena(void)
{
    struct arena_object* arenaobj;
    uint excess;        /* number of bytes above pool alignment */
    void *address;
    int err;

    // 判断是否需要扩充"未使用"的arena_object列表
    if (unused_arena_objects == NULL) {
        uint i;
        uint numarenas;
        size_t nbytes;

        /* Double the number of arena objects on each allocation.
         * Note that it's possible for `numarenas` to overflow.
         */
        // 确定需要申请的个数, 首次初始化, 16, 之后每次翻倍
        numarenas = maxarenas ? maxarenas << 1 : INITIAL_ARENA_OBJECTS;
        if (numarenas <= maxarenas)
            return NULL;                /* overflow */  //溢出了

        ....

        nbytes = numarenas * sizeof(*arenas);
        // 申请内存
        arenaobj = (struct arena_object *)realloc(arenas, nbytes);
        if (arenaobj == NULL)
            return NULL;
        arenas = arenaobj;

        /* We might need to fix pointers that were copied.  However,
         * new_arena only gets called when all the pages in the
         * previous arenas are full.  Thus, there are *no* pointers
         * into the old array. Thus, we don't have to worry about
         * invalid pointers.  Just to be sure, some asserts:
         */
        assert(usable_arenas == NULL);
        assert(unused_arena_objects == NULL);

        // 初始化
        /* Put the new arenas on the unused_arena_objects list. */
        for (i = maxarenas; i < numarenas; ++i) {
            arenas[i].address = 0;              /* mark as unassociated */
            // 新申请的一律为0, 标识着这个arena处于"未使用"
            arenas[i].nextarena = i < numarenas - 1 ?
                                   &arenas[i+1] : NULL;
        }

        // 将其放入unused_arena_objects链表中
        // unused_arena_objects 为新分配内存空间的开头
        /* Update globals. */
        unused_arena_objects = &arenas[maxarenas];

        // 更新数量
        maxarenas = numarenas;
    }

    /* Take the next available arena object off the head of the list. */
    assert(unused_arena_objects != NULL);

    // 从unused_arena_objects中, 获取一个未使用的object
    arenaobj = unused_arena_objects;
    unused_arena_objects = arenaobj->nextarena; // 更新链表

    // 开始处理这个 arenaobject

    assert(arenaobj->address == 0);
    // 申请内存, 256KB, 内存地址赋值给arena的address. 这块内存可用
#ifdef ARENAS_USE_MMAP
    address = mmap(NULL, ARENA_SIZE, PROT_READ|PROT_WRITE,
                   MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
    err = (address == MAP_FAILED);
#else
    address = malloc(ARENA_SIZE);
    err = (address == 0);
#endif
    if (err) {
        /* The allocation failed: return NULL after putting the
         * arenaobj back.
         */
        arenaobj->nextarena = unused_arena_objects;
        unused_arena_objects = arenaobj;
        return NULL;
    }
    arenaobj->address = (uptr)address;

    ++narenas_currently_allocated;

    // 设置pool集合相关信息
    arenaobj->freepools = NULL;  // 设置为NULL, 只有在释放一个pool的时候才有用
    /* pool_address <- first pool-aligned address in the arena
       nfreepools <- number of whole pools that fit after alignment */
    arenaobj->pool_address = (block*)arenaobj->address;
    arenaobj->nfreepools = ARENA_SIZE / POOL_SIZE;

    assert(POOL_SIZE * arenaobj->nfreepools == ARENA_SIZE);

    // 将pool的起始地址调整为系统页的边界
    // 申请到 256KB, 放弃了一些内存, 而将可使用的内存边界pool_address调整到了与系统页对齐
    excess = (uint)(arenaobj->address & POOL_SIZE_MASK);
    if (excess != 0) {
        --arenaobj->nfreepools;
        arenaobj->pool_address += POOL_SIZE - excess;
    }
    arenaobj->ntotalpools = arenaobj->nfreepools;

    return arenaobj;
}

图示: 初始化arenas数组, 初始化后的所有arena都在unused_arena_objects单链表里面

图示: 从arenas取一个arena进行初始化

没有可用的arena?

此时

    // 判断成立
    if (unused_arena_objects == NULL) {
        ....
        // 确定需要申请的个数, 首次初始化, 16, 之后每次翻倍
        numarenas = maxarenas ? maxarenas << 1 : INITIAL_ARENA_OBJECTS;

然后, 假设第一次分配了16个, 发现没有arena之后, 第二次处理结果: numarenas = 32

即, 数组扩大了一倍

arena分配

new了一个全新的 arena之后,

  void *
  PyObject_Malloc(size_t nbytes)
  {
            // 刚开始没有可用的arena
            if (usable_arenas == NULL) {
              // new一个, 作为双向链表的表头
              usable_arenas = new_arena();
              if (usable_arenas == NULL) {
                  UNLOCK();
                  goto redirect;
              }

              usable_arenas->nextarena =
                  usable_arenas->prevarena = NULL;

           }

          .......

          // 从arena中获取一个pool
          pool = (poolp)usable_arenas->pool_address;
          assert((block*)pool <= (block*)usable_arenas->address +
                                 ARENA_SIZE - POOL_SIZE);
          pool->arenaindex = usable_arenas - arenas;
          assert(&arenas[pool->arenaindex] == usable_arenas);
          pool->szidx = DUMMY_SIZE_IDX;

          // 更新 pool_address 向下一个节点
          usable_arenas->pool_address += POOL_SIZE;
          // 可用节点数量-1
          --usable_arenas->nfreepools;



}

图示: 从全新的arena中获取一个pool

假设arena是旧的, 怎么分配的pool

          pool = usable_arenas->freepools;
          if (pool != NULL) {

这个arena->freepools是何方神圣?

当arena中一整块pool被释放的时候

  void
  PyObject_Free(void *p)
  {


              struct arena_object* ao;
              uint nf;  /* ao->nfreepools */

              /* Link the pool to freepools.  This is a singly-linked
               * list, and pool->prevpool isn't used there.
              */
              ao = &arenas[pool->arenaindex];
              pool->nextpool = ao->freepools;
              ao->freepools = pool;
              nf = ++ao->nfreepools;

也就是说, 在pool整块被释放的时候, 会将pool加入到arena->freepools作为单链表的表头, 然后, 在从非全新arena中分配pool时, 优先从arena->freepools里面取, 如果取不到, 再从arena内存块里面获取

图示

一个arena满了之后呢

很自然, 从下一个arena中获取

  void *
  PyObject_Malloc(size_t nbytes)
  {


          // 当发现用完了最后一个pool!!!!!!!!!!!
          // nfreepools = 0
          if (usable_arenas->nfreepools == 0) {
              assert(usable_arenas->nextarena == NULL ||
                     usable_arenas->nextarena->prevarena ==
                     usable_arenas);
              /* Unlink the arena:  it is completely allocated. */

              // 找到下一个节点!
              usable_arenas = usable_arenas->nextarena;
              // 右下一个
              if (usable_arenas != NULL) {
                  usable_arenas->prevarena = NULL; // 更新下一个节点的prevarens
                  assert(usable_arenas->address != 0);
              }
              // 没有下一个, 此时 usable_arenas = NULL, 下次进行内存分配的时候, 就会从arenas数组中取一个

          }

  }

注意: 这里有个逻辑, 就是每分配一个pool, 就检查是不是用到了最后一个, 如果是, 需要变更usable_arenas到下一个可用的节点, 如果没有可用的, 那么下次进行内存分配的时候, 会判定从arenas数组中取一个

arena回收

内存分配和回收最小单位是block, 当一个block被回收的时候, 可能触发pool被回收, pool被回收, 将会触发arena的回收机制

四种情况

1. arena中所有pool都是闲置的(empty), 将arena内存释放, 返回给操作系统
2. 如果arena中之前所有的pool都是占用的(used), 现在释放了一个pool(empty), 需要将 arena加入到usable_arenas, 会加入链表表头
3. 如果arena中empty的pool个数n, 则从useable_arenas开始寻找可以插入的位置. 将arena插入. (useable_arenas是一个有序链表, 按empty pool的个数, 保证empty pool数量越多, 被使用的几率越小, 最终被整体释放的机会越大)
4. 其他情况, 不对arena 进行处理

具体可以看PyObject_Free的代码

内存分配步骤

好的, 到这里, 我们已经知道了block和pool的关系(包括pool怎么管理block的), 以及arena和pool的关系(怎么从arena中拉到可用的pool)

那么, 在分析PyObject_Malloc(size_t nbytes)如何进行内存分配的时候, 我们就刨除掉这些管理代码

关注: 如何寻找得到一块可用的nbytes的block内存

其实代码那么多, 寻址得到对应的block也就这么几行代码, 其他代码都是pool没有, 找arena, 申请arena, arena没有, 找arenas, 最终的到一块pool, 初始化, 返回第一个block

如果有的情况, 用现成的

pool = usedpools[size + size];
if pool可用:
    pool 没满, 取一个block返回
    pool 满了, 从下一个pool取一个block返回
否则:
    获取arena, 从里面初始化一个pool, 拿到第一个block, 返回

从上面这个判断逻辑来看, 内存分配其实主要操作的是pool, 跟arena并不是基本的操作单元(只是用来管理pool的)

结论: 进行内存分配和销毁, 所有操作都是在pool上进行的

usedpools 是什么鬼? 其实是可用pool缓冲池, 后面说

内存池

arena 内存池的大小

取决于用户, Python提供的编译符号, 用于决定是否控制

obmalloc.c

#ifdef WITH_MEMORY_LIMITS
#ifndef SMALL_MEMORY_LIMIT
#define SMALL_MEMORY_LIMIT      (64 * 1024 * 1024)      /* 64 MB -- more? */
#endif
#endif

#ifdef WITH_MEMORY_LIMITS
#define MAX_ARENAS              (SMALL_MEMORY_LIMIT / ARENA_SIZE)
#endif

具体使用中, python并不直接与arenas和arena打交道, 当Python申请内存时, 最基本的操作单元并不是arena, 而是pool

问题: pool中所有block的size一样, 但是在arena中, 每个pool的size都可能不一样, 那么最终这些pool是怎么维护的? 怎么根据大小找到需要的block所在的pool? => usedpools

pool在内存池中的三种状态

1. used状态: pool中至少有一个block已经被使用, 并且至少有一个block未被使用. 这种状态的pool受控于Python内部维护的usedpool数组

2. full状态: pool中所有的block都已经被使用, 这种状态的pool在arena中, 但不在arena的freepools链表中
处于full的pool各自独立, 不会被链表维护起来

3. empty状态: pool中所有block都未被使用, 处于这个状态的pool的集合通过其pool_header中的nextpool构成一个链表, 链表的表头是arena_object中的freepools

usedpools

usedpools数组: 维护着所有处于used状态的pool, 当申请内存的时候, 会通过usedpools寻找到一块可用的(处于used状态的)pool, 从中分配一个block

结构:

  #define SMALL_REQUEST_THRESHOLD 512
  // 512/8 = 64
  #define NB_SMALL_SIZE_CLASSES   (SMALL_REQUEST_THRESHOLD / ALIGNMENT)

  #define PTA(x)  ((poolp )((uchar *)&(usedpools[2*(x)]) - 2*sizeof(block *)))
  #define PT(x)   PTA(x), PTA(x)

  // 2 * ((64 + 7) / 8) * 8 = 128, 大小为128的数组
  static poolp usedpools[2 * ((NB_SMALL_SIZE_CLASSES + 7) / 8) * 8] = {
      PT(0), PT(1), PT(2), PT(3), PT(4), PT(5), PT(6), PT(7)
  #if NB_SMALL_SIZE_CLASSES > 8
      , PT(8), PT(9), PT(10), PT(11), PT(12), PT(13), PT(14), PT(15)
  #if NB_SMALL_SIZE_CLASSES > 16
      , PT(16), PT(17), PT(18), PT(19), PT(20), PT(21), PT(22), PT(23)
  #if NB_SMALL_SIZE_CLASSES > 24
      , PT(24), PT(25), PT(26), PT(27), PT(28), PT(29), PT(30), PT(31)
  #if NB_SMALL_SIZE_CLASSES > 32
      , PT(32), PT(33), PT(34), PT(35), PT(36), PT(37), PT(38), PT(39)
  #if NB_SMALL_SIZE_CLASSES > 40
      , PT(40), PT(41), PT(42), PT(43), PT(44), PT(45), PT(46), PT(47)
  #if NB_SMALL_SIZE_CLASSES > 48
      , PT(48), PT(49), PT(50), PT(51), PT(52), PT(53), PT(54), PT(55)
  #if NB_SMALL_SIZE_CLASSES > 56
      , PT(56), PT(57), PT(58), PT(59), PT(60), PT(61), PT(62), PT(63)
  #if NB_SMALL_SIZE_CLASSES > 64
  #error "NB_SMALL_SIZE_CLASSES should be less than 64"
  #endif /* NB_SMALL_SIZE_CLASSES > 64 */
  #endif /* NB_SMALL_SIZE_CLASSES > 56 */
  #endif /* NB_SMALL_SIZE_CLASSES > 48 */
  #endif /* NB_SMALL_SIZE_CLASSES > 40 */
  #endif /* NB_SMALL_SIZE_CLASSES > 32 */
  #endif /* NB_SMALL_SIZE_CLASSES > 24 */
  #endif /* NB_SMALL_SIZE_CLASSES > 16 */
  #endif /* NB_SMALL_SIZE_CLASSES >  8 */
  };

  即

  // 得到usedpools数组
static poolp usedpools[128] = {
   PTA(0), PTA(0), PTA(1), PTA(1), PTA(2), PTA(2), PTA(3), PTA(3),
   ....
   PTA(63), PTA(63)
}

解开看(obmalloc.c)


  typedef uchar block;

  /* Pool for small blocks. */
  struct pool_header {
      union { block *_padding;
              uint count; } ref;          /* number of allocated blocks    */
      block *freeblock;                   /* pool's free list head         */
      struct pool_header *nextpool;       /* next pool of this size class  */
      struct pool_header *prevpool;       /* previous pool       ""        */
      uint arenaindex;                    /* index into arenas of base adr */
      uint szidx;                         /* block size class index        */
      uint nextoffset;                    /* bytes to virgin block         */
      uint maxnextoffset;                 /* largest valid nextoffset      */
  };
  typedef struct pool_header *poolp;
  usedpools[0] = PTA(0) = ((poolp )((uchar *)&(usedpools[0]) - 2*sizeof(block *)))
  usedpools[1] = PTA(0) = ((poolp )((uchar *)&(usedpools[0]) - 2*sizeof(block *)))



  *p = usedpools[0] => p->nextpool and p->prevpool are both p

为了看懂这步的trick, 心好累>_<#

直接上图

new一个pool时维护

init获得的情况, 其实就是将刚刚从arena中获取的pool加入到 usedpools 对应的双向链表中, 然后初始化, 然后返回block

         init_pool:
              /* Frontlink to used pools. */

              // 1. 获取得到usedpools链表头
              next = usedpools[size + size]; /* == prev */

              // 2. 将新的pool加入到双向链表
              pool->nextpool = next;
              pool->prevpool = next;
              next->nextpool = pool;
              next->prevpool = pool;
              pool->ref.count = 1;

              // 3. 后面的是具体pool和block的了
              if (pool->szidx == size) {
                  /* Luckily, this pool last contained blocks
                   * of the same size class, so its header
                   * and free list are already initialized.
                   */
                  bp = pool->freeblock;
                  pool->freeblock = *(block **)bp;
                  UNLOCK();
                  return (void *)bp;
              }
              /*
               * Initialize the pool header, set up the free list to
               * contain just the second block, and return the first
               * block.
               */
              pool->szidx = size;
              size = INDEX2SIZE(size);
              bp = (block *)pool + POOL_OVERHEAD;
              pool->nextoffset = POOL_OVERHEAD + (size << 1);
              pool->maxnextoffset = POOL_SIZE - size;
              pool->freeblock = bp + size;
              *(block **)(pool->freeblock) = NULL;
              UNLOCK();
              return (void *)bp;   // here
          }

从现有pool中获取block

从现有的pool, 其实就是 usedpools得到双向链表头部, 判断是不是空链表, 不是的话代表有可用的pool, 直接从里面获取

      if ((nbytes - 1) < SMALL_REQUEST_THRESHOLD) {
          LOCK();
          /*
           * Most frequent paths first
           */
          size = (uint)(nbytes - 1) >> ALIGNMENT_SHIFT;
          pool = usedpools[size + size];

          // 注意这里的判断, pool != pool-> nextpool 表示得到的链表不是空的
          if (pool != pool->nextpool) {
              /*
               * There is a used pool for this size class.
               * Pick up the head block of its free list.
               */
              ++pool->ref.count;
              bp = pool->freeblock;
              assert(bp != NULL);
              if ((pool->freeblock = *(block **)bp) != NULL) {
                  UNLOCK();
                  return (void *)bp;
              }
              /*
               * Reached the end of the free list, try to extend it.
               */
              if (pool->nextoffset <= pool->maxnextoffset) {
                  /* There is room for another block. */
                  pool->freeblock = (block*)pool +
                                    pool->nextoffset;
                  pool->nextoffset += INDEX2SIZE(size);
                  *(block **)(pool->freeblock) = NULL;
                  UNLOCK();
                  return (void *)bp;
              }
              /* Pool is full, unlink from used pools. */
              next = pool->nextpool;
              pool = pool->prevpool;
              next->prevpool = pool;
              pool->nextpool = next;
              UNLOCK();
              return (void *)bp;   // here
          }

全局结构

先这样吧, Python中整个内存池基本结构和机制大概如此, 是不是发现有好多数组/链表等等, 在分配/回收上处理下做成各种池…..

后面还有内存相关的就是垃圾收集了, 后面再说了吧

wklken

2015-08-29

Python源码阅读-内存管理机制(一)

Sat, 29 Aug 2015 08:00:00 +0800

==========================

基本阅读完了, 只是没时间梳理, 趁着这今天时间比较空

逐步梳理, 发上来……也算是小结下, 要开始准备简历找工作了>_<#

这篇略长, 带很多图, 所以一分为二

Python的内存管理架构

基本分层

在Objects/obmalloc.c源码中, 给了一个分层划分

    _____   ______   ______       ________
   [ int ] [ dict ] [ list ] ... [ string ]       Python core         |
+3 | <----- Object-specific memory -----> | <-- Non-object memory --> |
    _______________________________       |                           |
   [   Python's object allocator   ]      |                           |
+2 | ####### Object memory ####### | <------ Internal buffers ------> |
    ______________________________________________________________    |
   [          Python's raw memory allocator (PyMem_ API)          ]   |
+1 | <----- Python memory (under PyMem manager's control) ------> |   |
    __________________________________________________________________
   [    Underlying general-purpose allocator (ex: C library malloc)   ]
 0 | <------ Virtual memory allocated for the python process -------> |

   =========================================================================
    _______________________________________________________________________
   [                OS-specific Virtual Memory Manager (VMM)               ]
-1 | <--- Kernel dynamic storage allocation & management (page-based) ---> |
    __________________________________   __________________________________
   [                                  ] [                                  ]
-2 | <-- Physical memory: ROM/RAM --> | | <-- Secondary storage (swap) --> |

可以看到

layer 3: Object-specific memory(int/dict/list/string....)
         Python 实现并维护
         更高抽象层次的内存管理策略, 主要是各类特定对象的缓冲池机制. 具体见前面几篇涉及的内存分配机制

layer 2: Python's object allocator
         Python 实现并维护
         实现了创建/销毁Python对象的接口(PyObject_New/Del), 涉及对象参数/引用计数等

layer 1: Python's raw memory allocator (PyMem_ API)
         Python 实现并维护, 包装了第0层的内存管理接口, 提供统一的raw memory管理接口
         封装的原因: 不同操作系统 C 行为不一定一致, 保证可移植性, 相同语义相同行为

layer 0: Underlying general-purpose allocator (ex: C library malloc)
         操作系统提供的内存管理接口, 由操作系统实现并管理, Python不能干涉这一层的行为

第三层layer 3前面已经介绍过了, 几乎每种常用的数据类型都伴有一套缓冲池机制.

在这里, 我们关注的是layer 2/1

简要介绍下layer 1, 然后重点关注layer 2, 这才是重点

layer 1: PyMem_ API

PyMem_ API是对操作系统内存管理接口进行的封装

查看pymem.h可以看到

// Raw memory interface
// 这里存在三个宏定义, 宏可以避免一次函数调用的开销, 提高运行效率
// 不允许非配空间大小为0的内存空间
#define PyMem_MALLOC(n)     ((size_t)(n) > (size_t)PY_SSIZE_T_MAX ? NULL \
                : malloc((n) ? (n) : 1))


#define PyMem_REALLOC(p, n) ((size_t)(n) > (size_t)PY_SSIZE_T_MAX  ? NULL \
                : realloc((p), (n) ? (n) : 1))
#define PyMem_FREE      free

// 这里做了三个函数的声明, 平台独立的 malloc/realloc/free
PyAPI_FUNC(void *) PyMem_Malloc(size_t);
PyAPI_FUNC(void *) PyMem_Realloc(void *, size_t);
PyAPI_FUNC(void) PyMem_Free(void *);

// ============================================================

// Type-oriented memory interface
// 这里还有三个类型相关的内存接口, 批量分配/重分配 n 个 类型为 type内存
#define PyMem_New(type, n) \
  ( ((size_t)(n) > PY_SSIZE_T_MAX / sizeof(type)) ? NULL :  \
    ( (type *) PyMem_Malloc((n) * sizeof(type)) ) )
#define PyMem_NEW(type, n) \
  ( ((size_t)(n) > PY_SSIZE_T_MAX / sizeof(type)) ? NULL :  \
    ( (type *) PyMem_MALLOC((n) * sizeof(type)) ) )

#define PyMem_Resize(p, type, n) \
  ( (p) = ((size_t)(n) > PY_SSIZE_T_MAX / sizeof(type)) ? NULL :    \
    (type *) PyMem_Realloc((p), (n) * sizeof(type)) )
#define PyMem_RESIZE(p, type, n) \
  ( (p) = ((size_t)(n) > PY_SSIZE_T_MAX / sizeof(type)) ? NULL :    \
    (type *) PyMem_REALLOC((p), (n) * sizeof(type)) )

然后object.c中, 我们关注实现, 三个实现的函数调用了对应的宏

// 使用 C 写Python扩展模块时使用函数而不是对应的宏
void *
PyMem_Malloc(size_t nbytes)
{
    return PyMem_MALLOC(nbytes);
}

void *
PyMem_Realloc(void *p, size_t nbytes)
{
    return PyMem_REALLOC(p, nbytes);
}

void
PyMem_Free(void *p)
{
    PyMem_FREE(p);
}

这些接口都相对简单

好了, 结束, 开始关注layer 2: Python's object allocator

Python 的内存分配策略

先来看Objects/obmalloc.c中的一段注释

/*
 * "Memory management is where the rubber meets the road -- if we do the wrong
 * thing at any level, the results will not be good. And if we don't make the
 * levels work well together, we are in serious trouble." (1)
 *
 * (1) Paul R. Wilson, Mark S. Johnstone, Michael Neely, and David Boles,
 *    "Dynamic Storage Allocation: A Survey and Critical Review",
 *    in Proc. 1995 Int'l. Workshop on Memory Management, September 1995.
 */

Python引入了内存池机制, 用于管理对小块内存的申请和释放

逻辑

1. 如果要分配的内存空间大于 SMALL_REQUEST_THRESHOLD bytes(512 bytes), 将直接使用layer 1的内存分配接口进行分配
2. 否则, 使用不同的block来满足分配需求

整个小块内存池可以视为一个层次结构

1. 内存池(概念上的, 标识Python对于整个小块内存分配和释放的内存管理机制)
2. arena
3. pool
4. block

block

Python内存的最小单位, 所有block长度都是8字节对齐的

注意这里block只是一个概念, 在源代码中并没有实体存在.

不同类型block, 对应不同内存大小, 这个内存大小的值被称为size class.

不同长度的block

 * Request in bytes     Size of allocated block      Size class idx
 * ----------------------------------------------------------------
 *        1-8                     8                       0
 *        9-16                   16                       1
 *       17-24                   24                       2
 *       25-32                   32                       3
 *       33-40                   40                       4
 *       41-48                   48                       5
 *       49-56                   56                       6
 *       57-64                   64                       7
 *       65-72                   72                       8
 *        ...                   ...                     ...
 *      497-504                 504                      62
 *      505-512                 512                      63
 *
 *      0, SMALL_REQUEST_THRESHOLD + 1 and up: routed to the underlying
 *      allocator.
 */

例如

申请一块大小28字节的内存, 实际从内存中划到32字节的一个block (从size class index为3的pool里面划出)

图示:

注意: 这里有个Size class idx, 这个主要为了后面pool中用到

size class和size class index之间的转换

#define ALIGNMENT               8               /* must be 2^N */
#define ALIGNMENT_SHIFT         3
#define ALIGNMENT_MASK          (ALIGNMENT - 1)

// size class index => size class
#define INDEX2SIZE(I) (((uint)(I) + 1) << ALIGNMENT_SHIFT)

/* 即
    (0+1) * 8 = 8
    (1+1) * 8 = 16
*/

// size class => size class index
size = (uint)(nbytes - 1) >> ALIGNMENT_SHIFT;

/* 即
    (8 - 1) / 8 = 0
    (16 - 8) / 8 = 1
*/

pool

pool管理block, 一个pool管理着一堆有固定大小的内存块

本质: pool管理着一大块内存, 它有一定的策略, 将这块大的内存划分为多个大小一致的小块内存.

pool size

在Python中, 一个pool的大小通常为一个系统内存页. 4kB

obmalloc.c

#define SYSTEM_PAGE_SIZE        (4 * 1024)
#define SYSTEM_PAGE_SIZE_MASK   (SYSTEM_PAGE_SIZE - 1)

#define POOL_SIZE               SYSTEM_PAGE_SIZE        /* must be 2^N */
#define POOL_SIZE_MASK          SYSTEM_PAGE_SIZE_MASK

pool组成

pool的4kB内存 = pool_header + block集合(N多大小一样的block)

pool_header

/* Pool for small blocks. */
struct pool_header {
    union { block *_padding;
            uint count; } ref;          /* number of allocated blocks    */
    block *freeblock;                   /* pool's free list head         */
    struct pool_header *nextpool;       /* next pool of this size class  */
    struct pool_header *prevpool;       /* previous pool       ""        */
    uint arenaindex;                    /* index into arenas of base adr */
    uint szidx;                         /* block size class index        */ - size class index
    uint nextoffset;                    /* bytes to virgin block         */
    uint maxnextoffset;                 /* largest valid nextoffset      */
};

pool_header的作用

1. 与其他pool链接, 组成双向链表
2. 维护pool中可用的block, 单链表
3. 保存 szidx , 这个和该pool中block的大小有关系, (block size=8, szidx=0), (block size=16, szidx=1)...用于内存分配时匹配到拥有对应大小block的pool
4. arenaindex, 后面说

结构图:

pool初始化

从内存中初始化一个全新的空的pool

Objects/obmalloc.c的

void *
PyObject_Malloc(size_t nbytes)
{
  ...

          init_pool:
            // 1. 连接到 used_pools 双向链表, 作为表头
            // 注意, 这里 usedpools[0] 保存着 block size = 8 的所有used_pools的表头
            /* Frontlink to used pools. */
            next = usedpools[size + size]; /* == prev */
            pool->nextpool = next;
            pool->prevpool = next;
            next->nextpool = pool;
            next->prevpool = pool;
            pool->ref.count = 1;

            // 如果已经初始化过了...这里看初始化, 跳过
            if (pool->szidx == size) {
                /* Luckily, this pool last contained blocks
                 * of the same size class, so its header
                 * and free list are already initialized.
                 */
                bp = pool->freeblock;
                pool->freeblock = *(block **)bp;
                UNLOCK();
                return (void *)bp;
            }


            /*
             * Initialize the pool header, set up the free list to
             * contain just the second block, and return the first
             * block.
             */
            // 开始初始化pool_header
            // 这里 size = (uint)(nbytes - 1) >> ALIGNMENT_SHIFT;  其实是Size class idx, 即szidx
            pool->szidx = size;

            // 计算获得每个block的size
            size = INDEX2SIZE(size);

            // 注意 #define POOL_OVERHEAD           ROUNDUP(sizeof(struct pool_header))
            // bp => 初始化为pool + pool_header size,  跳过pool_header的内存
            bp = (block *)pool + POOL_OVERHEAD;

            // 计算偏移量, 这里的偏移量是绝对值
            // #define POOL_SIZE               SYSTEM_PAGE_SIZE        /* must be 2^N */
            // POOL_SIZE = 4kb, POOL_OVERHEAD = pool_header size
            // 下一个偏移位置: pool_header size + 2 * size
            pool->nextoffset = POOL_OVERHEAD + (size << 1);
            // 4kb - size
            pool->maxnextoffset = POOL_SIZE - size;

            // freeblock指向 bp + size = pool_header size + size
            pool->freeblock = bp + size;

            // 赋值NULL
            *(block **)(pool->freeblock) = NULL;
            UNLOCK();
            return (void *)bp;
        }

初始化后的图

pool进行block分配 - 0 总体代码

总体分配的代码如下

     if (pool != pool->nextpool) {   //
            /*
             * There is a used pool for this size class.
             * Pick up the head block of its free list.
             */
            ++pool->ref.count;
            bp = pool->freeblock; // 指针指向空闲block起始位置
            assert(bp != NULL);

            // 代码-1
            // 调整 pool->freeblock (假设A节点)指向链表下一个, 即bp首字节指向的下一个节点(假设B节点) , 如果此时!= NULL
            // 表示 A节点可用, 直接返回
            if ((pool->freeblock = *(block **)bp) != NULL) {
                UNLOCK();
                return (void *)bp;
            }

            // 代码-2
            /*
             * Reached the end of the free list, try to extend it.
             */
            // 有足够的空间, 分配一个, pool->freeblock 指向后移
            if (pool->nextoffset <= pool->maxnextoffset) {
                /* There is room for another block. */
                // 变更位置信息
                pool->freeblock = (block*)pool +
                                  pool->nextoffset;
                pool->nextoffset += INDEX2SIZE(size);


                *(block **)(pool->freeblock) = NULL; // 注意, 指向NULL
                UNLOCK();

                // 返回bp
                return (void *)bp;
            }

            // 代码-3
            /* Pool is full, unlink from used pools. */  // 满了, 需要从下一个pool获取
            next = pool->nextpool;
            pool = pool->prevpool;
            next->prevpool = pool;
            pool->nextpool = next;
            UNLOCK();
            return (void *)bp;
        }

pool进行block分配 - 1 刚开始

内存块尚未分配完, 且此时不存在回收的block, 全新进来的时候, 分配第一块block

(pool->freeblock = *(block **)bp) == NULL

所以进入的逻辑是代码-2

            bp = pool->freeblock; // 指针指向空闲block起始位置

            .....


            // 代码-2
            /*
             * Reached the end of the free list, try to extend it.
             */
            // 有足够的空间, 分配一个, pool->freeblock 指向后移
            if (pool->nextoffset <= pool->maxnextoffset) {
                /* There is room for another block. */
                // 变更位置信息
                pool->freeblock = (block*)pool +
                                  pool->nextoffset;
                pool->nextoffset += INDEX2SIZE(size);


                *(block **)(pool->freeblock) = NULL; // 注意, 指向NULL
                UNLOCK();

                // 返回bp
                return (void *)bp;
            }

结果图示

pool进行block分配 - 2 回收了某几个block

回收涉及的代码

void
PyObject_Free(void *p)
{
    poolp pool;
    block *lastfree;
    poolp next, prev;
    uint size;

    pool = POOL_ADDR(p);
    if (Py_ADDRESS_IN_RANGE(p, pool)) {
        /* We allocated this address. */
        LOCK();
        /* Link p to the start of the pool's freeblock list.  Since
         * the pool had at least the p block outstanding, the pool
         * wasn't empty (so it's already in a usedpools[] list, or
         * was full and is in no list -- it's not in the freeblocks
         * list in any case).
         */
        assert(pool->ref.count > 0);            /* else it was empty */
        // p被释放, p的第一个字节值被设置为当前freeblock的值
        *(block **)p = lastfree = pool->freeblock;
        // freeblock被更新为指向p的首地址
        pool->freeblock = (block *)p;

        // 相当于往list中头插入了一个节点

     ...
    }
}

没释放一个block, 该block就会变成 pool->freeblock 的头节点, 而单链表一个节点如何指向下一个节点呢? 通过赋值, 节点内存空间保存着下个节点的地址, 最后一个节点指向NULL(知道上面代码-1的判断条件了吧>_<#)

假设已经连续分配了5块, 第1块和第4块被释放

此时内存图示

此时再一个block分配调用进来, 执行分配, 进入的逻辑是代码-1

            bp = pool->freeblock; // 指针指向空闲block起始位置
            // 代码-1
            // 调整 pool->freeblock (假设A节点)指向链表下一个, 即bp首字节指向的下一个节点(假设B节点) , 如果此时!= NULL
            // 表示 A节点可用, 直接返回
            if ((pool->freeblock = *(block **)bp) != NULL) {
                UNLOCK();
                return (void *)bp;
            }

pool进行block分配 - 3 pool用完了

pool中内存空间都用完了, 进入代码-3

            bp = pool->freeblock; // 指针指向空闲block起始位置


            // 代码-3
            /* Pool is full, unlink from used pools. */  // 满了, 需要从下一个pool获取
            next = pool->nextpool;
            pool = pool->prevpool;
            next->prevpool = pool;
            pool->nextpool = next;
            UNLOCK();
            return (void *)bp;

获取下一个pool(链表上每个pool的block size都是一致的)

好了, pool到此位置, 下篇进入arena

Python-基础-数据结构小结

Fri, 28 Aug 2015 23:59:59 +0800

只是一篇笔记, 梳理了下

====================

序列

string

基本数据结构, 不解释

可以看下我之前的笔记

list

基本数据结构, 不解释

可以看下我之前的笔记

tuple

基本数据结构, 不解释

可以看下我之前的笔记

namedtuple

在collections中, 从名字可以看出是命名的tuple

collections.namedtuple(typename, field_names[, verbose=False][, rename=False])

好处, 文档中提到

Named tuple instances do not have per-instance dictionaries, so they are lightweight and require no more memory than regular tuples.

和一般class+自定义__slots__的功能类似, 不会给每个实例定义__dict__, 可以节省内存

所以, 优点

1. 可读性更好, 可以当做轻量的类来使用(only attributes)
2. 节省内存

文档的例子

>>> from collections import namedtuple
>>> Point = namedtuple('Point', ['x', 'y'], verbose=True)
class Point(tuple):
    'Point(x, y)'

    __slots__ = ()

    _fields = ('x', 'y')

    def __new__(_cls, x, y):
        'Create new instance of Point(x, y)'
        return _tuple.__new__(_cls, (x, y))

    @classmethod
    def _make(cls, iterable, new=tuple.__new__, len=len):
        'Make a new Point object from a sequence or iterable'
        result = new(cls, iterable)
        if len(result) != 2:
            raise TypeError('Expected 2 arguments, got %d' % len(result))
        return result

    def __repr__(self):
        'Return a nicely formatted representation string'
        return 'Point(x=%r, y=%r)' % self

    def _asdict(self):
        'Return a new OrderedDict which maps field names to their values'
        return OrderedDict(zip(self._fields, self))

    def _replace(_self, **kwds):
        'Return a new Point object replacing specified fields with new values'
        result = _self._make(map(kwds.pop, ('x', 'y'), _self))
        if kwds:
            raise ValueError('Got unexpected field names: %r' % kwds.keys())
        return result

    def __getnewargs__(self):
        'Return self as a plain tuple.  Used by copy and pickle.'
        return tuple(self)

    __dict__ = _property(_asdict)

    def __getstate__(self):
        'Exclude the OrderedDict from pickling'
        pass

    x = _property(_itemgetter(0), doc='Alias for field number 0')

    y = _property(_itemgetter(1), doc='Alias for field number 1')


>>> p = Point(x=11, y=22)
>>> p.x, p.y
(11, 22)
>>> p[0], p[1]
(11, 22)
>>> p
Point(x=11, y=22)

array

python 2 library: array

数组, 和列表的区别是, 一个数组只能存储一种类型的数据(即数组中所有元素类型一致), 类型是有限的集合

相对的, 优点是: 节省内存

class array.array(typecode[, initializer])

# 其中, typecode
Type code   C Type                            Python Type Minimum size in bytes
'c'         char                              character   1
'b'         signed char                       int         1
'B'         unsigned char                     int         1
'u'         Py_UNICODE          Unicode character         2(see note)
'h'         signed short                      int         2
'H'         unsigned short                    int         2
'i'         signed int                        int         2
'I'         unsigned int                      long        2
'l'         signed long                       int         4
'L'         unsigned long                     long        4
'f'         float                             float       4
'd'         double                            float       8

使用实例

>>> import array
>>> l = array.array('i', [1,2,3,4,5])
>>> l
array('i', [1, 2, 3, 4, 5])
>>> len(l)
5
>>> l[0]
1
>>> l.index(3)
2
>>> l.insert(0, 0)
>>> l
array('i', [0, 1, 2, 3, 4, 5])

linked list

似乎要在Python中用这个的场景非常之少…..

也似乎有两种选择

自己写一个
用其他数据结构替代

具体可以看看这个 Python Linked List

set

base set

基本数据结构, 不解释

可以看下我之前的笔记

Python-基础-集合小结

frozenset

标准库带, 简而言之: frozenset是set的不可变版本, 类似tuple和list的关系

文档

frozenset可以作为字典键

>>> s = set([1,2,2,3])
>>> s.add(4)
>>> s.add(4)
>>> s
set([1, 2, 3, 4])
>>> hash(s)
Traceback (most recent call last):
  File "", line 1, in <module>
TypeError: unhashable type: 'set'
>>>
>>> s2 = frozenset([1, 2, 2, 3])
>>> s2
frozenset([1, 2, 3])
>>> s2.add(4)
Traceback (most recent call last):
  File "", line 1, in <module>
AttributeError: 'frozenset' object has no attribute 'add'
>>>
>>> hash(s2)
-7699079583225461316

dict

base dict

基本数据结构, 不解释

可以看下我之前的笔记

ordered dict

dict的子类, 会记住放入字典键值对的顺序, 文档

>>> from collections import OrderedDict
>>> d = OrderedDict()
>>>
>>> d[3] = 'c'
>>> d[1] = 'b'
>>> d[2] = 'a'
>>> d
OrderedDict([(3, 'c'), (1, 'b'), (2, 'a')])
>>> d.items()
[(3, 'c'), (1, 'b'), (2, 'a')]
>>> d.items()
[(3, 'c'), (1, 'b'), (2, 'a')]
>>>
>>>
>>> d2 = dict()
>>> d2[3] = 'c'
>>> d2[1] = 'b'
>>> d2[2] = 'a'
>>> d2
{1: 'b', 2: 'a', 3: 'c'}
>>> d2.items()
[(1, 'b'), (2, 'a'), (3, 'c')]

default dict

defaultdict, 同样是dict的子类, 会自动设置value的默认值, 文档

>>> from collections import defaultdict
>>> d = defaultdict(list)
>>> d
defaultdict(<type 'list'>, {})
>>> d['a'].append(1)
>>> d
defaultdict(<type 'list'>, {'a': [1]})
>>> d['a']
[1]
>>> d['a'].append(2)
>>> d['a']
[1, 2]
>>> d['notexists']
[]

others - MultiDict

一键多值的dict

bottle里面的MultiDict

werkzeug里面的版本

>>> d = MultiDict([('a', 'b'), ('a', 'c')])
>>> d
MultiDict([('a', 'b'), ('a', 'c')])
>>> d['a']
'b'
>>> d.getlist('a')
['b', 'c']
>>> 'a' in d
True

others - CaseInsensitiveDict

key大小写不明感的dict

CaseInsensitiveDict

cid = CaseInsensitiveDict()
cid['Accept'] = 'application/json'
cid['aCCEPT'] == 'application/json'  # True

others - CallbackDict

更新时会调用回调函数

CallbackDict

stack

Python标准库没有stack实现, 如果要处理, 可以自己写一个, 或者使用现有数据结构替代

use list as stack

class Stack:
    def __init__(self):
        self.items = []

    def isEmpty(self):
        return len(self.items) == 0

    def push(self, item):
        self.items.append(item)

    def pop(self):
        return self.items.pop()

    def peek(self):
        return self.items[len(self.items) - 1]

    def size(self):
        return len(self.items)

queue

base queue

use list as queue

class Queue:
    def __init__(self):
        self.items = []

    def isEmpty(self):
        return len(self.items) == 0

    def enqueue(self, item):
        self.items.insert(0, item)

    def dequeue(self):
        return self.items.pop()

    def size(self):
        return len(self.items)

其他, python标准库中的Queue模块, 文档

包含

Queue    FIFO
LifoQueue  LIFO
PriorityQueue  带优先级的

多用于多线程资源共享中(一般情况下很少用), 因为是线程安全的

deque

双端队列, 线程安全, 且左右两端出入队复杂度O(1), 文档

>>> from collections import deque
>>> d = deque([1, 2, 3])
>>> d
deque([1, 2, 3])
>>> d.append(4)
>>> d.appendleft(0)
>>> d
deque([0, 1, 2, 3, 4])
>>>
>>> d.pop()
4
>>> d
deque([0, 1, 2, 3])
>>> d.popleft()
0
>>> d
deque([1, 2, 3])

堆

最小堆实现

文档

>>> import heapq
>>>
>>> h = []
>>> heapq.heappush(h, (5, 'e'))
>>> heapq.heappush(h, (1, 'a'))
>>> heapq.heappush(h, (2, 'b'))
>>> heapq.heappush(h, (4, 'd'))
>>> heapq.heappush(h, (3, 'c'))
>>>
>>> h
[(1, 'a'), (3, 'c'), (2, 'b'), (5, 'e'), (4, 'd')]
>>> heapq.heappop(h)
(1, 'a')
>>> h
[(2, 'b'), (3, 'c'), (4, 'd'), (5, 'e')]
>>> heapq.heappop(h)
(2, 'b')
>>> h
[(3, 'c'), (5, 'e'), (4, 'd')]

树

标准库没有tree的实现

可以看看这本书的讲解 Introductory Programming in Python Advanced Data Structures: Trees

base tree

自己写一个>_<

import collections

def Tree():
    return collections.defaultdict(Tree)

binary tree

二叉树, 关注下这个包 bintree

包括二叉树/红黑树/AVL树

图

这个暂时没有好的推荐, 一般处理成二维数组, 或者使用类机制实现节点/边

其他

计数counter

Counter文档

dict子类, 会记录某个key出现的次数, 在做计数/统计的时候非常有用

>>> from collections import Counter
>>> c = Counter('abracadabra')
>>> c
Counter({'a': 5, 'r': 2, 'b': 2, 'c': 1, 'd': 1})
>>> c.most_common(3)
[('a', 5), ('r', 2), ('b', 2)]

bisect

bisect, 维持一个有序列表, 可以用于快速检索

>>> import bisect
>>> bisect.insort_left(l, 1)
>>> bisect.insort_left(l, 5)
>>> bisect.insort_left(l, 2)
>>> bisect.insort_left(l, 7)
>>> l
[1, 2, 5, 7]

>>> bisect.bisect_left(l, 2)  # 返回位置或插入后的位置
1
>>> bisect.bisect_left(l, 20)
4

struct

处理和存储二进制数据的时候用到, 文档

>>> from struct import *
>>> pack('hhl', 1, 2, 3)
'\x00\x01\x00\x02\x00\x00\x00\x03'
>>> unpack('hhl', '\x00\x01\x00\x02\x00\x00\x00\x03')
(1, 2, 3)

'活动'设计的一些trick

Fri, 28 Aug 2015 08:00:00 +0800

在梳理过去做过的项目

之前做项目的时候, 十个月期间做了不少活动, 类型比较多, 有推广/抽奖/小游戏等等.

有些活动需求明确一气呵成, 也有些活动需求模糊一度推倒重来, 还有的活动被刷了><#

好吧, 来说说活动

一些想法, 可以是技术, 非技术

目的

活动的目的是什么? 有没有存在的意义?

存在由于没有想清楚, 耗费人力物力搞了结果不尽人意……所以目的应该先想清楚, 并且明学下来

活动开发简要流程

需求分析: 整体流程, 用户侧细节, 管理侧需求, 统计需求等等, 对整个流程达成一致, 对每个环节的条件/处理逻辑/后续出口等等明确下来, 对一些资质/数字限制等确定下来
设计出图/后端建模-逻辑代码-API/前端开发
测试环境上线
内部测试, 试玩, 针对活动本身给意见. 测试人员测试, 针对逻辑本身, 同时进行网速测试(2g/3g/wifi) / 浏览器测试 / 不同手机-系统测试
修正迭代, 测试
正式上线
管理侧/统计侧上线
推广/监控
活动结束
奖品派发/数据统计等
活动下线

quick and maybe dirty

由于活动本身的性质, 这类代码逻辑属于短平快一类的.

简而言之: 怎么快怎么来

可以不要考虑复用
当然, 有些代码是复用的, 例如CRUD/get some list/check permission/call base service等等
不要考虑将来/以后, 很多活动上了就下了, 不会有所谓的将来, 切忌过渡设计, 空耗费许多精力没有必要
要快

注意代码/数据/部署隔离

前面说过, 很多活动逻辑没有将来

所以, 活动的代码尽量独立, 保证随写随测, 随上随下, 尽量隔离于主体代码之外, 这样上下线也方便

当然, 不可能完全独立, 依赖外部尽量使用独立的服务接口, 被外部依赖提供也尽量通过提供接口解决(情况很少)

数据独立, 包括, 数据库实例/redis or memcached/文件等, 活动需要记录一些数据, 和主体业务独立开来, 尽量不共用, 有条件的话单独提供实例

部署隔离, 尽量不要和关键服务在同一台机器或者共用带宽, 由于活动本身的特质, 可能带来突发的流量, 可能导致带宽/IO/缓存占用/机器负载等变高, 会影响到其他服务.(可以给定独立url, 通过反代定到活动服务)

开发注意

做好缓存
每个接口做好资质/权限控制, 这类逻辑放在api代码的前面(判断条件放到最前面), fail fast, 验证通过后才进入主体逻辑代码
友好的异常处理/用户提示
后端需要考虑防刷, 前端需要处理下重复提交
做好事务控制(并发), 特别是涉及数字增减的情况, 例如奖品数
涉及步骤的活动, 做好流程限制, 第一步-第二步-第三步……, 防止用户跳过某一步直接进入下一步.(可以通过签加密token的方式)
图片, 尽量放到 CDN (血的教训, 前端一张背景图导致带宽被跑满, 后续用户进不来)
需要有一套成熟的统计系统, 活动数据直接发送到统计系统, 由统计系统统一出数据
对于关键性的步骤/数据, 可以记日志
有必要的话, 做成一期一期的, 有开始结束时间, 自动切换(有些复杂的活动)
有必要的话, (传说中的开关)提供方便的配置或者入口, 可以一键上下线活动/奖品(valid/invalid/shutdown)
对于关键性的代码, 做好注释, 例如一些限制逻辑/数量等等

学会打时间差

很多活动, 可能是热点? 节日? 等等, 时效性比较强的.

然而, 当活动逻辑很复杂的时候, 又要在规定时间内上线, 这时候可以仔细切分需求, 分不同时间上线.

例如, 一个玩游戏/抽奖/兑奖的活动, 可能分为两部分, 用户侧和管理侧, 用户侧逻辑玩游戏/兑奖/查看是否获奖, 管理侧查看获奖情况/颁奖/新增用户统计/渠道统计/流量统计等等

那么, 可以先保证用户侧完成, 同时加入向统计系统发送统计数据的接口, 然后上线, 保证用户侧主体流程. 上线后开始开发管理侧, 管理侧可以按照运营优先级处理, 例如要查看实时统计信息的话, 先做统计, 保证推广效果, 获奖及颁奖可以稍稍押后, 作为第三阶段上线(如果活动兑奖都是在一个周期结束的话)

例如, 要发奖数据, 如果没有管理后台, 直接库里导一份出来就是了. 其实这时候应该思考, 要不要花力气做管理后台, 大不了活动结束手工操作一下, 十分钟.

下线

额, 活动做完, 要下线了.

如果程序是带日期限制的, 到点了自动结束, 提示用户活动结束, 活动流程无法走下去.

如果需要人肉, 直接将外网入口去掉即可.

然后, 可以考虑后续了

首先, 要确认, 该记录的统计数据记录了, 该分析的分析了, 该发奖的也发奖了……

首先, 备份代码到活动代码仓库(供后续参考/复用, 防止雷同逻辑/代码要重写), 然后从代码库删除.

线上, 备份数据到备份服务器, 包括数据库数据/日志/文件等等, 如果缓存中有需要dump的, dump出来. 然后下线数据库, 清空缓存, 日志等

活动, 很大程度上是一堆临时而无用并且没有技术含量, 而且非常短命的代码组成的, 做多了容易烦躁, 最好一个项目组里轮流处理, 当然有人认领更好.

活动成不成功, 决定因素很多, 但无论如何, 下线前做好review, 防止重复犯错

就这些

wklken

2015-08-28

一些简单的Python测试题

Wed, 26 Aug 2015 08:00:00 +0800

一些简单的测试题, 主要来源是网上:)

某种程度, 可以从代码中看出一些东西

编写代码, 打印1-1亿之内的偶数
写一个函数, 用正则表达式清除字符串中[]和其中的内容。

s = "[lol]你好，帮我把这些markup清掉，[smile]。谢谢！"

请使用python, 对下面的函数进行处理,

def hello(name):
    print "hello, %s" % name

在函数被调用时打印耗时详情

<function name: hello>
<function call begin>
hello, tom
<function call end>
[timecosts: 3.81469726562e-06s]

写一个函数, 将驼峰命名法字符串转成下划线命名字符串(需考虑各类编码中常见的命名)

e.g.  GetItem -> get_item
      getItem -> get_item
      doIT    -> do_IT

有一个列表：[1, 2, 3, 4…n]，n=20；请编写代码打印如下规律的输出：

1 [1*, 2, 3, 4, 5]
2 [1, 2*, 3, 4, 5]
3 [1, 2, 3*, 4, 5]
4 [2, 3, 4*, 5, 6]
5 [3, 4, 5*, 6, 7]
6 [4, 5, 6*, 7, 8]
...

20 [16, 17, 18, 19, 20*]

写一个程序模拟银行排队, 只有一个队伍, 一个用户进入时允许插队(进入队伍任意位置), 但要保证每次导致队伍变更, 队伍中受影响的人都收到通知

Customer A line up at position 11

Customer B: order changed to 12
Customer C: order changed to 13
Customer D: order changed to 14

用户系统, 存在相互关注的动作, 当进入某个人的个人主页, 需要展示其粉丝数, 关注数, 粉丝列表以及关注列表. 请简要描述解决方案, 包括db建模/数据层/业务层, 以及应对高并发/关注取关等情况的处理逻辑
给定一些NxN的矩阵，对于任意的路线，定义其【和】为其线路上所有节点的数字的和，计算从左上角到右下角的路线和最小值。每条路线只能从某一点到其周围（上下左右）的点，不可斜行。例如，

4,6
2,8 的路线和最小值为 4-2-8 14

1,2,3
4,5,6
7,8,9 的路线和最小值为 1-2-3-6-9 21

程序只需输出最小和值即可（一个数字）

我的tmux配置及说明【k-tmux】

Thu, 06 Aug 2015 08:00:00 +0800

配置了一份 k-tmux

以下快捷键是对这份配置的说明, 大部分为tmux通用, 部分为修改自定义

安装

mac
$ brew install tmux
$ brew install reattach-to-user-namespace

ubuntu
$ sudo apt-get install tmux

简要说明

tmux -> session -> window -> pane

Tmux可以管理多组会话
一个会话（Session）可以包含多个窗口，一个窗口（Window）可以包含多个窗格（Pane）

操作前缀 PREFIX = Ctrl-a

1. session

# 创建, tmux new -s  创建一个新的会话
$ tmux new -s basic

# 在tmux中创建一个会话
[PREFIX-:] new -s 

# 分离会话 detach
[PREFIX-d]
[detached (from session basic)]
or
$ tmux detach
or
[PREFIX-Ctrl-z]

# 查看已有会话列表(list-session)
$ tmux ls
basic: 1 windows (created Wed Aug  5 14:54:04 2015) [200x49]

# 在tmux中查看会话列表并切换
[PREFIX-s]

# 连接会话(只有一个)
$ tmux attach
$ tmux attach -t basic
$ tmux a -t basic

# 杀掉会话
$ tmux kill-session -t

# 重命名会话
[PREFIX-$]

2. window

# 创建一个新的窗口
[PREFIX-c]

# 重命名一个窗口
[PREFIX-,] 之后输入名字回车

# 切换到下一个窗口, k-tmux另外配置了PREFIX-t/T
[PREFIX-n]

# 切换到对应窗口
[PREFIX-1/2/3]

# 可视化选择切换到的窗口
[PREFIX-w]

# 查找窗口
[PREFIX-f]

# 退出窗口
exit or
[PREFIX-&] 会有确认

3. pane

分割原先未修改键位的分割方式是[PREFIX-%]和[PREFIX-"] 重新映射为

# 垂直/水平分割窗口
[PREFIX-\] / [PREFIX--]

关闭pane

# 关闭一个面板, 要确认
[PREFIX-x]

或者
exit [面板里执行]

切换

[PREFIX-hjkl] pane之间移动

[Ctrl-hjkl]   pane之间移动
[Ctrl-\]      最近使用两个窗口之间切换
[PREFIX-q]    展示窗口数字并选择跳转
[PREFIX-o]    循环切换

大小调整

[Ctrl-HJKL] pane大小调整
[PREFIX-z]  trigger暂时把窗口变大

关闭及移动

[PREFIX-x] 关闭当前pane, 需确认
[PREFIX-}] 当前pane移到左边
[PREFIX-{] 当前pane移到右边

其他

[PREFIX-!]     当前pane在新的window中打开
[PREFIX-space] 会自动切换依次使用这些布局(几种窗口布局轮流切换)

4. 复制粘贴

[PREFIX-[] 进入复制模式

=> 可以进行的操作
space/v    开始选择
Ctrl-v     整块选择
hjkl       方向键移动
w/b        向前向后移动一个单词
fx/Fx      行内移动到下一个字符位置
ctrl-b/f   在缓冲区里面翻页
g/G        到缓冲区最顶/底端
/ ?        向下, 向上查找
n/N        查找后下一个, 上一个
Enter/y    复制
[PREFIX-]] 粘贴

其他增强:

# 复制整个pane可见区域
[PREFIX-:] capture-pane

# 查看缓冲区内容
[PREFIX-:] show-buffer

# 列出缓冲区列表
[PREFIX-:] list-buffers

# 从缓冲区列表选择并插入到当期面板
[PREFIX-:] choose-buffer => 回车

5. 其他

获得快捷键列表

[PREFIX-?]

进入命令模式

[PREFIX-:]

一些命令模式下的命令
# 新建窗口
new-window -n console

# 新建并执行命令
new-window -n processes "top"

6. 增强

1. Tmuxinator

Tmuxinator 是一个 Ruby 的 gem 包，可用于创建 Tmux 的会话。它的工作方式是先在配置文件中定义会话中的细节，然后用 1 条命令创建出这些会话

gem install tmuxinator
tmuxinator new project_a => ~/.tmuxinator/project_a.yml => 配置

启动: tmuxinator start project_a
可以别名: mux start project_a

2. vim插件

christoomey/vim-tmux-navigator, 安装更便捷的导航跳转

7. 资源及参考

Review and Restart

Fri, 24 Jul 2015 08:00:00 +0800

7月4日, 想着正式工作四年了 7月9日, 公司这边出了点状况, 歇业, 也从公司离职了 7月10日, 衡山溜达了一圈 7月19日, 想着正好加入甜品十一个月了 7月18日, 生日

去年的七月, 也刚好离职, 正在一路北上的旅途中. 情况似曾相识.

Review

一些工作上的review

1. 凡事有结果 and Fail-fast(快速失败)

作为工程师, 似乎很容易陷入, 将做项目, 变成完成任务.

前置是需求, 有产品帮cover, 但是项目的后置, 是结果, 更多的是依赖自己.

需求分析后, 系统设计之初, 就应该考虑: 日志/统计, 考虑如何去衡量"结果".

项目上线后, 要跟!!! 分析及反馈数据, 让更多人了解现状, 以便后续决策.

做事如果没有结果, 会导致可能错误的不断投入精力处理一些不重要的事情, 甚至根本不需要做, 沉没成本

事情做了, 要有一个结果, 好/不好/不好不坏, 无论如何, 自己都要有所感知. 关乎成就感.

如果不好, 就快速失败, 砍掉或者修正, 总之, 不要往错误的方向越走越远.

当然, 这涉及和上下游多沟通交流.

所以, 建议无论产品或者研发, 做完一个项目, 都要有相应的review, 总结并通报相关人员.

2. 人

人员构成很重要, 要互补, 必要的时候能"千斤顶"

做事多向前走一步, 不要老是停留在自己的"舒适区"/“自留地”, 多走一步, 更高效协作

找准节奏, 快速度过磨合期

不要因为一时繁忙, 因为忙不过来而找人, 痛上一痛再做决定

不要给人找事做!!!!!(一时事太多=> 招人 => 没事干 => 找事干……)

各司其职, 信任伙伴, 不要大跨界或者插手太多, 无谓耗费自己的精力, 你的精力可以在自己擅长的地方发挥更大的作用

3. Scrum & 看板 & 项目制

没有万能药, 可以实施, 试试, 阵痛, 改进, 最终摸索到适合团队的

一个Sprint只集中精力处理有限的目标. 不要分散了精力.

Sprint, 是用来实现需求的, 而不是用来砍需求的!!!

看板, 从整体一个大看板, 到最终根据业务线逐步拆分, 整个过程用起来感觉很有效.

项目制, 可以先找小的项目试验, 核心成员参与, 先run起来, 成功了再扩大范围. 很多东西不能操之过急.

4. 工具

用好用的工具, 用好工具

mac/邮件/jira/stash/confluence等等, 整个团队达成一致, 高效协作

使用工具的整个过程中, 也势必遇到的各种问题, 例如团队规模的扩大, 业务线增多, 跟上游产品的协作, 配合sprint等等, 这都需要在不同阶段进行调整, 对工作流进行优化, 形成一些约定. 以提高协作效率为第一目标

工具能买就买, 找个工程师花几个人日搭开源的, 以及后续维护, 还不一定好用(这都是隐性的成本), 还不如花钱搞定, 况且如今各类工具成本已经非常低廉了:)

5. 快以及一切从简work就行

快速实现, 快速验证.

不要一开始就妄图设计一个完美的系统: 需求会改/项目会砍

一开始不要想得太过复杂, 基本流程ok, 上线, 迭代上线完善的功能, 不要一开始就花大力气想直接搞定, 因为这里面很多成本其实是不必要的, 搞不好你花了一周赶完, 上了发现根本毫无用处.

当人肉顶不住的时候, 再考虑做系统. 理由同上, 费劲搞了系统, 结果要么业务没上来, 没达到"人肉"顶不住的情况, 要么就是业务废弃了/砍掉了. 搞系统耗时耗力不一定有用.

6. 不忘初心

很多时候, 无论是产品, 还是研发, 都会忘了最初出发的目的是什么.

产品被一大堆细节淹没, 而研发将大目标切碎逐步做的过程中, 很那有整体的概念.

可以尝试, 可以变换, 但是要明确, 所有人都明确.

一切, 轻重缓急, 排期, 以目标为导向

目标导向, 但同一个时刻, 不要有太多的目标, 不要一个目标未完就想在此基础上尝试新的目标.(精力分散/事情没做透)

7. 理想主义

不要太过理想主义

这十个月, 经历了很多, 团队由小到大, 项目由1到28, 从0到1, 造了很多轮子, 经历了整个团队协作方式的变更, 经历了磨合的阵痛, 经历了一轮又一轮的sprint, 经历了第一版上线, 到最后第80个安装包, 经历了一次次上线, 一个个活动, 看着后台用户数一点点涨起来, 看着全部api调用一点点涨起来, 然后掉下去>_<#(这似乎是个悲伤的故事……)

但是, 这十个月, 从第一天到甜品, 感受到"家"的气息, 到最终收拾离开, 关小黑屋, 晨会, 愉快地coding, 聚餐等等, 十月风雨, 过得很充实, 也学到很多东西, 感谢所有糖厂的银, 帮助及包容.

Restart

闲了一周了, 趁这段时间, 打算做做总结, 重写一些代码, 读完CPython源码及APUE, 还有, 就是学车及休息

整理整理, 想明白一些东西, 再重新启程.

希望明天会更好吧

既然选择了远方, 便只顾风雨兼程, 共勉

wklken

2015-07-24 于深圳

工作四周年小结

Sat, 04 Jul 2015 08:00:00 +0800

一晃, 四年过去了

每年的7月4日, 都会想到刚毕业入职第一天

惯例, 写一些东西, 记录过去的这些日子

既然选择了远方, 便只顾风雨兼程 – 汪国真

最近遇到了一些事情, 颇为突然, 也颇为无奈.

似乎, 也是去年的这阵子, 遭遇了公司的变故, 最终离职, 到北边溜达了一阵. 回来后, 宅了一阵, 花了两天找了工作, 迄今十月有余.

很多事情很突然, 也就在旦夕之间

原来没有感觉, 但是回顾, 发现却也是必然的

十月风雨, 一切美好, 仿佛一场梦

思考, 总结, 前进

生活, 总是要继续的.

既然选择了远方, 便只顾风雨兼程, 这是我给每个新入职小伙伴的纸条, 祝好, 也送给自己, hold on.

前进, 前进, 不顾一切地前进 – 三体

似乎, 之前一直秉承这个信念在做一些事情

回头却发现, 似乎错放了重点

每个人在每个阶段, 都有不同的需求/追求, 而一直坚持一个信念

愚蠢!

我将重点错放了, 有些事情总要去做的, 有些责任总是要要承担的, 有些变迁, 总是要去经历的. 而, 这个信念, 成为了我逃避的理由. 规避了太多不该规避的东西, 最终还剩下什么?

结果是, 似乎折腾许多, 却也没折腾出什么, 步步前行, 却错失了很多生活中的美好.

anyway, 需要醒醒, 认真生活了.

关于造轮子

近期思考的问题, 关于造轮子与创业.

创业过程, 避免不了去造轮子, 如果顺利, 随着业务发展, 不断完善, 优化, 变革, 最终造一个大轮子:)

而往往, 事情总不尽人意, 如果业务没发展呢? 假设, 到再次创业, 轮子似乎又得造一遍.

这个过程, 或许可以造一个更好的轮子, 但是, 独轮车总归还是独轮车, 载不动.

然后, 如果要造第三遍呢? 呵呵

业务成就了技术, 这也造成了很多无奈:(

充电, 毕竟有限, side project, 更多的是玩具, 哎.

所谓的沉没?

当一切已成往事, 谁还记得, 那些岁月

去年的8月, 玩久了, 宅久了, 大体有个方向, 花了些时间看了下公司, 两天面了四个, 然后选了一个, 入职.

一切很快, 选择的原因呢? 两个因素: 1.做的事情符合价值观, 认同且喜欢 2.人

角色? 后端开发兼运维打杂, 除了业务系统, 底层服务依赖的开发, 还兼职做运维, 负责环境搭建/部署/自动化等等.

一路过来, 造了很多轮子, 很多轮子造的第二遍, 重构过几个项目, 做对过一些事情, 做错过一些事情, 对靠谱二字重新定义.

一路过来, 也对自己有更为多的认识. 性格上的缺陷.

回顾十月, 感谢很多人, 感谢一起奋斗过的小伙伴.

很遗憾, 我是个记性很好的人, 例如同一个话题, 谁第几遍重复说起都记得, 哎. 这也造成了, 对很多事情, 难以释怀, 记性太好或许对 INTJ 来说, 是件坏事.

那些一起战斗的岁月, 或许已成往事, 依然记得.

四年

四年是什么感觉呢?

感觉老了, 一眼过去, 一片都是90后

感觉时间匆匆, 不经意间, 一小时, 一天, 一礼拜, 一月, 一年, 就这么没了, 更多的压力, 紧迫感, 更加珍惜时间.

感觉自己还是弱弱的, 读很多书, 做很多事, 也对自己有更多的认识, 愈发觉得自己的渺小, 能做一些事情, 但是却也有很多无能为力的时候, 唯有努力

感觉生活中充满了各种不确定, 无论如何都得努力面对, 努力锻炼, 学习, 努力变得更好

旦夕, 不确定

上一刻还在愉快地coding, 下一刻回头发现已沧海桑田

生活总是充满变化, 充满了无奈, 这就是生活, 这就是现实.

虽然, 拥抱变化, 但是落差好大

then?

坚持, 努力地去做一些事情吧, 让自己变得更好

创业的一些感受

还在review, 等想明白了再写

选择很重要

然!

但是没有对与错, 选择了就选择了, 仅此而已

迷茫, 是能力和理想不匹配

不久前在知乎上看到的, 深以为然, 也在思考.

wklken

2015-07-04 于深圳

vim插件: surround & repeat[成对符号编辑]

Sat, 13 Jun 2015 12:16:00 +0800

k-vim配置 github

surround

作用: 快速给词加环绕符号,例如单引号/双引号/括号/成对标签等

github: vim-surround

安装

Bundle 'tpope/vim-surround'

使用

注意(括号, 左括号会加空格, 右括号不会)

示例:

# 替换: cs"'
"Hello world!" -> 'Hello world!'

# 替换-标签(t=tag): cst"
abc  -> "abc"

cst
abc  -> abc

# 删除: ds"
"Hello world!" -> Hello world!

# 添加(ys=you surround): ysiw"
Hello -> "Hello"

# 添加: csw"
Hello -> "Hello"

# 添加-整行: yss"
Hello world -> "Hello world"

# ySS"
Hello world ->
"
    hello world
"

# 添加-两个词: veeS"
hello world -> "hello world"

# 添加-当前到行尾: ys$"

# 左符号/右符号 => 带不带空格
cs([
(hello) -> [ hello ]

cs(]
(hello) -> [hello]

演示:

vim-repeat

作用: 重复一个插件的操作, 支持surround.vim, 通过 surround 操作之后的行为, .号重复

github: vim-repeat

安装

" for repeat -> enhance surround.vim, . to repeat command
Bundle 'tpope/vim-repeat'

使用

演示:

最终配置

Bundle 'tpope/vim-surround'
Bundle 'tpope/vim-repeat'

建议

善用.
repeat同时还支持的插件 doc

vim插件: gundo[时光机]

Sat, 13 Jun 2015 10:37:00 +0800

k-vim配置 github

有时候编辑一半, 特别是删除了一些东西, 然后想找回, 但是没有存下来(只在脑子里有) 这时候时光机就发挥作用了

作用: 文件时光机, 可以查看同一个文件之前的历史内容

github: gundo

安装

Bundle 'sjl/gundo.vim'

使用

绑定快捷键h作为toggle, 进入之后

j/k   上下选择
p     查看diff
回车  回滚文件到这个时刻的版本
h  关闭(或者wq关闭gundo打开的窗口)

注意, 你可以跳进预览, 复制一些东西出来, 不必走回滚

最终配置

nnoremap h :GundoToggle

建议

只要写过的, 都能找回来
同类插件 undotree

vim插件: expand-region[区域选中]

Sat, 13 Jun 2015 10:21:00 +0800

k-vim配置 github

作用: 视图模式下可伸缩选中部分，用于快速选中某些块

github: expand-region

安装

Bundle 'terryma/vim-expand-region'

使用

自定义key

v 增加选中范围
V 减少选中范围

演示:

最终配置

Bundle 'terryma/vim-expand-region'
vmap v (expand_region_expand)
vmap V (expand_region_shrink)

建议

培养使用v/V进行区块选中的习惯, 避免每次多敲键位
可以进行选中规则的自定义, 具体见文档

vim插件: quickrun[快速执行]

Sat, 13 Jun 2015 10:09:00 +0800

k-vim配置 github

作用: 快速执行当前文件, 例如*.py/.rb/.sh等等, 用于快速验证一些代码实现

github: vim-quickrun

安装

Bundle 'thinca/vim-quickrun'

使用

配置使用message进行结果展示, 即, 展示运行结果后, 按任意键回到vim编辑

同时, 映射r以及F10快捷键

在快速编写验证性代码时非常有用

演示:

最终配置

Bundle 'thinca/vim-quickrun'
let g:quickrun_config = {
\   "_" : {
\       "outputter" : "message",
\   },
\}

let g:quickrun_no_default_key_mappings = 1
nmap r (quickrun)
map  :QuickRun

建议

无

vim插件: trailing-whitespace[行尾空格处理]

Sun, 07 Jun 2015 18:16:00 +0800

k-vim配置 github

没有什么太多需要讲的, 功能+一个快捷键

代码洁癖/强迫症必备

作用: 高亮行末空格(标红), 也可以一键去除文件中所有行行尾空格

github: vim-trailing-whitespace

安装

Bundle 'bronson/vim-trailing-whitespace'

使用

被动技能: 自动标记行尾的空格

主动技能: 绑定为快捷键, 一键去除所有行尾空格 (k-vim中为,空格)

最终配置

Bundle 'bronson/vim-trailing-whitespace'
map  :FixWhitespace

vim插件: closetag[成对标签补全]

Sun, 07 Jun 2015 18:15:00 +0800

k-vim配置 github

如果日常开发中要编辑xml和html文件, 一个字符一个字符敲是不聪明地, 虽然你可以这么做…

作用: 编辑xml/html时, 自动补全闭合标签

github: closetag

安装

Bundle 'docunext/closetag.vim'

使用

被动技能, 自动补全

最终配置

Bundle 'docunext/closetag.vim'
let g:closetag_html_style=1

建议

被动技能, 越简单越好, 当然如果你要用这个来写前端代码, 是远远不够的, 你可能需要emmet

vim插件: ctrlp[文件搜索]

Sun, 07 Jun 2015 18:14:00 +0800

k-vim配置 github

使用频率最高的插件之一

作用: 模糊搜索, 可以搜索文件/buffer/mru/tag等等

github: 原始kien/ctrlp, 使用的是国人改进版本 ctrlpvim/ctrlp.vim

安装

Bundle 'ctrlpvim/ctrlp.vim'

使用

绑定快捷键

-f模糊搜索最近打开的文件(MRU)

-p模糊搜索当前目录及其子目录下的所有文件

搜索框出来后, 输入关键字, 然后

ctrl + j/k 进行上下选择

ctrl + x 在当前窗口水平分屏打开文件

ctrl + v 同上, 垂直分屏

ctrl + t 在tab中打开

最终配置

Bundle 'ctrlpvim/ctrlp.vim'
let g:ctrlp_map = 'p'
let g:ctrlp_cmd = 'CtrlP'
map f :CtrlPMRU
let g:ctrlp_custom_ignore = {
    \ 'dir':  '\v[\/]\.(git|hg|svn|rvm)$',
    \ 'file': '\v\.(exe|so|dll|zip|tar|tar.gz|pyc)$',
    \ }
let g:ctrlp_working_path_mode=0
let g:ctrlp_match_window_bottom=1
let g:ctrlp_max_height=15
let g:ctrlp_match_window_reversed=0
let g:ctrlp_mruf_max=500
let g:ctrlp_follow_symlinks=1

其他

更多操作, 详见文档
可以考虑废弃fuzzyfinder / Command-T
可以考虑只用一个快捷键, 配置映射到:CtrlPMixed, 就可以一键搜索文件/buffer/mru

附: ctrlp的插件`ctrlp-funky`

作用: 模糊搜索当前文件中所有函数

github: ctrlp-funky

安装

Bundle 'tacahiroy/ctrlp-funky'

使用

绑定快捷键

fu 进入当前文件的函数列表搜索

fU 搜索当前光标下单词对应的函数

最终配置

Bundle 'tacahiroy/ctrlp-funky'
nnoremap fu :CtrlPFunky
" narrow the list down with a word under cursor
nnoremap fU :execute 'CtrlPFunky ' . expand('')
let g:ctrlp_funky_syntax_highlight = 1

let g:ctrlp_extensions = ['funky']

vim插件: airline[状态栏增强]

Sun, 07 Jun 2015 18:13:00 +0800

k-vim配置 github

作用: 状态栏增强展示

github:vim-airline

之前用过powline, 最终切到airline

安装

Bundle 'bling/vim-airline'

使用

状态栏增强, 集成支持ctrlp/nerdtree/tagbar等一些列插件features

airline.png

最终配置

Bundle 'bling/vim-airline'
if !exists('g:airline_symbols')
let g:airline_symbols = {}
endif
let g:airline_left_sep = '▶'
let g:airline_left_alt_sep = '❯'
let g:airline_right_sep = '◀'
let g:airline_right_alt_sep = '❮'
let g:airline_symbols.linenr = '¶'
let g:airline_symbols.branch = '⎇'

" 是否打开tabline
" let g:airline#extensions#tabline#enabled = 1

vim插件: theme[主题]

Sun, 07 Jun 2015 18:12:00 +0800

k-vim配置 github

主题, 在k-vim中, 默认配置了两个

1. solarize

github: solarized

配置

Bundle 'altercation/vim-colors-solarized'
let g:solarized_termtrans=1
let g:solarized_contrast="normal"
let g:solarized_visibility="normal"

2. molokai

github: molokai

配置

Bundle 'tomasr/molokai'
" monokai原始背景色
let g:molokai_original = 1

启用:

Bundle之后安装, 仅仅是安装, 要启用哪个主题, 需要在vimrc中显式指定

set background=dark
set t_Co=256
colorscheme solarized
" colorscheme molokai
" colorscheme desert

建议

有包含大部分主题的插件, 但是就个人而言, 够用就行, 所以k-vim中只保留了两个, 曾经习惯monokai, 后来转到solarized, 自己喜欢的才是最好的

vim插件: tagbar[大纲式导航]

Sun, 07 Jun 2015 18:11:00 +0800

k-vim配置 github

tagbar, 可以将正在编辑的文件生成一个大纲, 包含类/方法/变量等, 可以选中快速跳转到目标位置, 编辑大文件特别有用.

评价: 五星

作用: 大纲式快速导航

github: tagbar

安装

首先, vim必须是7.0以上

安装依赖 Exuberant ctags

# ubuntu
sudo apt-get install ctags

# centos
sudo yum install ctags

# mac
brew install ctags

在vim中安装tagbar

Bundle 'majutsushi/tagbar'

使用

在k-vim中配置快捷键为F9, 编辑文件时按F9, 进入, 上下移动(jk)), 选中回车后会跳转

如果安装了i easymotion, 还可以使用其快速跳转

最终配置

Bundle 'majutsushi/tagbar'
nmap  :TagbarToggle
" 启动时自动focus
let g:tagbar_autofocus = 1

" for ruby, delete if you do not need
let g:tagbar_type_ruby = {
    \ 'kinds' : [
        \ 'm:modules',
        \ 'c:classes',
        \ 'd:describes',
        \ 'C:contexts',
        \ 'f:methods',
        \ 'F:singleton methods'
    \ ]
\ }

建议

只配置一个快捷键, 可以根据需要定制具体语言的tagbar展示内容. 文档地址
建议废弃taglist(年久失修了), ctrlp+tagbar实际使用效果更好
如果在写golang的时候要用到tagbar, 需要安装gotags支持

vim插件: nerdcommenter[快速注释]

Sun, 07 Jun 2015 18:10:00 +0800

k-vim配置 github

最经常用的插件之一

作用: 快速注释/解开注释

github: nerdcommenter

安装

Bundle 'scrooloose/nerdcommenter'

使用

使用默认的快捷键, 不需要自己绑定

cc   加注释
cu   解开注释

c  加上/解开注释, 智能判断
cy   先复制, 再注解(p可以进行黏贴)

最终配置

Bundle 'scrooloose/nerdcommenter'
" 注释的时候自动加个空格, 强迫症必配
let g:NERDSpaceDelims=1

建议

同类插件 tcomment / vim-commentary, 有兴趣的话, 可以对比下后者和nerdcommenter
常用就三四个快捷键, 更多快捷键自取文档

vim插件: rainbow_parentheses[括号高亮]

Sun, 07 Jun 2015 18:09:00 +0800

k-vim配置 github

作用: 括号(小括号/中括号/大括号)

github: rainbow_parentheses.vim

安装

Bundle 'kien/rainbow_parentheses.vim' [DONE]

使用

被动(虽然支持主动触发), 可以设定括号高亮展示, 包括()[]{}<>

最终配置

Bundle 'kien/rainbow_parentheses.vim'
let g:rbpt_colorpairs = [
    \ ['brown',       'RoyalBlue3'],
    \ ['Darkblue',    'SeaGreen3'],
    \ ['darkgray',    'DarkOrchid3'],
    \ ['darkgreen',   'firebrick3'],
    \ ['darkcyan',    'RoyalBlue3'],
    \ ['darkred',     'SeaGreen3'],
    \ ['darkmagenta', 'DarkOrchid3'],
    \ ['brown',       'firebrick3'],
    \ ['gray',        'RoyalBlue3'],
    \ ['darkmagenta', 'DarkOrchid3'],
    \ ['Darkblue',    'firebrick3'],
    \ ['darkgreen',   'RoyalBlue3'],
    \ ['darkcyan',    'SeaGreen3'],
    \ ['darkred',     'DarkOrchid3'],
    \ ['red',         'firebrick3'],
    \ ]

" 不加入这行, 防止黑色括号出现, 很难识别
" \ ['black',       'SeaGreen3'],

let g:rbpt_max = 16
let g:rbpt_loadcmd_toggle = 0
au VimEnter * RainbowParenthesesToggle
au Syntax * RainbowParenthesesLoadRound
au Syntax * RainbowParenthesesLoadSquare
au Syntax * RainbowParenthesesLoadBraces

建议

开启16对括号匹配一般就够了
可以根据自己需求, 确认<>是否开启, 具体见github文档
不建议配置快捷键, 当做被动属性, 省心省事

vim插件: syntastic[语法检查]

Sun, 07 Jun 2015 18:08:00 +0800

k-vim配置 github

作用: 语法检查, 支持大部分的语言

github: syntastic

安装

Bundle 'scrooloose/syntastic'

使用

被动技能, 设置打开时开启, 则打开对应文件的时候, 会自动进行语法检查, 高亮错误位置

注意, 针对某些具体语言, 指定了checker, 需要对应安装外部依赖, 例如pyflakes/pep8/jshint等等

主动技能, k-vim中配置绑定了s打开错误列表面板

默认

:Errors 显示错误面板
:lnext  到下一个错误
:lprevious 到上一个错误

最终配置

Bundle 'scrooloose/syntastic'
let g:syntastic_error_symbol='>>'
let g:syntastic_warning_symbol='>'
let g:syntastic_check_on_open=1
let g:syntastic_check_on_wq=0
let g:syntastic_enable_highlighting=1
let g:syntastic_python_checkers=['pyflakes'] " 使用pyflakes,速度比pylint快
let g:syntastic_javascript_checkers = ['jsl', 'jshint']
let g:syntastic_html_checkers=['tidy', 'jshint']
" 修改高亮的背景色, 适应主题
highlight SyntasticErrorSign guifg=white guibg=black

" to see error location list
let g:syntastic_always_populate_loc_list = 0
let g:syntastic_auto_loc_list = 0
let g:syntastic_loc_list_height = 5
function! ToggleErrors()
    let old_last_winnr = winnr('$')
    lclose
    if old_last_winnr == winnr('$')
        " Nothing was closed, open syntastic error location panel
        Errors
    endif
endfunction
nnoremap s :call ToggleErrors()
" nnoremap sn :lnext
" nnoremap sp :lprevious

建议

支持语言的列表, 见这里

vim插件: delimitmate[符号自动补全]

Sun, 07 Jun 2015 18:07:00 +0800

k-vim配置 github

作用: 自动补全引号(单引号/双引号/反引号), 括号(()[]{})

github: delimitMate

安装

Bundle 'Raimondi/delimitMate'

使用

被动技能, 在编辑输入的时候触发

问题: 如何在结束输入后, 自动跳转到符号后面

触发后, 假设你要跳到补全后的符号后面继续编辑, 按Shift-Tab

# 1. 按", 自动补全
"|"

# 2.输入`hello`
"hello|"

# 3. 按 shift-tab, 跳到补全的符号后面, 还是insert-mode
"hello"|

最终配置

" 自动补全单引号，双引号等
Bundle 'Raimondi/delimitMate'

" for python docstring ", 特别有用
au FileType python let b:delimitMate_nesting_quotes = ['"']
" 关闭某些类型文件的自动补全
"au FileType mail let b:delimitMate_autoclose = 0

建议

有很多款括号等自动补全的插件, 这款在功能和可配上都不错, 需要自定义的可以看文档
同类插件

smartinput https://github.com/kana/vim-smartinput
lexima https://github.com/cohama/lexima.vim  类似多光标替换
auto-pairs https://github.com/jiangmiao/auto-pairs
autoclose  https://github.com/Townk/vim-autoclose

TODO:

粘贴代码的时候自动补全括号这个特性怎么去掉?

vim插件: matchit[成对标签跳转]

Sun, 07 Jun 2015 18:06:00 +0800

k-vim配置 github

这个插件最后一次更新是2008年, 七年前了……

vim的%, 会自动跳转到匹配的()[]{}<>等符号, 但是在编辑html和xml的时候, 可能需要在配对标签直接跳转, 这个插件扩展实现了这个功能.

作用: %跳转到匹配的标签

github: matchit

安装

Bundle 'vim-scripts/matchit.zip'

使用

在需要跳转的位置按%, 跳转到匹配位置

例如 xml/html中支持成对标签之间的跳转

最终配置

" 没错, 只有一行
Bundle 'vim-scripts/matchit.zip'

建议

根据自己需求确定要不要这个插件, 虽然小, 但是没用的话就不需要装了

vim插件: easy-align[快速对齐]

Sun, 07 Jun 2015 18:05:00 +0800

k-vim配置 github

作用: 快速进行对齐/格式化

github: vim-easy-align

安装

Bundle 'junegunn/vim-easy-align'

使用

绑定快捷键 a, 使用V进入选择, 选取多行, 之后触发

,a=        对齐等号表达
,a:        对齐冒号表达式(json/map等)

# 默认左对齐
,a  首个空格对齐
,a2 第二个空格对齐
,a- 倒数第一个空格对齐
,a-2 倒数第二个空格对齐
,a* 所有空格依次对齐

# 右对齐
,a*

最终配置

Bundle 'junegunn/vim-easy-align'
vmap a (EasyAlign)
nmap a (EasyAlign)
if !exists('g:easy_align_delimiters')
  let g:easy_align_delimiters = {}
endif
let g:easy_align_delimiters['#'] = { 'pattern': '#', 'ignore_groups': ['String'] }

建议

同类插件 tabular , 个人觉得vim-easy-align更符合直觉, 更新频繁, 文档, 教程也更全, 例子

vim插件: multiple-cursors[多光标操作]

Sun, 07 Jun 2015 18:03:00 +0800

k-vim配置 github

作用: 类似sublimetext的多光标选中

github: vim=multiple-cursors

安装

Bundle 'terryma/vim-multiple-cursors'

使用

默认快捷键

ctrl+m 选中一个
ctrl+p 放弃一个, 回到上一个
ctrl+x 跳过当前选中, 选中下一个
esc    退出

选中后, 可以进行增删替换a/c/x等

最终配置

Bundle 'terryma/vim-multiple-cursors'
let g:multi_cursor_use_default_mapping=0
" Default mapping
let g:multi_cursor_next_key=''
let g:multi_cursor_prev_key=''
let g:multi_cursor_skip_key=''
let g:multi_cursor_quit_key=''

建议

无

vim插件: vim-signature[快速标记跳转]

Sun, 07 Jun 2015 18:02:00 +0800

k-vim配置 github

作用: 标签展示以及快速跳转(增强vim的书签功能)

github: signature

安装

Bundle "kshenoy/vim-signature"

使用

使用默认快捷键

m[a-zA-Z]   打标签
'[a-zA-Z]   跳转到标签位置

'.          最后一次变更的地方
''          跳回来的地方(最近两个位置跳转)

m    去除所有标签

最终配置

Bundle "kshenoy/vim-signature"

建议

无

vim插件: easymotion[快速跳转]

Sun, 07 Jun 2015 18:01:00 +0800

k-vim配置 github

说明: 全局映射为,

除却hjkl, gg, G, Ctrl-D/U, 以及 [f/F]和[t/T]这些vim默认的移动方式

有没有更高效的移动做法么? 回答是肯定的

这个插件的唯一目的就是: 快速跳转

作用: 如何进行更快速的光标移动

github: github

安装

Bundle 'Lokaltog/vim-easymotion'

用法1: 跳转到当前光标前后的位置(w/b)

快捷键w(即,,w)和b(即,,b)

助记: word and back

演示:

easy_motion_base.gif

用法2: 搜索跳转(s)

快捷键s(即,,s), 然后输入要搜索的字母, 这个跳转是双向的

助记: search

演示:

用法3: 行级跳转(jk)

配置

map j (easymotion-j)
map k (easymotion-k)

快捷键: j和k(即,,j和,,k)

助记: hjkl不解释

演示:

用法4: 行内跳转(hl)

配置

map h (easymotion-linebackward)
map l (easymotion-lineforward)

快捷键h和l(即,,h和,,l)

助记: hjkl不解释

用法5: 重复上一次动作(.)

配置

map . (easymotion-repeat)

快捷键.

助记: 同repeat插件….

最终配置

Bundle 'Lokaltog/vim-easymotion'
let g:EasyMotion_smartcase = 1
"let g:EasyMotion_startofline = 0 " keep cursor colum when JK motion
map h (easymotion-linebackward)
map j (easymotion-j)
map k (easymotion-k)
map l (easymotion-lineforward)
" 重复上一次操作, 类似repeat插件, 很强大
map . (easymotion-repeat)

建议

还可以f和t, 不过建议简单化, 一个w/b走天下.
如果你不经常使用s, 可以将s改键, nmap s (easymotion-s), 这样你只需要输入s就可以进行搜索快速跳转(强迫症表示不能忍….) 具体做法见官方文档
默认作为这个插件的快捷键其实挺好的, 貌似没有其他插件会导致冲突, 还可以配置一整套, 强迫症很满意
可以配置2/n个字符的搜索跳转, 更精准, 按需自取(个人觉得太复杂了没必要) 文档和文档
这个插件专心做好跳转就好, 没必要把搜索的活给做了

vim插件: vundle[管理插件]

Sun, 07 Jun 2015 18:00:00 +0800

k-vim配置 github

第一个需要手动安装的插件, 其他的插件通过这个来进行管理

作用: 管理其他所有插件(安装/更新/移除)

github:vundle

安装

git clone https://github.com/gmarik/Vundle.vim.git ~/.vim/bundle/Vundle.vi

使用

在.vimrc中加入/修改/删除自己需要的插件配置

Bundle 'scrooloose/syntastic'

然后, 在命令行模式下运行

:BundleInstall     install 安装配置的插件
:BundleInstall!    update  更新
:BundleClean       remove plugin not in list 删除本地无用插件

其他

同类插件 pathogen, neobundle
依旧是同类插件, vim-plug, 不过这个支持并行安装插件(目测如果是第一次配置机器会快很多….)

Elasticsearch几个问题的解决

Sat, 23 May 2015 08:00:00 +0800

今天惯例看统计报表, 才发现es集群悲剧了……昨天下午到今天早上, 持续报错, 写了1G的错误日志>_<#(暂无监控….)

当前状态: 单台机器, 单节点(空集群), 200W 数据, 500+shrads, 约3G大小

以下是几个问题的处理过程

大量unassigned shards

其实刚搭完运行时就是status: yellow(所有主分片可用，但存在不可用的从分片), 只有一个节点, 主分片启动并运行正常, 可以成功处理请求, 但是存在unassigned_shards, 即存在没有被分配到节点的从分片.(只有一个节点…..)

.当时数据量小, 就暂时没关注. 然后, 随着时间推移, 出现了大量unassigned shards

curl -XGET http://localhost:9200/_cluster/health\?pretty
{
  "cluster_name" : "elasticsearch",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 2,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 538,
  "active_shards" : 538,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 558,
"number_of_pending_tasks" : 0
}

处理方式: 找了台内网机器, 部署另一个节点(保证cluster.name一致即可, 自动发现, 赞一个). 当然, 如果你资源有限只有一台机器, 使用相同命令再启动一个es实例也行. 再次检查集群健康, 发现unassigned_shards减少, active_shards增多.

操作完后, 集群健康从yellow恢复到 green

status: red

集群健康恶化了……

这次检查发现是status: red(存在不可用的主要分片)

curl -XGET http://localhost:9200/_cluster/health\?pretty
{
  "cluster_name" : "elasticsearch",
  "status" : "red",    // missing some primary shards
  "timed_out" : false,
  "number_of_nodes" : 4,
  "number_of_data_nodes" : 2,
  "active_primary_shards" : 538,
  "active_shards" : 1076,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 20,  // where your lost primary shards are.
  "number_of_pending_tasks" : 0
}

fix unassigned shards

开始着手修复

查看所有分片状态

curl -XGET http://localhost:9200/_cat/shards

找出UNASSIGNED分片

curl -s "http://localhost:9200/_cat/shards" | grep UNASSIGNED
pv-2015.05.22                 3 p UNASSIGNED
pv-2015.05.22                 3 r UNASSIGNED
pv-2015.05.22                 1 p UNASSIGNED
pv-2015.05.22                 1 r UNASSIGNED

查询得到master节点的唯一标识

curl 'localhost:9200/_nodes/process?pretty'

{
  "cluster_name" : "elasticsearch",
  "nodes" : {
    "AfUyuXmGTESHXpwi4OExxx" : {
      "name" : "Master",
     ....
      "attributes" : {
        "master" : "true"
      },
.....

执行reroute(分多次, 变更shard的值为UNASSIGNED查询结果中编号, 上一步查询结果是1和3)

curl -XPOST 'localhost:9200/_cluster/reroute' -d '{
        "commands" : [ {
              "allocate" : {
                  "index" : "pv-2015.05.22",
                  "shard" : 1,
                  "node" : "AfUyuXmGTESHXpwi4OExxx",
                  "allow_primary" : true
              }
            }
        ]
    }'

批量处理的脚本(当数量很多的话, 注意替换node的名字)

#!/bin/bash

for index in $(curl  -s 'http://localhost:9200/_cat/shards' | grep UNASSIGNED | awk '{print $1}' | sort | uniq); do
    for shard in $(curl  -s 'http://localhost:9200/_cat/shards' | grep UNASSIGNED | grep $index | awk '{print $2}' | sort | uniq); do
        echo  $index $shard

        curl -XPOST 'localhost:9200/_cluster/reroute' -d "{
            'commands' : [ {
                  'allocate' : {
                      'index' : $index,
                      'shard' : $shard,
                      'node' : 'Master',
                      'allow_primary' : true
                  }
                }
            ]
        }"

        sleep 5
    done
done

“Too many open files”

发现日志中大量出现这个错误

执行

curl http://localhost:9200/_nodes/process\?pretty

可以看到

"max_file_descriptors" : 4096,

官方文档中

Make sure to increase the number of open files descriptors on the machine (or for the user running elasticsearch). Setting it to 32k or even 64k is recommended.

而此时, 可以在系统级做修改, 然后全局生效

最简单的做法, 在bin/elasticsearch文件开始的位置加入

ulimit -n 64000

然后重启es, 再次查询看到

"max_file_descriptors" : 64000,

问题解决

待续, 目测还有很多坑, 而且随着数据量上来, 会遇到越来越多的坑……

2015-05-23 于深圳

分享一份 Vim 简介PPT

Sun, 10 May 2015 08:00:00 +0800

这是近期做团队分享的一份ppt, 原稿用markdown仓促写的, 感谢markdown及weakpoint, 可以直接将markdown转成ppt

这次分享主要不是讲vim, 更多的是关于工具的使用和思考

其实, 无非是记住一些东西, 忘记一些东西, 定制和寻找适合自己的工具, 善用工具, 成为主人而不是奴隶

将markdown原稿放出, 很多实操演示, 在文稿中是看不到的……

vim

wklken

vim

曲线:

vim

Vim the Six Billion Dollar editor

Better, Stronger, Faster.

Maybe:

成为你最后一个使用的编辑器

vim

文本编辑器 , 不是IDE

能做一些事情, 但是一些事情是做不到的, 不要强求, 该用IDE的时候, 用就是了

how

步骤:(简明 Vim 练级攻略)

存活
感觉良好
觉得更好，更强，更快
使用VIM的超能力

诀窍:

不断练习

肌肉记忆, 直觉-行动而不是思考-行动(十倍差距)

过程:

一个vimer必定会经历的过程

什么都没有, 纯vi
什么都有
只留适合自己的, 不适合自己也要配置成适合自己的
什么都没有(听说)

target

实操: vim能做什么?
思考:

哪些是你常用编辑器可以实现的?
哪些好的功能是你想要却没有的? 能否解决
你的痛点在哪里?
工作流

模式

移动1

概览

移动2

忘掉刚才那张图……

移动3

hjkl (请杜绝方向键, 移动右手到方向键区浪费时间)
```
  map  
  map  
  map  
  map  
```
单词: w / b / e (忘记: W/B/E-以空白为分隔符, 要多按shift键键/不好记/用得少)
行内: 0 / $ (忘记: ^, 够不着啊)
段落: { / }

移动4

页: / (忘记: ctrl-f/ctrl-b, 都在左侧键区左手太累, 经常是要上要下, 而不是往一个方向走)
可视范围: H M L (全部忘记, 没多大用, 要按shift, 混淆记忆)
文件内: gg / G / :N (基本够了)
匹配处: % 括号匹配 / # (忘记: *, 在键盘左侧, 太远不好敲, 可以交换#和*的功能)

更强大的, 看后面的插件部分

编辑

N

x
dd
dw / db / d$ / dG / dgg
yw / yb / y$
yy / p / P
J

撤销和重复

选中

select

v: vw / vb / vta / v$

block select

-> hjkl/

行首加 / 行尾加

搜索

行内搜索: f / t (可以选择性遗忘t, 同时, 忘记F/T, 甚至可以忘记f, 你不需要)

为什么? 看后面的easy-motion插件

替换

记住这两个似乎够了(频率最高)

:1,10s/a/b/g
:%s/a/b/g

字符替换

文本对象

初学者基本不了解的一个特性

a or i
a = all / i = in
action: d y v c

object:

  w(world) / s(sentence) / p{paragraph}
  " ' ) ] }

装插件, 可以是: l(line) e(entire file) i(indent)

分屏

:sp file1
:vsp file2
ctrl-w-h/j/k/l (改键 ctrl-h/j/k/l)
ctrl-w-H/J/K/L

插件1: 语法检查

syntastic

插件2: 自动补全与代码片段

两大效率神器

毫秒级补全/ python / c系等, 编译安装, 具体自行文档

括号补全

delimimate

xml/html标签补全

closetag

插件3: 快速编码

快速注释:

nerdcommenter

快速编辑

去空格

vim-trailing-whitespace

代码对齐

vim-easy-align

插件4: 快速运行

vim-quickrun

插件5: 快速移动

行/位置/搜索

vim-easymotion

mark

vim-signature

插件6: 快速选中

区块

vim-expand-region

多标签

vim-multiple-cursors

插件7: 文件导航/搜索

目录导航

nerdtree

标签导航

tagbar

搜索文件

ctrlp.vim

搜索代码

ctrlsf.vim

关于插件1

不是越多越好
配了用不上 = 没配 + 浪费资源
同一功能, 对比几个插件, 选择一个合适的
快捷键配置一定要容易记
相信我, 一个插件用的最多的快捷键就两个, 绝大多数情况下不会多于两个, 不用耗费心力在配置更强大的操作上

关于插件2

更符合自觉的键位/操作
尽量减少敲击次数
杜绝一切无效的敲击
个性化, 定制到每个细节, 力争解决自己所有痛点

高级

怎么配置:

参考下别人的vim配置, 读插件文档, 读插件代码, 必要时改一份

资源

配置:

文章:

others:

QA

Thx:)

k-vim 更新9.0版本

Tue, 05 May 2015 08:00:00 +0800

直达链接

趁着近期有点时间, 将积累几个月的改进/痛点/更新等处理了一把, k-vim正式更新到9.0版本.

如果喜欢, 欢迎star/fork, 欢迎提pr.

本次更新: 完整更新日志

    1. 新增依赖ag(the_silver_searcher)

    安装 [the_silver_searcher](https://github.com/ggreer/the_silver_searcher#installing)

    具体见文档

    2. 引入 thinca/vim-quickrun

        2.1 以message的方式展示, 同原先的F10行为, 按回车过掉消息
        2.2    F10 运行 / ,r  运行

    2. 引入dyng/ctrlsf.vim, 类似 sublimetext的全局搜索

        2.1 依赖于ag的全局搜索
        2.2 将光标挪到单词, 快捷键\  - 进入全局搜索, 移入分屏界面, o/t/T/q操作


    3. 代码折叠

        3.1 zz 折叠/打开所有代码toggle(本次新增配置)
        3.2 za 当前光标所在区域折叠toggle(vim默认的)

    4. syntastic语法检查

        4.1 修正语法检查错误高亮, 精确到具体错误单词
        4.2 开启python的pep8, 允许忽略某些warning, vimrc.bundles: line 40
        4.3 s  打开当前文件所有语法错误列表(新增配置)

    5.  easymotion

        5.1 .  重复上一次easymotion命令, 更高效(新增配置)

    6. 修改RainbowParentheses, 防止黑色括号出现

    7. 修改vim-expand-region快捷键

        7.1 v 扩增选中范围
        7.2 V 缩小选中范围

    8. 新增主题tomorrow

后面, 针对每个插件的使用, 之前笔记整理了一把, 后续逐步发出.

另外, 开始在实际项目中更多的使用golang, 最近在搞ELK日志收集统计系统, 做了一个收集任意端上报数据, 落地成日志文件, 然后经由logstash转存储到es.

http_json_logger: 一个日志上报收集服务, 可以收集从浏览器/js/android/ios等通过http上报的日志, 落地为文本文件, 用作后续日志统计/分析/数据挖掘等. logger模块是使用beego的logger模块精简后的, 这是第二个golang项目, 上一个是下拉提示 suggestion

另一个更新是, 花了两个小时, 给blog文章页面加了生成目录的功能, 另外搞了下阅读时左侧展示当前所在位置标题.(还无法支持响应式……)

度过了接近一年多的瓶颈期, 过去一年多可能是近几年迷茫和挣扎的一段时间, 眼睁睁看自己在某个地方卡住, 苦苦挣扎, 一步步往前, 这个过程是痛苦的, 独自成长, 一点点地去达成1万小时的目标

随着时间流逝, 一切在逐渐明晰, 从测试转开发, 正式两年半了, 不短不长, 近期却有很多感悟. 或许, 该有些突破了吧.

后续在自建wiki的同时, 提高blog的更新频率.

wklken

2015-05-05 于深圳

关于知识管理工具的思考

Sat, 02 May 2015 08:00:00 +0800

毕业快四年了, 测试一年半, 后端开发两年半, 时间如梭.

回顾这些年, 笔记什么的, 是一部漫长的迁移史/血泪史, 如果能早些学习git/markdown等, 能早些了解到一些工具, 应该能省下不少时间吧.

汇总整理下自己所使用过的知识管理工具

工具的目标: 提升效率

而我们的目的很简单

方便快速收集/记录/整理/沉淀
快速搜索

手抄笔记

大学那段时间

那时候, 学习linux, 学习vim, 学习java/jsp/ssh...., 学习xml等等, 大多数情况下, 都是看书+手抄笔记大法, 那时候完全没有意识去对知识进行组织和整理, 几年下来, 积累了各类笔记, 一大堆, 过年回家还发现当时学习java的六七本笔记, 还有oracle, 还有不知道什么时候做的c语言学习笔记(完全忘了).

手抄, 现在回过头来, 费时费力, 效率极低, 但是就当时环境而言, 不失为一种好的做法(相对于啥都没记来说), 好记性不如烂笔头.

而且, 上课/参加培训等等, 都通过笔记来记录

手抄的做法, 太过古老, 如果是非技术书籍, 抑或个人喜欢纸质书籍, 不失为一种好的做法. 但是技术书籍, 手抄太过低效, 不易整理, 更不易搜索, 看似积累了很多, 实际沉淀不多.

word

到毕业做测试一年多, 那时大多数情况下是windows系统, 毕业那会刚刚把系统转到ubuntu, 但是工作环境主要还是windows, 用终端连接主机工作.

正式参加工作, 虽然还经常买纸质书, 但是正儿八经系统啃书的机会相当少, 大部分是工作中碎片化学习的东西, 所以手抄笔记完全从生活中消失了

这时候, 开始有意识记录使用电脑记录, 以及整理汇总一些东西.

这段时间, 系统性整理了linux & shell笔记/vim笔记等, 测试理论, python入门等等. 工作中还是svn, 对git完全没有概念, 更别说markdown了.

这时候笔记以word形式归总在目录下, 通过金山快盘同步, 后来迁到dropbox了

那时候evernote/有道笔记还刚刚火起, 对云端没有太多需求, 没怎么关注

word记录, 相对手抄效率略高, 也方便整理复习, 搜索功能有限.

有道笔记 - 印象笔记

学习markdown了, 也开始玩github, 这时候云笔记开始火了, 刚好, 开始玩微博, 对各种人各种关注, 天天刷微博, 这个习惯延续至今.

其实用得最多的只有一个功能: 网页剪藏

每个人都会经历这么一个阶段, 碰到各种资源信息, 疯狂收集, 不管有用没用, 先搞下来再说.

然后, 发现有3000+剪藏, 微博上2000+收藏, 后来觉得有道不足够靠谱, 丢过笔记, 本着折腾的信念, 开始迁移笔记, 3000+剪藏只能以尽量高效的方式废弃: 当前不涉及不会接触短期内也不会关注的不管好不好以后有没有用全部删掉, 这样, 完成了自己的折腾史.

除了剪藏, 最大的功能就是云同步了, 公司电脑和家里电脑同步. 那时候还在用android机, 移动端记录的需求倒是不怎么强烈

这期间, 明白了资源再多, 无用就是无用, 心态上改变了, 微博停止了点收藏, 那2000+收藏, 也就废弃了. 另外, 也开始进行关注的整理, 获取有效而稳定的信息流.

PS: 云笔记最坑的是同步, 然后你发现丢了…..还有, 同步, 你发现冲突了, 然后在两份文件里面diff……都经历过, 心塞

印象笔记 - Ulysess

印象笔记, 用了一段时间, 这时候也换了mac和iphone, 以及后来ipad, 开始随时记录.

但是用了一段时间, 发现一个问题: 不支持markdown

后来, 又有一个问题: 代码高亮也不支持

后来的后来, 发现: 这编辑功能也太渣了吧

这时候, 刚好博客都迁移到自己站点, 全markdown静态.

想着技术部分的笔记是否有一个更好的编辑/展现方式.

也正好, 这时候对mac app有着一股狂热, 虽然现在过去了, 但是当时刚刚使用mac, 感受到了好处, 开始折腾各类工具, 正好碰上了ulysess

这时候, 感觉技术笔记迁移到上面会更好, 然后逐步迁移.

no zuo no die, 展现不错, 支持markdown, 支持高亮, 对于外貌党来说, 很赞的编辑器, 是的, 迁完之后, 才想起来, 这货是个编辑器, 不是笔记.

由于搜索太弱, 不支持多端等等情况, 年前有发生了一次全部笔记给我double了一份, 老天, 几百篇笔记都变成双份了. 我花了一整天时间手工删除重复笔记. (目测可能是icloud的锅)

死心了, 接着迁移

WizNote

为知笔记, 口碑不错, 试用了几天

支持markdown, 目测是云笔记系列为数不多能支持这个的.

然后, 为了弃用 ulysess, 花了点时间迁移完(ulysess作为编辑器还是很赞的, 还在用).

用着用着, 发现这markdown, 这剪藏, 似乎没有那么理想, 体验不佳, 用得越多越感觉到

这时候, 搬了一回家, 发现搬书, 完全是一个自虐的活. 而且很多大部头看过后都不在打开, 很多书被我脱水了也没有阅读价值了……开始转向电子书, 多看

这时候, 开始思考…….然后, 迁移

分级的知识管理

后来, 到了现在的情况: 分级, 邮件/evernote/gollum

1. 收集

要求: 方便, 阅读格式ok, 不丢

选择: Evernote国际版, 有条件上个高级版, 别问我为啥不用印象笔记

专门建立一个笔记本: Inbox, 对于碰到的感兴趣的东西, 一键剪藏, 或者分享到evernote, 简单直接有效, 这点是所有云笔记中做的最好的

另外, 支持多看读书笔记同步, 感受到这个世界深深地温暖

PS: 对于微博的处理, 额, 我现在是这么干的: “分享到-邮件”, 给自己发邮件, 然后定期处理:), 很有效.(使用unibox, 同一个发件人的邮件都在一个对话窗口里面, 很好处理 )

2. 整理

要求: 易用, 高效

选择: evernote, mindnode pro, gollum

主要是一些点, 标注, 做思维导图

对于观点/经验等等东西, 可以阅读梳理后, 放置到evernote

对于技术类/干货类东西, 放evernote

3. 沉淀

要求: 高效

选择: evernote, gollum

沉淀是再次提取思考的过程, 还是evernote

不过, 对于技术类东西, 其实对云同步要求不需要那么高, 所以选择了自建wiki, 写完markdown往目录一扔, 就可以在本地web server上看到, 搜索等等, 是对技术/代码沉淀的最佳工具

4. 搜索

要求: 精准高效

选择: evernote, gollum

用一下就知道了

这完全是一部折腾的血泪史, 只有不断经历, 才能进步, 进化, 最终找到适合自己的方式.

没有最好的方法, 只有最合适的方法, 对工具同理, 所以在整个过程中, 还是建议, 明确自己的需求, 要解决的问题等, 多关注一些东西, 多尝试.

好了, 就这些:)

2015-05-02

wklken 于深圳

Logstash+ElasticSearch+Kibana处理nginx访问日志

Sun, 26 Apr 2015 08:00:00 +0800

ELK似乎是当前最为流行的日志收集-存储-分析的全套解决方案.

去年年初, 公司里已经在用, 当时自己还山寨了一个统计系统(postgresql-echarts, 日志无结构化, json形式存储到postgresql, 构建统一前端配置生成, 调用统一查询接口, 具体细节), 已经过了一年有余.

一年刚好, 发生了很多事, 那套系统不知现在如何了.

在新的公司, 一切都得从0到1, 近期开始关注日志/数据上报/统计, 以及后续的数据挖掘等.

搭建, 测试并上线了一套简单的系统, 初期将所有服务器的nginx日志, 以及搜索日志进行处理.

下面主要介绍对nginx日志进行处理的过程, 不是针对elk的介绍, 所有涉及ip的地方都改成127.0.0.1了, 根据自己环境进行修改

1. nginx日志 -> logstash shipper -> redis

在centos使用yum安装nginx后, 默认/etc/nginx/nginx.conf中的日志格式定义为:

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for"';

然后在具体server配置中使用

access_log /data/logs/nginx/{PROJECT_NAME}_access.log main;

此时, 我们需要做的是, 将access log通过logstash shipper读取, 转json, 发送到redis, 由后续的logstash indexer进行处理

步骤

1.在日志所在机器部署logstash

2.在logstash安装目录下的patterns中加入一个文件nginx

内容(与上面的log_format相对应)

NGUSERNAME [a-zA-Z\.\@\-\+_%]+
NGUSER %{NGUSERNAME}
NGINXACCESS %{IPORHOST:clientip} - %{NOTSPACE:remote_user} \[%{HTTPDATE:timestamp}\] \"(?:%{WORD:verb} %{NOTSPACE:request}(?: HTTP/%{NUMBER:httpversion})?|%{DATA:rawrequest})\" %{NUMBER:response} (?:%{NUMBER:bytes}|-) %{QS:referrer} %{QS:agent} %{NOTSPACE:http_x_forwarded_for}

3.增加一个logstash配置文件: logstash-project-access-log.conf

注意, input的file, filter的grok, output的redis-key

    input {
    file {
        path => [ "/data/logs/nginx/xxxx_access.log" ]
        start_position => "beginning"
    }
    }

    filter {
    mutate { replace => { "type" => "nginx_access" } }
    grok {
        match => { "message" => "%{NGINXACCESS}" }
    }
    date {
        match => [ "timestamp" , "dd/MMM/YYYY:HH:mm:ss Z" ]
    }
    geoip {
        source => "clientip"
    }
    }


    output {
    redis { host => "127.0.0.1" data_type => "list" key => "logstash:xxxx:access_log" }
    }

4.使用supervisor启动shipper.

    [program:logstash_xxxx_shipper]
    command=/var/shell/logstash/bin/logstash -f /var/shell/logstash/configs/nginx-xxxx-shipper.conf
    numprocs=1
    autostart=true
    autorestart=true
    log_stdout=true
    log_stderr=true
    logfile=/data/logs/logstash/logstash_xxxx_access.log

2. redis -> logstash indexer -> elasticsearch

注意, input的redis为上一步redis配置, key要对应, output的elasticsearch配置, index指定了最终es中存储对应的index, 加日期, 方便对日志进行定期删除

input {
redis {
    host => "127.0.0.1"
    port => "6379"
    key => "logstash:xxxx:access_log"
    data_type => "list"
    codec  => "json"
    type => "logstash-arthas-access"
    tags => ["arthas"]
}
}

output {
elasticsearch {
    host => "127.0.0.1"
    index => "logstash-arthas-access-%{+YYYY.MM.dd}"
}
}

3. elasticsearch -> kibana

剩下的其实没什么了, 启动kibana后, 配置好指向的es, 就可以在kibana中查看到实时的日志数据

demo环境截图

kibana中, 支持各种统计, 着实让人惊艳了一把.

除了基本的nginx日志, 还需要在各类url入口, 加入平台, 渠道等信息, 这样通过nginx访问日志, 可以统计到更多的信息

当然, 如果需要一些更为精确/特殊的统计, 需要自行进行数据上报的工作.

后续

更多的类型的日志聚合, 包括各类访问日志, 统计上报日志等, 日志落地成文件, 永久留存, 转入es中, 只留存三个月
如何对各类数据进行拆分/汇总
ELK整体部署/运维/扩容等, 包括数据清理
基于ES日志的业务自定义统计后台(kibana无法满足一些具体业务的统计需求)
为什么不使用logstash forwarder, 因为目前日志组成等较为简单, 简单处理 , 后续需要用到时再考虑

其他

1. 关于`logformat`和对应`grok`的配置

grok是logstash的一个插件, 文档

Grok is currently the best way in logstash to parse crappy unstructured log data into something structured and queryable

所以, 我们在处理nginx日志时, 需要根据具体logformat定义对应的grok表达式

除了上面例子中用的那套, 另一份

logformat

  log_format logstash '$http_host '
                      '$remote_addr [$time_local] '
                      '"$request" $status $body_bytes_sent '
                      '"$http_referer" "$http_user_agent" '
                      '$request_time '
                      '$upstream_response_time';

patterns/nginx

NGUSERNAME [a-zA-Z\.\@\-\+_%]+
NGUSER %{NGUSERNAME}
NGINXACCESS %{IPORHOST:http_host} %{IPORHOST:clientip} \[%{HTTPDATE:timestamp}\] \"(?:%{WORD:verb} %{NOTSPACE:request}(?: HTTP/%{NUMBER:httpversion})?|%{DATA:rawrequest})\" %{NUMBER:response} (?:%{NUMBER:bytes}|-) %{QS:referrer} %{QS:agent} %{NUMBER:request_time:float} %{NUMBER:upstream_time:float}

如果想自行定义, 可以使用 grokdebug, 将要解析的日志和配置的正则放入, 可以查看最终得到的结构化数据

2. elasticsearch插件

初期只安装了一个 kopf, web界面查看

3. supervisor

建议使用supervisor对elk进行管理,(ps. 不要用yum自带的, 版本太旧好多坑, 浪费1小时……使用pip install安装最新版本即可)

配置示例elk.conf

[program:elasticsearch]
command=/var/shell/elk/elasticsearch/bin/elasticsearch
numprocs=1
autostart=true
autorestart=true

[program:kibana]
command=/var/shell/elk/kibana/bin/kibana
numprocs=1
autostart=true
autorestart=true

[program:logstash_arthas]
command=/var/shell/elk/logstash/bin/logstash -f /var/shell/elk/logstash/config/xxxx_access.conf
numprocs=1
autostart=true
autorestart=true
log_stdout=true
log_stderr=true
logfile=/data/logs/elk/logstash/logstash_arthas_access.log

4. logstash坑

start_position => "beginning"

logstash, 会记录一份文件读到的位置, 在$HOME/.sincedb_xxxxx 如果要让logstash重新读取文件, 删除之即可, 重启shipper.

但是你可能发现es中重复记录了, 这是因为, 在output中, 没有定义存储到es时使用的document_id, es全部当成新纪录存入, 导致数据重复

2014, 在变化与坚持中前进

Wed, 18 Mar 2015 08:00:00 +0800

每年都来个总结, 似乎好多年了.

今年的总结拖了三个月, 为什么呢? 不说了, 什么都是理由罢了. 今天在角落里发现了这个, 想想, 还是发出来吧.

开始, 依旧很杂.

工作

今年(2014, 快一年了), 发生了一件事, 然后公司没了, 囧.

总之, 不愉快的过程, 见证了快播的终结.

这或许就是所谓的变化, 以及生活. 安详平和的环境可能瞬间被撕裂. 你永远不知道明天会是什么样的.

年后回来的时候, 还在愉快的码代码, 写一个统计系统, 然后事情就发生了, 然后依旧继续在优化统计系统, 写了一个月, 然后就结束了.

一切太过仓促, 没什么时间思考.

思及自己似乎一年多一直不能说止步不前, 但似乎长进没有预想中的那样大, 所以决定离开. 这个决定主要是从心, 直觉—“做事情总是追求意义”

善始善终, 逐一交接完毕, 然后离开.

没什么后悔的. 只是曾经的战友, 如今已各在一方.

感谢快播, 一年多日子, 一切, 唯有感恩.

离职后, 念及自己上次换工作的gap之一几天, 这次决定休息一下, 北上行走, 后面说, 需要想清楚一些东西.(千里行纪&工作三周年小结)

回来后, 疯狂地睡了一整天.

然后慢悠悠地宅了一个月(物极必反), 上网, 看书, 充充电, 追美剧……过着一个人的世界.

后来想想, 要找点事干了. 然后开始找工作, 历时一周(准确来说两天), 又是一个决定, 来了现在的公司.(广告时间, 甜品礼物)

我总认为, 迄今也一直坚持的一个观点, 活着, 总要做一些事情, 创造一些价值, 当然, 前置的一个观点是, 你需要做自己喜欢的事情.

目前的工作, 恰好都符合, 我正在做自己喜欢的事情, 也在努力做好, 也认同自己做的工作的价值, 跟随着项目以及公司, 逐步成长.

我能真真实实感受到那种演化成长的过程.

现在已经六个月了, 最大的感受是, 和一群靠谱的人, 在做一件有意义的事情. 虽然过程中, 有碰撞, 冲突, 阵痛, 但是经历了, 才一步步解决和成长

Maybe, We are making history.

记得面试的时候被问到What do you want to build? What do you want to change?, 到现在依旧反复自问.

新的环境, 新的伙伴, 开始的新的征程.

我给新伙伴的纸条里总会反复反复出现一句话(有偷懒的嫌疑)

既然选择了远方, 便只顾风雨兼程

So, 继续前进.

附, 之前写的一段话:) 对糖厂有兴趣的同学可以找我咨询……

在甜品工作是一种怎样的体验?

蟹妖>_<

这是一种什么感觉呢? 就是见证一个项目从第一行代码, 逐渐壮大, 完善, 重构, 在自己手中最终进化成一套完美的系统:)。 更重要的是, 代码, 不仅仅是一个个字符, 它有了其存在的意义和价值。 在这里, 可以安安静静一气呵成码一天代码, 也可以找产品 PK 需求, 找小伙伴一起讨论方案, 吐吐槽发发呆跑跑步。 什么是时间管理? 什么是拥抱变化? 什么是团队协作? ......有困难, 有冲突, 有想法, 有方案, 有成长。 既然选择了远方, 便只顾, 风雨兼程。

learning by doing

2014年, 尝试去学很多东西, 但是最后却发现, 貌似变成了记录/整理很多东西, 烂尾了很多项目….>_<

很多沉没成本在里面.

解决方案无他, 做一些东西出来.

开搞一些东西, 尽请期待吧:)

冲突与成长

这是之前在知乎上看到的一个观点: 没有冲突, 谈何成长.

我个人一个弱点, 就是很容易被说服.

这属于性格上的缺陷, 不够tough(too nice to everyone and everything), 在生活或者工作上, 总是避免冲突.

极力避免冲突, 但现实是冲突是无法避免的, 而我这样做是不对的

这直接导致了一路走来, 似乎成长不多.

一路顺风顺水顺心, 似乎看起来很好, 其实失去的更多不是么?

所谓”稳定”与”变化”的对立, 生活总是在变化的, 而变化势必导致冲突, 如何应对, 处理冲突? 这常常考验一个人的各个方面.

You can’t make everyone happy.

似乎还是明白晚了, 2014年开始的时候, 有一段时间纠结于一些不该纠结的事情, 作为一个不合格的组长, 带了一段时间的队. 不过不经历, 或许也就不会明白, 不是么.

所以, 结论是: 不要刻意去避免冲突, 把自己一直放在舒适区里, 就很难得到更多成长的机会.(有序, 原则, 底线, 规则)

不那么友好, 但是, 这才是正确的做事风格

变化

拥抱变化

这是 Ali 的文化之一, 一直铭记.

时间在快速向前, 一切都在变化.

世界上没有不变的东西, 只有相对不变的东西.

从偏向来说, 做后端开发会采取相对保守的策略.

以不变应万变这是目标之一, 但是现实中往往不尽人意, 需求变更神马的都是家常, 很多时候要为一些问题承担后果.

如何快速应对, 去拥抱变化, 这是一个问题.

包括能力上, 以及心境上.

能力上, 更多的是考验对需求的理解以及编码的功底. 如何在设计初期尽可能多考虑, 编码期模块接口等足够灵活等等

心境上, 要接受, 不排斥, 要意识到变化总是会存在的, 去想办法解决, 坦然受之.

但是, 变化也是有底线的, 例如上线前临阵改需求等, 需要坚守自己底线. 这不是一般的坑, 是大坑.

归到底, 不惧怕变化, 惧怕的是不可控的变化.

学会试着去拥抱变化.

生活与社交 — INTJ 的围城

内倾/直觉/思考/判断, 有兴趣可以去看看十六型人格.

INTJ, 对码农这门职业, 似乎有属性加成来的:)

但是, 对于生活社交, 似乎是灾难性的. 想太多, 看太多, 太过依赖直觉, 排斥一切无意义的事情.

INTJ, 在很多事情上, 注定是悲剧?!!

2014, 彻底宅的一年, 疯狂地看书, 刷电影, 刷美剧, 刷代码, 刷微博…….没有目的和方向, 同时战线拉太长导致了很多烂尾的半成品, 还有很多看了半本的书.

2014的一年, 这方面, 糟透了.

反思下来, 似乎自己逃避很多, 彻彻底底的逃避.

生活, 是时候做些改变了.

需要, 把一些该办的事情办了.

It’s always about time.

我们所在对抗的, 或者顺应的, 是一种叫做命运的东西

很多问题想不明白, 生活中存在很多悖论.

例如, 要成为什么样的人? 要去做什么? 要怎么做? 活着的意义? 时间的本质? 生存的本质?

时间是把杀猪刀, 今天度过了很多关键性节点, 例如, 毕业三周年, 例如来深两周年.

时间无情地收割一切, 无能为力, 无可奈何.

有时候, 看到一些景, 例如斑驳的阳光, 夕阳, 落叶, 车流, 人流, 总是想起以前某个时刻的感觉, 却想不清, 到底确切是哪个时刻了. 逝去的总是美好的, 而一切都在逝去.

我总是试图, 去寻找一切东西的意义, 却总是求而不得 ,所以迷茫

总感觉明白的太晚, 悟太晚, 太过纠结, 不够洒脱, 性格上还未经磨砺,

总告诉自己, 给生活做减法, 那些抛弃的, 就抛弃吧, 不用顾虑太多, 人生太短, 哪来那么多顾虑, 却总做不到. 性格很多缺陷.

一重心障, 破之便是新世界, 呆着? 不可能!

我还没有能力完全掌控自己的生活, 拒绝去做那些自己不喜欢的事情, 生活尚未能完全掌控.

我不知道未来会怎么样

无力, 力争活在当下, 仅此而已.

当下

很多时候, 不要去想以后, 等我有空了, 等过年了什么的, 想起来, 就去做, 当天当场就去做, 想起来, 就去实施, 人生, 很容易在这种等等等的过程中消耗掉

生活

码农有生活么?

废话.

2014匆匆, 过得并不如何, 自己过得太随意, 也就没有什么回想了.

好像连续拍了几十天的天空, 然后断了, 连续坚持每周末暴走, 然后也断了, 然后说好的看书, 也没坚持, 然后起了好多side project, 也没坚持, 然后……不提了

2015争取慢慢, 丰富些, 自由些.

年底的时候重读了三体和remote, 两本不搭边的书, 却给了自己很多想法.

2014年度盘点

年度iOS app: windy

午睡神器, 抗干扰, 唯一缺点, 可能睡过头……

年度mac app: things

重回GTD, 这是继do.im/clear/omini focus/wunderlist等一系列试用后, 剩下的

年度mac app2: dayone

很早就入了, 但是2014用得特别多, 我浏览中竟然发现2014-5-2 吃了今年夏天的第一个甜筒 这种丧心病狂的记录……不过也蛮好的, 一年点滴, 尽在其中.

年度买的最值的东西: gunnar眼镜

续航能力提升不少, 缺点是, 要提醒自己起来动一动……

年度图书: Remote

重读

年度电影: 星际穿越

电影院看了三遍…..

年度游戏: 纪念碑谷

我火星了?……

年度音乐: Lui Si Chiama

下了黄山, 在梅雨纷纷赶往南京路上, 电台推过来的, 循环了一路, 然后回来找不到(听不懂加不记歌名的后果), 找个半个月, 终于电台又给我推了一次, 感谢虾米……

2014年度计划盘点

学习一门新语言. 学习javascript, golang和ruby,js的话上半年工作需要去学的, 写了一个统计后台组件, golang, 写了一个完整的项目, ruby, 仅学习了下范式, 挖坑新项目中.
k-vim, 完成一个版本. 两个大版本, 目前version8.0, star 1100+, 并衍生的一个服务器版本vim-for-server. suggestion完成golang版本重构及上线, stackoverflow-py-top-qa翻译计划一直停滞, 还剩40个问题. 其他还有几个坑慢慢走, 感觉一直不务正业……
博客, 目标是50篇, 最终完成了40篇, 还好
读书, 目标是50本, 最终完成70的样子, 超额完成任务
旅行, 去一个地方. 去了, 走了十三天, 想明白了一些东西
回趟学校. 回了, 景依旧, 人不在
做几个满意的项目. 今年连续写了几个项目, 一般般, 没有什么特别满意的东西, 开始挖坑新的独立项目.

ps. 今年在自己blog和相关项目放了buy me a coffee的donation链接, 收到了不少朋友的donation, 非常感谢:)

2015新的计划

读完APUE/各种源码等
例行: 学习一门新语言, haskell/lisp(一年一门系列).
重要:把一些该做的事情做了, 不再逃避(******)
例行: keep reading * 30, 只读经典.
例行: 旅行, 似乎该去大西北了

2014, 是变化和积累的一年

2015, 我希望是大后期的输出一年:)

so. 把该搞定的事情都搞定了

放开, 往前奔跑, 前方如何, 暂时不管了

Python-基础-时间日期处理小结

Tue, 03 Mar 2015 08:00:00 +0800

好久没写文了, 继续清理笔记, 都是一些小结之类的, 源码分析以及在做系统中一些细节难点等, 后续逐步发

另外打个广告, 甜品礼物, 坐标深圳, 有兴趣的同学可以给我发邮件, 非python职位会转到对应同事:)

      _       _       _   _
     | |     | |     | | (_)
   __| | __ _| |_ ___| |_ _ _ __ ___   ___
  / _` |/ _` | __/ _ \ __| | '_ ` _ \ / _ \
 | (_| | (_| | ||  __/ |_| | | | | | |  __/
  \__,_|\__,_|\__\___|\__|_|_| |_| |_|\___|

原则, 以datetime为中心, 起点或中转, 转化为目标对象, 涵盖了大多数业务场景中需要的日期转换处理

步骤:

1. 掌握几种对象及其关系
2. 了解每类对象的基本操作方法
3. 通过转化关系转化

涉及对象

1. datetime

>>> import datetime
>>> now = datetime.datetime.now()
>>> now
datetime.datetime(2015, 1, 12, 23, 9, 12, 946118)
>>> type(now)
<type 'datetime.datetime'>

2. timestamp

>>> import time
>>> time.time()
1421075455.568243

3. time tuple

>>> import time
>>> time.localtime()
time.struct_time(tm_year=2015, tm_mon=1, tm_mday=12, tm_hour=23, tm_min=10, tm_sec=30, tm_wday=0, tm_yday=12, tm_isdst=0)

4. string

>>> import datetime
>>> datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
'2015-01-12 23:13:08'

5. date

>>> import datetime
>>> datetime.datetime.now().date()
datetime.date(2015, 1, 12)

datetime基本操作

1. 获取当前datetime

>>> import datetime
>>> datetime.datetime.now()
datetime.datetime(2015, 1, 12, 23, 26, 24, 475680)

2. 获取当天date

>>> datetime.date.today()
datetime.date(2015, 1, 12)

3. 获取明天/前N天

明天

>>> datetime.date.today() + datetime.timedelta(days=1)
datetime.date(2015, 1, 13)

三天前

>>> datetime.datetime.now()
datetime.datetime(2015, 1, 12, 23, 38, 55, 492226)
>>> datetime.datetime.now() - datetime.timedelta(days=3)
datetime.datetime(2015, 1, 9, 23, 38, 57, 59363)

4. 获取当天开始和结束时间(00:00:00 23:59:59)

>>> datetime.datetime.combine(datetime.date.today(), datetime.time.min)
datetime.datetime(2015, 1, 12, 0, 0)
>>> datetime.datetime.combine(datetime.date.today(), datetime.time.max)
datetime.datetime(2015, 1, 12, 23, 59, 59, 999999)

5. 获取两个datetime的时间差

>>> (datetime.datetime(2015,1,13,12,0,0) - datetime.datetime.now()).total_seconds()
44747.768075

6. 获取本周/本月/上月最后一天

本周

>>> today = datetime.date.today()
>>> today
datetime.date(2015, 1, 12)
>>> sunday = today + datetime.timedelta(6 - today.weekday())
>>> sunday
datetime.date(2015, 1, 18)

本月

>>> import calendar
>>> today = datetime.date.today()
>>> _, last_day_num = calendar.monthrange(today.year, today.month)
>>> last_day = datetime.date(today.year, today.month, last_day_num)
>>> last_day
datetime.date(2015, 1, 31)

获取上个月的最后一天(可能跨年)

>>> import datetime
>>> today = datetime.date.today()
>>> first = datetime.date(day=1, month=today.month, year=today.year)
>>> lastMonth = first - datetime.timedelta(days=1)

关系转换

几个关系之间的转化

Datetime Object / String / timestamp / time tuple

关系转换例子

datetime <=> string

datetime -> string

>>> import datetime
>>> datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
'2015-01-12 23:13:08'

string -> datetime

>>> import datetime
>>> datetime.datetime.strptime("2014-12-31 18:20:10", "%Y-%m-%d %H:%M:%S")
datetime.datetime(2014, 12, 31, 18, 20, 10)

datetime <=> timetuple

datetime -> timetuple

>>> import datetime
>>> datetime.datetime.now().timetuple()
time.struct_time(tm_year=2015, tm_mon=1, tm_mday=12, tm_hour=23, tm_min=17, tm_sec=59, tm_wday=0, tm_yday=12, tm_isdst=-1)

timetuple -> datetime

timetuple => timestamp => datetime [看后面datetime<=>timestamp]

datetime <=> date

datetime -> date

>>> import datetime
>>> datetime.datetime.now().date()
datetime.date(2015, 1, 12)

date -> datetime

>>> datetime.date.today()
datetime.date(2015, 1, 12)
>>> today = datetime.date.today()
>>> datetime.datetime.combine(today, datetime.time())
datetime.datetime(2015, 1, 12, 0, 0)
>>> datetime.datetime.combine(today, datetime.time.min)
datetime.datetime(2015, 1, 12, 0, 0)

datetime <=> timestamp

datetime -> timestamp

>>> now = datetime.datetime.now()
>>> timestamp = time.mktime(now.timetuple())
>>> timestamp
1421077403.0

timestamp -> datetime

>>> datetime.datetime.fromtimestamp(1421077403.0)
datetime.datetime(2015, 1, 12, 23, 43, 23)

Linux及Bash笔记

Sat, 17 Jan 2015 08:00:00 +0800

第一次接触, 在大学时期, 但是真正去学习和了解, 大概是在刚毕业那年

到现在, 三年多, 主后端开发, 工具也就是一个command line加vim, 每天开个终端就开始噼里啪啦干活, 兼职一些简单的部署运维工作

去年, 是变化和积累的一年, 今年, 希望有些产出

Linux和bash, 记了很多笔记, 逐一梳理出来

之前的两篇文章 LINUX SHELL脚本攻略笔记以及如何书写SHELL脚本

也会一并汇总, 这可能是今年唯一产出的一本笔记了, python源码阅读和python基础笔记, 这两个在本地的gitbook上, 工程量太浩大, 后面以博文的形式慢慢发吧:)

好了, 放到github上了, 当前10%的样子, 欢迎 star以及提pr, 纠正以及丰富之

地址: https://github.com/wklken/linux-notes

先这样……后面开始专注码业余项目去了, 博文产出估计会少点, 当然也不会太少

2015-01-17

wklken

一些nginx配置

Thu, 01 Jan 2015 08:00:00 +0800

nginx配置

开年第一篇, 梳理笔记本中….

没啥, 一些用到以及后面可能用到的nginx配置, 记录一下, 备查备用

ps. 之前一篇 nginx基础笔记

使用独立目录, 然后include具体配置

nginx.conf
site/
    a.conf
    b.conf

nginx.conf

http {

    .......
    include /etc/nginx/conf.d/*.conf;
    include sites/*.conf;
}

gzip on

加到http模块中, 开启gzip, 注意gzip_types配置得是压缩的资源类型

nginx.conf

http {


    .....


    gzip on;
    gzip_min_length 1k;
    gzip_comp_level 5;
    gzip_proxied expired no-cache no-store private auth;
    gzip_types text/plain text/css application/javascript text/javascript application/x-javascript text/xml application/xml application/xml+rss application/json image/x-icon image/png image/jpg image/jpeg application/font-woff;
    gzip_vary on;
}

for multi processers

nginx.conf

worker_processes  4;
events {
    worker_connections  2048;
    use epoll;
    multi_accept on;
}

worker_rlimit_nofile 100000;

static file cache

    location ~* \.(?:css|js)$ {
      expires 12h;
      access_log off;
      add_header Cache-Control "public";
      proxy_pass http://127.0.0.1:5000;
      proxy_redirect off;
    }

proxy pass

    location /
    {
        proxy_pass http://127.0.0.1:8000;
        proxy_pass_header Server;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Scheme $scheme;
        proxy_set_header Host $http_host;
        proxy_redirect off;
    }

可以设置超时时间

        proxy_connect_timeout 500s;
        proxy_read_timeout 500s;
        proxy_send_timeout 500s;

静态目录 or 文件

    location /movies/ {
        alias /Volumes/Media/Movies/;
        allow all;
    }

    location = /abc.txt {
        alias /data/www/static/abc.txt;
        expires  30d;
        access_log off;
    }

静态站

server {
    listen       192.168.1.1:80;
    server_name  www.abc.com;

    client_max_body_size 1M;
    access_log logs/blog_access.log;
    error_log logs/blog_error.log;

    root /data/static_site_dir;
    index index.html;

}

服务转发

将收到的服务url/参数等, 原封不动转给另一个服务

server {
    listen 80;
    server_name  www.xxxx.com;
    location ~ ^/(.*)$ {
        proxy_pass http://192.168.1.1:80/another/service/$1$is_args$args;
        proxy_read_timeout 90;
    }
}

return

直接return

语法

return http_code;
return http_code "content";

e.g.

location /api/test/ {
    return 403;
}

location /stat/ {
    return 204;
}

location /ping/ {
    return 200;
}

for mobile

移动端和网站端互相跳转

    location = / {
        try_files $uri @mobile_rewrite;
    }

    location ~ ^/(login|register|search|album|404|album/\d+|item/\d+|topic)$ {
        try_files $uri @mobile_rewrite;
    }


    location @mobile_rewrite {

        if ($http_user_agent ~* "(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows (ce|phone)|xda|xiino") {
            set $mobile_rewrite perform;
        }
        if ($http_user_agent ~* "^(1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas\-|your|zeto|zte\-)") {
            set $mobile_rewrite perform;
        }

        if ($arg_mobile = 'no') {
            set $mobile_rewrite do_not_perform;
        }

        if ($arg_mobile = 'yes') {
            set $mobile_rewrite perform;
        }

        if ($mobile_rewrite = perform) {
            rewrite ^ http://$server_name/m$request_uri permanent;
            break;
        }

        proxy_pass http://127.0.0.1:5000;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_redirect off;

    }


    location /m/
    {

        set $pc_rewrite 1;
        if ($http_user_agent ~* "(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows (ce|phone)|xda|xiino") {
            set $pc_rewrite 0;
        }
        if ($http_user_agent ~* "^(1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas\-|your|zeto|zte\-)") {
            set $pc_rewrite 0;
        }
        if ($pc_rewrite = 1) {
            rewrite ^/m/(.*)$ http://$server_name/$1 permanent;
        }

        proxy_pass http://127.0.0.1:5000;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_redirect off;
    }

redirect to www

server {
    server_name  abc.com;
    rewrite ^(.*) http://www.abc.com$1 permanent;
}

allow and deny

访问ip控制


location /test/ {
    allow 192.168.1.1;
    deny all;

}

负载均衡

nginx.conf

http {

    upstream A {
        server 192.168.1.1:5000;
        server 192.168.1.2:5000;
    }
}

sites/a.conf

server {

    location / {
        proxy_pass A;
    }

}

其他

centos service cmds

检查配置文件正确性
service nginx configtest


重新加载配置
service nginx reload

重读<<你的灯亮着吗? >>

Sat, 06 Dec 2014 08:00:00 +0800

书今年到是读了不少, 50本的目标目测已然超标了:), 发现今年的博客目标还差11篇(50篇), 目测完不成指标了, 随性写写吧, 能写几篇是几篇

这本书是原先团队老大推荐的, 看过一遍, 后来自己入了一本, 今天重读(发现我越来越喜欢这类很薄的树)

做事情本质上就是遇到问题，分析问题，解决问题的过程。而对如何解决问题本身，这本书做了一些讨论

三点：

1. 问题是什么（期望和体验）
2. 谁的问题（不同人会有不同的解决方式，责任）
3. 问题来源

得到了一些原则性的结论，每一点仔细思考分析.

记得当时总结过一句话: 当”问题”成为问题时, 才是问题.

值得反复阅读, 以下更多的是做一些摘录

第一部分: 问题是什么?

这是什么类型的问题? 谁碰到了问题? 问题是什么? 或者说, 此时此刻, 问题的本质是什么?

谁碰到了问题? 问题的本质是什么?

谁的问题? 如果没有负责人, 那将永远得不到解决. 具体到了细节, 责任人负责并弄清楚. 分配到人

问题就是理想状态和现实状态之间的差别

调整理想状态或者改变现实状态.

期望和结果, 你能做的, 降低期望, 或者去改变结果.

“忽略问题”是一种古老但有效的方法(降低敏感度, 降低期望)

我们永远不知道问题是什么, 直到我们彻底解决了拜托了这些问题

别去费力榜缺乏幽默感的人解决问题

第二部分: 这次的问题是什么?

不要把别人的解决方法作为定义问题的方法

你的最终目的是什么? 你的问题本质是什么. focus在问题本身, 而不是问题的解决方法上, 错误地将解决方法作为你的问题.

别把问题的解决方案误当做问题的定义, 当这个解决方案是由你提出的时候尤其如此

如果你解决问题太过神速, 别人根本不会相信你真的解决了问题.

头疼…..

面对有利可图的问题时, 道德考量很可能就烟消云散了

即使问题已经解决, 你也无法确定你的问题定义是正确的.

你永远无法确定已经找到的问题定义是正确的, 但是永远不要停下寻找正确定义的脚步

不要仓促下结论, 但也不要忽视第一印象

第三部分: 问题到底是什么?

每一个解决方案都是下一个问题的来源

修复一个bug可能引起另外一个bug

某些问题最困难的部分就在于发现问题的存在

你已经麻木了, 无法站在新的视角对事情进行评估, 确定是否有问题存在

问题和习惯，一旦我们习惯了某些东西，就会对某些问题视而不见，改变习惯是非常困难的事情，每做一件事情的时候，都有必要问下自己，有必要真么做么？事不过三，每次改善一点点，都能节约出很多时间和精力，放在重要的事情

看看你对问题的理解, 如果想不出至少三个可能有出错的地方, 你就没有真正理解这个问题

问题的关键就是在于首先要意识到问题的存在, 或者让设计者意识到有问题存在

吃自己的狗粮

大多数不协调之处一经发现很容易解决

借助外国人/盲人/儿童来检验你给出的定义, 或者让自己设身处地地站到外国人/盲人/儿童的角度来检验…….每转换一次视角, 都会发现新的不协调之处

切换角度看问题, 发现不协调

如果想得到不同的解决方案, 该怎样变换问题的表述方式?……一旦你将一个问题描述拟成了文字, 做些文字游戏, 以确保每个人对问题的理解可以统一.

首先, 语义层面, 问问题的方式, 都可能带有偏向或误导, 如何客观地阐述问题?

当你沿着定义问题的道路疲倦前行时, 过一会就要回头看看, 确定字节没有走错路

第四部分: 问题该由谁解决?

当别人可以妥善解决自己的问题是, 不要越俎代庖

特别是leader….

如果这是别人的问题, 就把它当成是别人的问题

如果一个人处于解决问题的位置, 却并不受问题困扰, 那就采取一些行动使他能亲身体验到问题.

你的灯亮着么?

如何让别人意识到问题?

第五部分: 问题来自哪里?

人们觉得无力解决问题, 常常把问题归因为天性, 以逃避解决问题的责任.

大多数情况下, 问题的根源在你自己身上.

记住这一点, 我们往往不承认这一点, 但这是无可辩驳的事实.

世界上有两种人, 一种人做事, 另一种人制造出事来让其他人做. 远离那些找事让别人做的人, 你就能好好过日子了.

世界上有两种人, 一种人做事, 另一种人领赏, 做第一种人吧, 那里的争斗比较少.

第六部分: 你真的想解决问题么?

大多数情况下, 只要知道问题是什么, 解决问题就是一件非常不值一提的事情.

无论表面上如何, 在你提供他们所要求的东西之前, 他们极少知道自己想要什么.

从最后的情况看, 想要真正解决问题的人并不是很多.

人们永远没有足够的时间把它做好, 但永远有足够的时间重新来过.

人们永远没有足够的时间去考虑到底是不是想要它, 但永远有足够的时间去为之后悔

鱼, 总是最后一个看到水的.

当局者迷.

重读<<番茄时间工作法>>

Sun, 30 Nov 2014 08:00:00 +0800

最近在执行重读计划, 为年后搬家做准备, 一些书读完珍藏/出给需要的人, 减少搬家那一柜子书的困扰….

重新读了下这本书, 写写

大概去年的这个时候, 写了篇拖拉一点也无妨的读书笔记, 需要的可以看下

番茄时间工作法, 意在让人们驻足/观察/醒悟, 并在此过程中改进自我

人们往往容易关注未来, 而不是过去, 匆匆忙忙, 只为了尽快达到目标, 却忽视了对整个过程的review, 停留, 观察, 总结, 改进, 然后再前进, 更快更好地前进.

编程中有一种学习方式叫做刻意练习, 而在«一万小时天才理论>>中提到精深练习, 要慢, 要去犯错, 要去实际体悟, 要总结.

GTD 里也有review的环节.

总之, review很重要, 但常常被忽略(例如说我…)

要完成大量工作, 重点不在完成工作上, 而在于能否集中注意力

很赞同, 打断是效率杀手.

如果一天打断太多, 加上会太多, 很可能意味着晚上要花时间补回这段时间. That is not cool!

要想做到专注, 你就得坚决抛开各种杂念

什么是番茄工作法? 简单来说, 就是列出你当天要做的事, 设置25分钟闹钟, 然后从第一件事开始.

很简单的做法, 但是实践两年多, 感觉行之有效. 而自己的番茄钟, 也根据任务性质长短不一, 从10分钟到1小时不等, 特别是半夜码代码写东西根本停不下来.

而对于我这种比较懒散的人来说, 最简单的方式才是最好的方式, 例如每个番茄钟的休息时间, 只要自己感觉精力ok, 可以进入下一步, 就开始. 如果感觉一定要继续下去, 那么继续. 灵活运用, 不要僵化了(但是最开始的时候应该对自己严格些).

同样, 你没有必要买一个番茄钟(我就买了一个…现在放厨房里落灰, 原因是滴答滴答的声音太干扰了), 手机/网页/软件, 你可以发现各类好用的东西, 主旨: 能在适时通知你, 不干扰你的工作和思路, 能记录. (我用的是Vitamin-R 2)

每隔一段时间, 回顾下所有步骤, 看看有没有需要简化或干脆去掉的步骤.

我是伪GTD爱好者, 从狂热到降温, 使用一个个工具, 最终确定了things这个工具(足够轻). 而GTD步骤, 也被简化到了适合我工作场景的情况.

不要僵化于步骤, 不要狂热于工具, 关注自己, 关注做事, 工具神马的, 够轻够用就好, 适合自己的才是最好的.

一次只做一件事

人是并行动物, 但不意味着你可以同时干几件事.

同时并行干几件事, 代价太大, 先不说最坏的情况是都干砸了, 最好的都干成了, 但是你也把自己搞得筋疲力尽.

不断的中断, 上下文切换, 最终导致了cpu过载……

一次只做一件事, 集中精力, 高效搞定, 然后下一件.

或者, 你可以将想法挂起后台, 到了你真正去做的时候, 想法已经进化并成熟了很多.(亲测有效)

so, 不要在一边....一边...., 或许看起来很忙很努力, 就像«Rewrok>>中提到的工作狂, 这是很愚蠢的事情.(能多线doing的天才除外啊)

为什么要用番茄工作法

面对复杂, 望而却步
无聊琐事, 越拖越久
小事忙活一天, 大事一件没办
最后期限, 步步紧逼
从休息回到工作, 心智调整不过来
一错再错, 不长记性
没想到一件事要做这么久
没想到一件事越做越复杂
头脑被各种想法占据
时间都用来学习适应复杂的工作方法了
只顾低头干活, 忘了抬头看路
把预估当做承诺
牵着不走, 打着倒退
完美主义, 碍手碍脚
前怕狼后怕虎, 害怕失败和批评

通过执行一套相同的动作和准备程序, 可以使大脑自我调整, 进入执行某类事务的最佳状态

有点迷信的感觉. 但是, 其实目的仅仅是像书里说的, 通知大脑, 我要开始做什么了, 准备好.

另一个我觉得, 是为了防止中断, 例如开工前去倒好水, 调整好电脑, IM和邮件通知关掉等等,

短暂的定期休息, 能够促进融会贯通的能力.

It works.

每隔25分钟, 常规休息, 4个番茄钟后进行15~30分钟阶段休息

“心流”

一种精神状态, 创造性的状态.

明确的目标, 集中, 专注, 自我意识消失, 时间感扭曲, 直接和即时反馈, 能力水平与面对挑战的平衡, 个人控制感, 工作本身的内在奖励, 行为与认知的合一.

在那种状态下, 效率奇高, 你感觉自己无所不能, 集中专注, 自我意识消失(你不会意识到自己在这种状态下)

虽然书中提到节奏一说, 要定时从心流中跳出规划全局再进入, 但我更倾向于多进入这种状态, 尽可能长地维持, 因为要进入心流状态, 是很困难的. 如何快速进入也是需要逐渐训练的.

在短时间内对工作方法做反复调整

小步快跑, 调整得到正确的姿势—论如何优雅地工作

番茄时间工作法的阶段

计划: 从inbox里, 得到一张今日待办的清单(当天的自我承诺)
跟踪: 开始番茄钟后, 收集一些过程指标, 比如中断次数
记录: 一天结束时, 将跟踪数据记录归档
处理: 对跟踪数据进行分析思考, 得到一些特征和规律
可视化: 将信息组织起来, 找出改进流程的思路

以上是每天要进行的, 个人感觉太重了, 而且重心在改进, 而不再do.

前期还没有形成自己节奏的时候, 适用, 中后期, 应该将重心放在do上, 轻化计划和跟踪.

处理外部中断

如果是别人的问题, 进行分派.

如果是我的问题

邮件/IM过来的, 可视为不紧急, 完成番茄钟后处理
电话, 一两分钟能done的, 做掉. 不能, 确认紧急程度, 不紧急, 给承诺, add to TODO list, back to work. 紧急的, 到4
当面, 同2, 确认对方最晚可接受的时间, 如果不紧急, 承诺, 结束对话
紧急, 给当前工作打断点, 注释或纸笔, 写下当前状态思路, 然后去做紧急的事情.

书中提到的处理策略: 告知(dong something)-协商(when)-计划(todo list)-答复(done)

怎么区分紧急, 需要慢慢去学习.

邮件的处理

如果答复时间不超过1分钟, 立即答复

如果需要分派, 分派

如果可以委托他人, 委托

如果需要我处理, 不紧急, 回复处理时间, 记todo list

如果需要我处理, 紧急?(紧急的事情会用邮件? 一般是伪紧急)

过度学习

达到熟练程度后, 继续学习或者练习的行为.

持续改善

一种工作方法, 以改进为目标, 对渐进变化的专注.

事前预估与时间所花工夫之间经常不一致

做预估的方法或能力有待改进
工作开始后, 又出现新情况, 新问题, 使得环境发生改变.

最后

很多时候, 我们的工作倾向于无序的, 如何将有限的时间分配到无限的工作中, 需要一些技巧, 并且辅助以工具, 不要神化技巧, 也不要狂热于工具, 最重要的是人本身, 是完成事情本身, 学习一些方法(番茄/GTD), 应用, 思考, 改进, 这就够了:)

关于代码调试de那些事

Sun, 23 Nov 2014 08:00:00 +0800

写代码最完美的就是, 想清楚, 码, 运行, perfect, DONE, 下班.

当然, 那是完美的状态. 大多数时候只存在于理想中.

现实是, 我们会被各种坑, 被环境坑, 被语言坑, 被依赖坑, 被第三方库坑, 被编辑器坑, 被自己坑(三个月前的自己/昨天的自己/几分钟前的自己), 被数据库坑, 被缓存坑, 被队友坑(这个比较惨), 被需求变更坑(这个也是)……

所以, 总是避免不了代码调试.

今天顺带过了下«想计算机科学家一样思考Python>>, 里面每一章最后都有关于调试的一些观点, 例如阅读 - 深思 - 修改/运行/回退, 所以决定来写写关于代码调试的一些东西.

其实, 代码调试是论如何排查问题的一个过程, 根据一切蛛丝马迹, 推断出问题所在, 并消灭之.(破案的即视感)

下面是一些关于一些自己在写代码和调试的总结

1.你得明白你在做什么, 保持清醒

代码调试有时候会让你陷入无尽的自我怀疑/迷茫/愤怒/沮丧/窘迫/挫败(无限负能量), 很容易被这些情绪左右, 不清醒, 陷入怀疑自我(一定是我调用的方式不对), 或者怀疑一切(一定是数据库问题, 不对, 缓存问题, 不对, 接口问题, 好像不对, 数据问题), 或者胡乱改代码(改-跑-错了-再改-跑-又错-再改, 传说中的随机行走编程), 或者……(挣扎吧……)

此刻, 保持清醒的自我是非常重要的, 要明确: 我在做什么, 问题是什么症状, 原来逻辑是什么, 最有可能出问题的是哪里?

2.想清楚了再写代码

如果连需求是什么, 想要做什么都没整明白, 就吭哧吭哧开写, 意图在实践中摸索通向胜利的道路, 是很愚蠢的行为.

需要去理解需求, 自己要做什么, 然后, 在大脑中构造, 现在有什么, 为了完成需求需要做什么, 完成大体的组成结构/步骤流程的思考后, 再着手去做.

大到整体设计, 小到一个函数, 都可以这么处理

例如, 遇到复杂问题, 可以先写注释, 完整所有函数整体设计, 然后再填充细节

def dosomething():
		“””
		“””
		# step1: call func test()

		# step2: parse url to 

		# step3: judge

		# step4: convert and return

3.关于`脚手架`代码

在逻辑的关键位置, print/assert关键信息, 用于在调试中迅速确认问题. (一些中间值/状态/条件判断结果)

当然, 信息除了关键这个特性, 还需要足够丰富和显眼, 一遍一次性定位问题. (既要好看又要有用)

你需要确定下如何用顺手的编辑器快速输入这些代码, 可以用各类语言的snippets

例如, 在写python时候, 我很喜欢prt(k-vim自动补全), 快速插入一些需要的信息

print "TRACK ================= result", type(result), result, result == "test"

4.写完一段代码第一时间自己review一下

事实证明, review的效果比写完直接跑再来调, 效率高多了.

刚写完一段代码, 思路还很清晰, 跳到开始, review过程中注意各类变量, 条件判断, 函数调用, 上下文, 一致性, 错误处理等, 花不了多少时间, 却能发现一些显而易见的问题, 省下很多无谓的调试时间(没问题不需要调试!).

5.review中注意, 代码是`抠`过来的么?

很多时候从其他地方copy代码过来(一行或几行, 有时候只是一个函数调用或一个判断), 但是很容易忘了根据当前情况修改一些必要的值, 导致问题

例如函数调用, 这个地方调用参数可能跟你copy这行代码需要参数不一样, 但是放在这里并不会报错(一切运作正常), 最终结果并不对…..

好了, 开始调试

6.搞明白问题的表现是什么(症状)

运行代码, 报错了, 有些人会瞬切回编辑器, 开始改代码(作高效状)……>_<#

问题是: 报错提示你看了么, 看明白了么?

现在大部分语言, 其报错提示已经很明显了, 精确到行/变量, 虽然整个异常栈信息可能很长(非常长), 但是都有其特征(在最前或在最后,或在中间靠后, 有关键字), 仔细看下报错信息, 精确制导才是王道.

所以, 你需要从错误信息中先确认

错误类型
发生错误的地方

很多语法问题可以根据这个信息直接定位

7.调试过程中, 需要时刻注意

改的是不是正确的目录下正确的文件?(大坑)

保存了么(编译了么)?(又一个坑)

服务重启了么?

跟数据库有没有关系/跟缓存有没有关系, 要不要清?

……

以上问题, 随便碰上一个你都可能发现, 自己书写的代码和当前运行来调试的代码不一样.(会浪费你巨量的时间)

自己调试半天怎么还是一样的结果

我一直在修改, 但是没有什么区别(出现这种情况要自问一下了)

可以显示在代码头部打印或者故意出错, 确认是同一套代码

8.环境/数据一致性

当你发现在本地无法复现别人报过来的问题(在我电脑上是正常的), 这时候, 需要考虑是否是环境和数据的问题.

9.先不要动代码, 假设代码是正确的

遇到问题, 不要急着修改代码, 需要假设, 代码是正确的, 然后去复现, 复现之后定位.

10.首先要怀疑自己

你不能一旦代码跑不动就怀疑是别人的问题, 然后抛给别人, 这样做同样是很不负责任而且很愚蠢的.

首先, 你需要怀疑自己, 排查问题, 当确定不是自己的问题之后, 将问题定位, 输入, 预期结果, 现在的异常结果都处理好, 生成一个问题, 抛给对应负责人. (一切没有价值的怀疑都是无意义的)

程序员都是好人, 每次都在想: 一定是我的问题

11.对于莫名其妙的问题, 多试几种情况

有时候碰上一些诡异的问题, 例如有一种情况的输入会报错, 这时候, 再跳过去修改代码前, 可以多尝试几种输入, 涉及边界/异常/正常等情况, 排除法, 精确制导.

例如, 可以变换输入值的范围(扩大或缩小, 可能用二分法), 变换输入类型和格式

12.先回到`正确的代码`

如果这段代码是由于修改导致的, 可以注掉此次变更代码, 同样的输入再次验证定位

13.如果一段代码是`没动过`的代码

如果你确保确实没动过, 此时, 先不要怀疑自己, 更大的可能是别人的问题.

可能情况: 依赖出了问题(调用函数返回数据不对/异常? 依赖请求挂了? ……), 数据出了问题(表结构变更/服务返回数据变更), 环境问题(数据库/缓存)

14.bug总是倾向于集中出现在一起

很多时候, bug是扎堆的, 可以回忆下之前修改的地方, 确认问题.

15.对于很长很长, 上`二分法`

可能函数很长, 或者调用链很长, 不易调试.(光打调试信息就得打得手疼)

找到关键变量, 上二分法, 无上利器.

16.print or debug?

个人偏好简单粗暴的print, 主要是用的vim+sinppet, 快速高效.

当然, 如果用IDE, 用 debug 吧

17.十分十分诡异的问题

上debug, 打断点, 一点点调试吧, 只能这样了.

18.当一个问题超过半小时

歇一歇, 走动走动, 打个水, 呼吸下新鲜空气.

这时候有利于脱出情境, 去掉挫败感/愤怒/迷信等

很多时候突然灵感一到, 瞬间明了(这种感觉很奇妙)

19.关于google

有些错误信息, 如果觉得比较独特诡异, 可以google下, 你会找到更多的一些信息的.

20.关于求助

实在搞不定, google大神也搞不定, 此时可能需要求助了.

前提, 你自己能把问题想清楚, 并且逻辑清晰地描述出来.(什么业务什么位置的什么逻辑, 报错类型和报错信息, 输入输出, 迄今做了哪些尝试等等) 要学会聪明地问问题, 高效, 尊重自己也尊重别人.

如果你自己都没整明白怎么问, 别人也无能为力.

遇到很多人, 直接上来就一句xxx出问题了, 没有前置条件后置结果中间症状……

不过, 如果你会聪明地问, 那就放心大胆地问吧, 不用磨磨唧唧的, 程序员大都是善良的孩子.

21.吃一堑长一智

被坑了就要总结总结, 有个记录, 不被同一个问题坑两次.

如果被坑了就忘, 还需要去反复求助, 那这属于坑队友的行为(鄙视下)

好了, 就这些:)

基于 PostgreSQL 的数据统计系统

Sun, 16 Nov 2014 20:58:00 +0800

看到标题就知道我要写什么了, 这是之前一个项目的小结吧, 自己对统计的一些认识和看法.

当时从前到后, 包括技术选型, 花了接近一个月的时间, 也在生产上用了两三个月, 一致在持续维护, 做完图表配置化已然接近完工, 无奈后来离开了, 不过目前应该还在运转

至于源代码, 暂时不考虑开源, 太渣(其中在看了几天js情况下, 自己撸了1000行js的前端框架, 质量堪忧), 全套用python实现.

提供一种快速实现运营统计需求的思路.

(图为百度 echarts 示例)

一. 场景

统计

所谓统计, 抽象出来就是计数而已(还有各个计数之间的算术运算). 再具体一些, 根据不同维度进行计数.

而统计后台, 无外乎数据的输入, 处理, 及输出.

对于实时性, 一般会以天为单位进行统计.

而在具体业务场景下, 需要计数的数据来源于各个项目和同一个项目的不同机器(分布式部署), 就需要考虑, 如何将日志进行汇聚, 如何更为便捷地进行处理, 存储, 以及展现.

其中要考虑, 需求是不断在变化的, 如何将成本降到最低?

以往的统计方式:

分析统计需求 -> 修改项目记录日志内容和格式(到磁盘) -> 自行将日志汇总到一台机器(rsync) -> crontab脚本分析日志(要删或备份历史数据) -> 新建db表, 存储统计结果 -> 写管理后台, 查询统计结果(最繁琐) -> 处理分页/图表等

虽然每次耗时或许并不会太长(0.5-2d, 视需求大小), 但对于不同项目和需求变更, 这些工作都是纯体力毫无技术含量的枯燥工作, 可以说是无意义的资源浪费.

新的方式

分析统计需求 -> 确认日志内容和格式  -> 统计后台配置输入/处理/输出逻辑 -> 查看结果

说白了就是, 处理统计需求变成了 写sql + 配置

二. 处理思路

大体思路如下(从后往前):

1. 将日志进行汇总
2. 日志格式一致化
3. 将日志导入到一个容器中
4. 便捷地通过容器进行计算(计数)
5. 统计结果进行统一存储
6. 提供统一的查询接口
7. 提供前端框架组件, 可以通过配置调用统一查询接口, 并对数据进行分页及图表化
8. 提供配置入口, 可以配置日志入口, 处理逻辑, 展现逻辑. 即完全地配置化

需要统一的地方:

日志格式
容器存储
报告存储
查询接口
前端组件

系统成型后

增加/修改统计需求: 只需要在后台配置数据来源(日志), 处理逻辑(一段 sql), 展示逻辑(一段前端 json配置), 就可以实现图标

三. 具体

0. 基本架构


             ----------------------------------------------
            |      日志(UniteStats or ApplicationLogs)     |
             ----------------------------------------------
                              ||
                 ---------------------------
                |        load处理程序        |
                 ---------------------------
                              ||
                ___________________________
               |存储容器--计算容器           |
               |                          |
               |  Container(Postgresql)   |   //json - sql - 聚集函数
               |                          |
               |___________________________
                             ||
            --------------------------------------
           |        [自定义统计脚本-查询逻辑及报告表]  |
            --------------------------------------
                             ||
            ---------------------------------------
           |            统计报告                    |
            ---------------------------------------
                            ||
            ---------------------------------------
           |            统一查询接口                |
            ---------------------------------------
                            ||
             ------------------------------------
            |      [自定义前端-使用统一库-配置生成]   |
             ------------------------------------

1. 日志格式

日志, 即文本.

但是文本存在各种格式, 例如常见的’\t’分隔的列, csv, json, xml等等.

这里的要求是: 一定要满足自描述, 易读(人), 易处理(生成和解析).

最终选择了json. 将原先无结构数据转成半结构化数据.

原因之一, 容器对半结构化的数据支持已经非常完善了, 例如postgresql, mongodb等, 对于后续计算很重要.

原因之二, 作为一个统一的平台, 我只在乎数据是一份日志, 但是不在乎, 日志里存了些什么, 每个字段的意义, 这些只有平台的使用者需要知道. 否则带来很大一个问题是, 对于使用者在新增或变更一份日志格式时, 需要明确告诉系统这份日志各个字段是什么(名称和类型), 复杂化了

到这里, 我们统一了日志的格式, 记录为json, 每条记录一行.

2. 日志收集汇总

目的: 将日志汇总到同一台机器上, 便于统一处理

命名规则: $THE_LOG_PATH/{projectName}/{projectName}_{moduleName}_{ip}_{yyMMdd}.log (示例)

日志汇总的方案有很多:

scp
rsync
nfs
logstash

最终的处理方案: 数据量小, 同一个机房, 使用NFS将日志汇总到目录, 不同机房, 使用rsync进行汇总. 如果数据量大, 可以考虑使用logstash, 直接将日志经过节点处理实时写到一台机器上(就不要分别记录到各自磁盘了).

扩展: 使用多台机器, 只要保证最终导入同一个库即可.(同一个项目, 同一天存在一张表, 不同机器的日志导入之)

到这里, 我们将所有json格式的日志汇集到了一起

3. 导入容器处理

目前每个项目的日志格式是,

{projectName}/{projectName}_{moduleName}_{ip}_{yyMMdd}.log

我们会将同一个项目, 可能来自不同机器的日志导入同一张表

{projectName}/{projectName}_{moduleName}_*_{yyMMdd}.log
=>
table: projectName_moduleName_yyMMdd

处理方式: 批量入库, 并且清理保留日期外的表

建议使用批量导入的方式, 速度杠杠的. Postgresql请使用copy命令

4. 容器

一个计算容器, 仅此而已

技术选型时, 考虑过Mysql/Mongdb/Redis/MariaDB/OrientDB/CouchDB/RethinkDB等等, 最终敲定使用postgresql, 无它, 对json的完美支持, 满足业务: 一定的数据量, 足够简单的统计方式, 足够稳定, 简单易运维等

提下redis, 当时做了整套的redis方案(接口文档都明确完了就差写代码了), 但是后来毙掉了. (典型的拿着锤子满世界都是钉子的案例). 思想是: 流式日志处理, 根据业务需求使用redis counter, 主从, 后台从redis直接取counter进行展示. 脑洞很大, 可以搞定实时/非实时情况, 还可以顺带把各类业务中的counter需求给做了, 以及更为灵活的展现方式, 但是学习成本较高, 对每个写统计的人要求较高(素质, 具备正确的统计思维, 否则会悲剧掉). 再加上业务本身要求实时性并不高, 所以废弃.

MySql 对 json 的支持, 相对于 postgresql 而言逊色太多了, 对json格式存在限制(多层复杂嵌套的情况)

Mongodb 虽然对json支持不错, 但是对于数据量较大的情况支持并不好, 并且查询以及运维都会带来一定困难, 对于使用者有一定学习成本

PostGresql作为容器的好处:

1. 支持的数据量
2. 查询简单，支持json, 所有sql查询，group by/order by/嵌套子查询，聚集等
3. 各种聚集、统计函数均可用，搞定基本统计查询无障碍（再复杂的都可以）
4. 运维简单
5. 对于开发而言几乎没有学习成本, 会sql再学习下postgresql的json查询

示例: 假设搜索日志:

{‘ip’: ‘127.0.0.1’,
 ‘keyword’: ‘test’,
 ‘result_count’: ‘1’,
}

统计 pv

select count(data->'ip') from search_20141101;

统计 uv

select count(DISTINCT data->>'ip') from search_20141101;

无结果数

select count(*) from search_20141101 where data->>'result_count' = '0';

搜索热词排行榜

select data->>’keyword’, count(*)
from search_20141101
where data->>'result_count' != '0'
group by data->>’keyword’
order by count(*) desc
limit 100;

5. 批处理

这里要做的事情, 需要有一个管理后台, 让开发可以配置上传自己的处理脚本, 设定脚本执行时间, 执行参数(处理日期/报告表名), 甚至是执行依赖.

这里需要形成一个约定

报告表名: projectName_statsModuleName
报告表一些字段名(因为统一查询接口需要用到): 日期 date,
其他约定字段

每天, 系统会扫描并调度任务, 执行, 处理得到统计结果, 存入报告表.

到这里, 我们每天的统计结果都存入到了报告表中

6. 输出

报告表, 是以时间为维度的, 每条记录带有日期, 每条记录细化到要统计到的精确维度.(具体表现是一个维度会多一列字段), 原则是, 需求分析时充分考虑当前及后续可能的统计需求(要预见还是蛮容易的), 直接将统计维度最细化.

当然, 如果无法最细化, 后面存在变更, 可以修改统计脚本, 根据情况对历史数据进行重新统计.

7. 统一查询层

一层通用的接口, 支持传入表名, 条件, 需要结果字段, 格式等, 可以对系统中各类报告表进行各种形式的查询, 获取统计结果.

8. 前端框架及展现

是一整套的js款干啊

分成几块

生成查询表单: 模块化组件, 通过json配置, 自动生成统计查询的表单, 支持各类维度

配置示例:

// 产生条件html
    var condition_configs = {
        title: "频道访问统计摘要",
        conditions: [
                {
                    type: "date_begin_to_end", //开始结束日期选择框
                },
                {
                    type: "select",   //下拉框
                    label: "频道",
                    id: "channel",
                    options: [
                        {
                            text: "所有",
                            value: "",
                        },
                        {
                            text: "快速访问",
                            value: "quickaccess",
                        },

                    ]
                },
                {
                    type: "version", //文档框
                },
        ]
    };

就会自动生成表单

begin_date:
end_date:
channel:
version:

组合查询条件: 表单提交时, 根据json配置, 将表单内容/字段/值/表等, 拼接成统一查询层接口需要的请求串
查询后数据处理: 将查询后的结果, 根据json配置, 进行转化和展现, 并图表化.

一个配置示例:

一般文本
{
    'column': 'date',
    'name': '日期',
    'type': 'text',
},

百分比 $后面跟的是sql查询结果列名
{
    'column': 'uninstall_ratio',
    'name': '卸载率',
    'type': 'ratio',
    'value': '$uninstall_pv/$install_pv'
},

公式计算
{
    'column': 'the_qvod_link_pv',
    'name': '导入链接数',
    'type': 'calculate',
    'value': '$qvod_link_pv + $qvod_start_pv'
},

列值翻译
{
    'column': 'channel',
    'name': '渠道',
    'type': 'text',
    'translation': {
        "all": "all",
        "player": "播放器",
        "zx": "资讯",
        "other": "其他导入",
    }
},

9. 图表

使用百度 echats

可以根据配置, 将统一查询层的接口返回数据直接灌入echats, 生成表单

10. 过程日志及监控

需要一组管理表, 进行任务配置/调度/执行/执行结果, 整个过程中的操作可以配置和查看, 用于监控.

四. 小结

It’s Simple, but it works.

数据情况, 当时大概每天 10G 日志 load 到库(处理前>10G), 每天日志数据大概是五千万条, 具体业务上了大概40个的样子, 每天30分钟左右处理完. 对于开发的改进是, 将原先0.5-2d的工作, 缩减到了1-2小时, 对生产力的提升较为显著.(对于日志数多且单一日志量较小的情况处理尤为便捷)

适用范围: 对于一般团队应该足够了(流量百万级别), 每个项目每天3-5百万访问量, 日志数据10-20G, 当然, 一直没机会测试上限, 不过只要PostGresql能抗住, 量再大些应该也ok.(可以考虑上elasticsearch)

以上思路, 仅供借鉴:) 就这样吧

简约之美 & 编写可读代码的艺术

Sun, 16 Nov 2014 08:00:00 +0800

最近陆续收到一些donation, 非常感谢哈, blog的文章说多不多说少不少, 大部分是笔记性质的, 主要目的还是积累以及方便自己查询回顾, 分享出来, 希望有所帮助:)

ps: 昨天将国内ip切到gitcafe了, 加载速度应该快了很多, 在此特别感谢下gitcafe. (关于如何国内国外切分访问, google大法)

今天要提的是«简约之美—软件设计之道>> 以及 «编写可读代码的艺术>>, 主要原因是, 经典, 更重要的是, 足够薄:), 建议买了珍藏, 也是属于那种不同时期反复读会有不同感受的书

———————————

简约之美

这本书, 用一百页来说明, 软件开发设计中, 一些十分简单的道理.

好的程序员和差的程序员的区别在于理解能力. 差劲的程序员不理解自己做的事情, 优秀的程序员则相反.

理解能力, 看起来蛮虚的一个词, 但是在工作中真正进行沟通时, 你会发现区别非常大, 决定了是一次沟通 还是 反复沟通; 是直达目标, 还是不断曲折; 是一次搞定, 还是改改改; 是反馈有效问题, 还是反馈不是你的问题的问题空耗你的时间. 所以花费时间去理解需求, 想明白之后再开始写代码, 这个很重要! (真正团队干活你会有直观感受的)

问题的根源通常在于编程……这一切都与复杂性有关……编程就成了把复杂问题化解为简单问题的劳动……”好程序员”应当竭尽全力, 把程序写得让其他程序员容易理解.

bug的本质, 归根结底在于编程本身.

我们往往容易把问题复杂化(大而全, 追求完美, 过早优化, 过早关注细节), 而过度复杂的后果导致后期代码的难以维护.(所谓的到时候再改/重构, 都是虚妄的), 程序员遇到一坨代码(别人写的或者之前写的), 有优化的冲动, 但是迫于需求或者时间或者系统稳定性, 往往惧怕变化, 这段代码能工作就行.

但是为什么要复杂化呢? 最简单的, 莫过于在最初就做到最好, 不要给自己到时候再重构的念头. 写好每行代码.

这里的其他程序员, 也可能是一个月后的自己. 如果经常发现回头看自己的代码都看不懂, 那么说明进步的余地还是很大的:).

到这里, 我们的目标转向: 寻找提高代码质量的科学方法.

每个写代码的人都是设计师

小到一个变量名, 一个判断逻辑, 大到一个函数, 一个类, 一个算法, 从代码里可以感受到很多东西. 拿建筑设计师对比, 写代码, 如同构筑一栋建筑, 不管是小屋/公寓还是摩天大厦, 好的设计永远美好, 而糟糕的设计, 无论大小, 永远丑陋. 很多概念, 意识和技巧在里面.(建议阅读编写可读代码的艺术, 然后是代码大全)

全部软件都有一个相同的目标: 帮助其他人……不能理解帮助其他人的程序员, 只能写出糟糕的程序, 也就是说, 他们的程序提供不了什么帮助……在做与软件有关的决策时, 指导法则就是判断能够提供什么样的帮助

同样, 这里的其他人, 可能是你自己.

需求的优先级, 取决于这个需求对于用户帮助的大小.

你这样做/这个功能/这么处理, 对于目标, 对于团队, 对于个人, 有何帮助? 如果没有, 为什么要这么做?

软件设计科学的目标: 1.确保软件能够提供尽可能多的帮助. 2.确保软件能够持续提供尽可能多的帮助 3.设计程序员能尽可能简单地开发和维护的软件系统. 才能实现1/2

1代表软件本身的价值, 2代表软件的可维护性可扩展性, 3代表, 好的/简单的设计, 决定了可维护性和可扩展性, 是万丈高楼的地基. 不过1和3, 在有限资源的情况下(资源永远是不够的), 是互相冲突的, 所以要思考如何保持平衡.

这里提到, 软件的开发和维护都应当简单, 要避免困难和复杂.

软件设计方程式可取程度=价值/成本 => 可行性=(当前价值+未来价值)/(实现成本+维护成本)

当前价值和实现成本往往是可评估的, 人们会关注于这一点, 带来的问题就是忽略了未来价值和维护成本, 这两个和时间相关, 不易评估, 但是却更为重要. 人很容易只着眼于现在而忽略了未来. 所以写代码时需要注意, 存在着未来.

相比降低实现成本, 降低维护成本更为重要. 很直观的感觉, 一个设计良好的接口, 在需求变更的时候, 只需要动个参数或者动几行代码或者压根不需要改. 而一个糟糕的设计里, 每次需求变更, 会发现需要改动很多代码, 甚至是重写, 连带测试等时间, 你会发现很多时间耗费在里面. 所以应该一开始就理解, 往未来看一眼(预测短期未来是可行的, 预测长期未来是不靠谱的), 再进行设计, 再进行代码.

变化定律: 程序存在的时间越久, 它的某个部分需要变化的可能性就越高.

一切都是变化的, 你自己, 还有这个世界.

所以需求变更是必然的:)

之前学到一个很重要的观点: 拥抱变化.

软件设计三大误区: 1.编写不必要的代码 2.代码难以修改 3.过分追求通用

YAGIN, 不要编写不是必须的代码, 并且要删除没有用到的代码. 版本库干嘛用的? 提交, 然后删除那些没用的, 然后再提交:)

僵化设计的原因: 1.对未来做了太多假设(……) 2.不仔细设计就编写代码(新手需注意). 设计程序时, 应当根据你现在确切知道的需求, 而不是你认为未来会出现的需求

避免过度设计: 仅仅根据目前确知的需求来考虑通用.

缺陷概率定律: 在程序中新增缺陷的可能性与代码修改量成正比

好的设计, 代码少(很大可能), 代码变更少, 而糟糕的设计, 反之. 从而, bug出现的概率显而易见

最好的设计, 就是能够适应外界尽可能多的变化. 而软件自身的变化要尽可能少.

不变应万变, 追求之

永远不要修正 任何东西, 除非它真的可能有问题, 而且有证据表明问题确实存在.

例如: “过早优化”!

当问题成为问题的时候, 才是问题, 才需要去处理!

理想情况下, 任何系统里的任何信息, 都应当只存在一次.

避免重复. 变更时代价最小.

简洁定律: 软件任何一部分的维护难度, 反比于该部分的简洁程度.

简洁是相对的.

保持一致/可读性(代码被阅读的次数远远多于编写和修改的次数)/命名/注释(代码的意图通常不应该用注释来说明, 直接阅读代码就应当能够理解)

复杂性是会叠加的, 而不是简单的线性叠加

问题复杂, 解法不一定复杂.

解决复杂性: 把它分解成独立的小部分, 并进行重新设计.

测试法则: 你对软件行为的了解程度, 等于你真正测试它的程度……除非亲自测试过, 否则你不知道软件是否能正常运行.

about test.

编写可读代码的艺术

关于如何编写高质量可读的代码的方法论:)

«The Art of Readable Code>>, 这本书就不细写了, 因为不到两百页, 几乎每一页都是干货.

强烈推荐.

代码大全太厚, «Clean Code>>太晦涩, 建议来读这本. 每次总能得到一些感悟.

重读Rework

Sun, 09 Nov 2014 08:00:00 +0800

忙碌了一段时间, 终于迎来了久违的周末.

时间过得很快, 入职快三个月了, 很忙但很充实, 带来的影响是, 时间少了, 读书和写 blog 的进度随之放缓, 但是积累了很多笔记.

<>这本书, 是37signals三本本书中的第二本, 读过很多遍了, 短小精悍, 但是每次重读都会有一些不同的收获, 建议买一本珍藏:)

以下是一些摘录和自己的看法, 仅供参考

————————

做一些自己喜欢的事情并从中获得些回报

要思考下自己目前的工作, 是否符合这一点? 如果是, 那就继续努力做好, 如果不是, 就需要思考下, 自己喜欢做什么?

一种普遍的错误认知是: 人要从错误中吸取经验教训.

要学会从错误中吸取经验, 这句话是没错的, 不断尝试, fail fast, 然后得到一些东西, 这也是没问题的. 但是, 不要认为, 不断从错误中吸取教训就能获得成功. 就像通关游戏有一千个坑, 你或许可以一个个试, 然后一次学到一些东西, 但是….有没有想过, 失败不是成功的先决条件

你更应该从成功中汲取养分.成功才是真正靠得住的教材.

优秀是一种习惯, 进化是建立在成功的基础之上的. 每个人, 无时无刻都是在往前走的, 然而, 每个人最终得到的并不一样.

计划即瞎猜……现在就决定你这周要做什么,不必去管全年的计划, 只要找出下一项最重要的任务, 然后起而行之.

准确理解应该是: 长期计划即瞎猜……你不需要年度/季度/月度计划, 但是你需要年度/季度/月度目标, 计划总是赶不上变化的, 你总是花费很长一段时间或者很多精力给自己制定一个非常完美的计划, 但是计划永远只是计划而已.不去做, 只是徒费精力.我的做法是, 有目标, 然后拆解成小目标, 小目标更灵活可变, 而在do的时候, 只专注于一两个, 并且根据自己的心情/状态等灵活变动. 拥抱变化, 只要保证不偏离目标主体就行. 不过短期计划还是需要的, 例如每天的todo list. 我现在切换成了things管理, wunderlist貌似也不错, 不过你需要找一个最适合你自己的工具.

工作狂的行为不但没有必要, 而是愚蠢至极……真正的英雄早已想出办法, 搞定一切, 然后回家了.

获取三年前刚毕业那会, 我不会完全赞同这个观点, 经过三年, 三家公司, 三种完全不同的工作风格和模式, 看法已经彻底改变了.

快乐工作, 认真生活, 这句话我一年多前才完全认同之. Work Smarter, Not Harder—来自zapier的一篇博文16 of the Best Ways to Work Smarter, Not Harder

我之前的博文提过, 恶性循环/良性循环, 所谓的工作狂, 就是处在恶性循环中而不自知, 如果觉得自己有点苗头, 需要自省.

拼的是效率, 而不是时间.

首先, 工作永远是干不完的, 你必须明确知道这一点. 其次, 效率是可以提升的, 你也必须认同这一点, 并通过不断完善自己的工作风格/模式, 优化共同方式, 积累经验, 技术栈工具栈补完, 你可以达到一个很好的状态. 再次, 努力成为英雄而不是工作狂.

用自己的方式, 做自己喜欢做的事情, 并从中获得回报.

这才是工作.

在宇宙中留下你的足迹

人的一生有限.

挠自己痒处,……最好还是做自己真正关心的东西

写代码, 有一个吃自己的狗粮一说. 这里同, 做自己关心的东西, 感兴趣的东西, 优秀到卓越的区别在于此.

在你的人生中真正有意义的是你做了什么, 而不是你想过什么,说过什么, 或者计划过什么

计划党/拖延症患者需注意….

永远不会有正当其时的时候…..完美的时机永远不会出现

所以, 不要找借口了吧骚年? 活在当下, 现在就开始.

Draw a line in the sand.

信念, 你所坚守的到底是什么?

坚守某种信念并不仅仅是把它写下来. 不但要相信它, 还要让他成为你的生活方式.

think about it

你需要的是承诺策略, 而不是退出策略

你做事情的第一反应是?

与其做半个成品, 不如做好半个产品

以后再重构, 这句话是很虚无缥缈的, 可以说是遥遥无期, 所以, 经手的每一件事情, 每一行代码, 做到最好. 不要考虑退出策略

不要过早关注细节……你只有在真正开始后, 才能认清到底哪些细节才是最重要的.

同不要过早优化:)

关注不变因素

什么才是不变的? 才是核心? 才是重要的?

人们把装备当做取胜的法宝, 却不愿花时间去练习……

妄图寻找捷径?

有一段时间是工具控, 沉迷各种工具，编辑器，插件，操作系统，效率，gtd,浏览器等等

其实，更重要的是事情本身, 是人本身

Get things done, 就足够了

花时间找到适合自己的工具, 不太重, 不过轻, 刚刚合适就好. 而不是花时间收集一大堆东西, 徒耗精力.

现在，已经没那么狂热了，只遵循一个原则，尝试新事物，针对所有工具，使用二八原则，只关心最核心的20%. 足够了.

立马就上线…为了迅速上线,要砍掉一切不必要的东西…最有效的成功方法是不断尝试. 不要再臆测到底会发生什么事了, 到现实中去寻找答案吧.

小步快跑才是王道

退出的理由?

为什么要这么做? 你在解决什么问题?这真的有用么?你加上去的东西有价值么? 这种改变真的会起作用么? 这种方法更简单吗? 有其他更值得做的事情吗? 这样做值吗?

Interruption is the enemy of productivity……你的生活被各种干扰包围着, 只有你自己才能去发起反击.

干扰不可避免, 只看你如何去解决. 你必须要形成行之有效的工作风格/模式, 以及沟通方式, 并培训你的战友.

会议有毒

如何更高效地开会? 这几个月已经彻底杜绝了被动的会议, 但是有些必要的会议时间还是太长了.

Good enough is fine.

没有更好, 只有合适. 简单有效就ok.

Don’t be a hero

有些时候, 需要考虑适时退出.

该睡觉时睡觉

作息规律, 高效保证, 熬夜苦撑没有任何好处

积累动力的方法就是完成一项任务，然后紧接去完成下一项任务

重要, 不要给自己设置一个不可能完成的东西, 然后被恐惧压垮

预估都是垃圾

不是不预估, 而是, 你需要聪明地去预估. 分治, 小的任务总是更容易把控些.

要做得比你的对手少, 并以此来击败他们.

少.

不要相信”客户永远是正确的”这种废话

不要相信”产品/老板永远是正确的”这句话, 思辨地看待问题, 提出问题, 解决问题. 学会说’no’. (处理需求的时候很重要)

头脑发热不等于当务之急

做当前最重要的事情, 而不是最想去做的事情.

要保持低调, 你可以利用这段时间继续调整你的策略, 解决纠结的问题, 测试各种创意, 尝试新事物.

黑暗森林?

一夜成名只是传说……道路很艰难, 但你必须充满信心.

生活

受不了时再招人……不要提前招人.

你最终会明确你想要招的是什么样的人.

鸡尾酒会上的陌生人……要营造一个能让人直言不讳并且有安全感的环境.

所处的环境是不是这样的? 你能否感觉到自己是一份子, 能改变些什么? 而不是深深的无力感?

多年的无关经验……真正的差别来自于个人的努力程度, 性格差异以及智力水平.

人和人的区别和工作年限相关性其实蛮低的, 深有体会.

文化不是由谁创造的……企业文化是行为, 不是语言

连着实习, 四家公司, 企业文化? 有两家白纸黑字进去新员工培训就有, 大大的标语什么的, 迄今没有记得是什么. 杭州一年多, 是那种潜移默化的, 你从大家的身上可以感受到的东西, 对我影响很大, 受益良多. 现在感受到的, 同样是身体力行, 在一件件事情中. 所以找工作, 如果觉得契合, ok, 如果感觉所谓的文化很SB, 果断些.

会写代表会思考

代码/总结/博客

不要一受伤就结疤, 不要因为一个人的一次错误而去指定规章制度.只有当一件事情反复发生时，才需要为之制定规章制度

我们做事的时候是不是也这样? 一遭被蛇咬, 十年怕井绳. 这样自己的领域会不断地受限的.

所以, 事不过三的原则很重要:)

灵感稍纵即逝……想法是不朽的, 一直都会存在. 最不可能长存的是灵感.

Vim相关资源

Fri, 03 Oct 2014 08:00:00 +0800

Vim资源列表

之前在 k-vim 的readme中写了很多, 本次更新8.0版本后, 对其进行了梳理, 感觉放那并不合适, 所以迁过来这边:)

    .----------------.  .----------------.  .----------------.
    | .--------------. || .--------------. || .--------------. |
    | | ____   ____  | || |     _____    | || | ____    ____ | |
    | ||_  _| |_  _| | || |    |_   _|   | || ||_   \  /   _|| |
    | |  \ \   / /   | || |      | |     | || |  |   \/   |  | |
    | |   \ \ / /    | || |      | |     | || |  | |\  /| |  | |
    | |    \ ' /     | || |     _| |_    | || | _| |_\/_| |_ | |
    | |     \_/      | || |    |_____|   | || ||_____||_____|| |
    | |              | || |              | || |              | |
    | '--------------' || '--------------' || '--------------' |
    '----------------'  '----------------'  '----------------'

资源库

Tutorial

Tips

国内文章

国外文章

视频

其他vim配置

sof

其他

Python 源码阅读 - dict

Mon, 11 Aug 2014 08:00:00 +0800

基本类型实现的最后一篇, 先告一段落, 专心找工作去……搞定工作后再开始扫后面的

源码位置 Include/dictobject.h | Objects/dictobject.c

PyDictObject的存储策略

1. 使用散列表进行存储

2. 使用开放定址法处理冲突

    2.1 插入, 发生冲突, 通过二次探测算法, 寻找下一个位置, 直到找到可用位置, 放入(形成一条冲突探测链)

    2.2 查找, 需要遍历冲突探测链

    2.3 删除, 如果对象在探测链上, 不能直接删除, 否则会破坏整个结构(所以不是真的删)

关于 hash表的 wiki

基本键值PyDictEntry

typedef struct {
    Py_ssize_t me_hash;
    PyObject *me_key;
    PyObject *me_value;
} PyDictEntry;

说明

1. PyDictEntry 用于存储键值对信息

2. Py_ssize_t me_hash
存储了me_key计算得到的hash值, 不重复计算

结构

PyDictEntry的三个状态(图片引自-Python源码剖析)

PyDictObject定义

定义

typedef struct _dictobject PyDictObject;
struct _dictobject {
    PyObject_HEAD

    Py_ssize_t ma_fill;
    Py_ssize_t ma_used;
    Py_ssize_t ma_mask;

    PyDictEntry *ma_table;
    PyDictEntry *(*ma_lookup)(PyDictObject *mp, PyObject *key, long hash);
    PyDictEntry ma_smalltable[PyDict_MINSIZE];
};

说明

1. PyObject_HEAD
反而声明为定长对象, 因为ob_size在这里用不上, 使用ma_fill和ma_used计数

2. Py_ssize_t ma_fill;
   Py_ssize_t ma_used;

    ma_fill = # Active + # Dummy
    ma_used = # Active

3. Py_ssize_t ma_mask;
散列表entry容量 = ma_mask + 1, 初始值ma_mask = PyDict_MINSIZE - 1 = 7

    ma_mask + 1 = # Unused + # Active + # Dummy

4. PyDictEntry *ma_table;
指向散列表内存, 如果是小的dict(entry数量<=8). 指向ma_smalltable数组

5. ma_lookup
搜索函数

6. PyDictEntry ma_smalltable[PyDict_MINSIZE];
小dict, 大小8, 小于8个键值对的字典会直接存放在这里, 超出后再从内存分配空间

结构

结论

1. PyDictObject在生命周期内, 需要维护ma_fill/ma_used/ma_mask 三个计数值

2. 初始化创建是ma_smalltable, 超过大小后, 会使用外部分配的空间

构造过程

定义

PyObject *
PyDict_New(void)
{
    register PyDictObject *mp;

    // 初始化dummy
    if (dummy == NULL) {
        dummy = PyString_FromString("");
        if (dummy == NULL)
            return NULL;

    // 暂时忽略
#ifdef SHOW_CONVERSION_COUNTS
        Py_AtExit(show_counts);
#endif
#ifdef SHOW_ALLOC_COUNT
        Py_AtExit(show_alloc);
#endif
#ifdef SHOW_TRACK_COUNT
        Py_AtExit(show_track);
#endif
    }

    // 如果PyDictObject缓冲池可用
    if (numfree) {
        // 取缓冲池最后一个可用对象
        mp = free_list[--numfree];

        assert (mp != NULL);
        assert (Py_TYPE(mp) == &PyDict_Type);
        _Py_NewReference((PyObject *)mp);

        // 初始化
        if (mp->ma_fill) {
            // 1. 清空 ma_smalltable
            // 2. ma_used = ma_fill = 0
            // 3. ma_table -> ma_smalltable
            // 4. ma_mask = PyDict_MINSIZE - 1 = 7
            EMPTY_TO_MINSIZE(mp);
        } else {
            // 1. ma_table -> ma_smalltable
            // 2. ma_mask = PyDict_MINSIZE - 1 = 7
            INIT_NONZERO_DICT_SLOTS(mp);
        }

        assert (mp->ma_used == 0);
        assert (mp->ma_table == mp->ma_smalltable);
        assert (mp->ma_mask == PyDict_MINSIZE - 1);
#ifdef SHOW_ALLOC_COUNT
        count_reuse++;
#endif
    } else {
        // 创建一个
        mp = PyObject_GC_New(PyDictObject, &PyDict_Type);
        if (mp == NULL)
            return NULL;
        // 初始化 1/2/3/4
        EMPTY_TO_MINSIZE(mp);

#ifdef SHOW_ALLOC_COUNT
        count_alloc++;
#endif
    }

    // 搜索方法, 关注这个
    mp->ma_lookup = lookdict_string;

#ifdef SHOW_TRACK_COUNT
    count_untracked++;
#endif
#ifdef SHOW_CONVERSION_COUNTS
    ++created;
#endif

    // 返回
    return (PyObject *)mp;
}

简化步骤

1. 如果PyDictObject对象缓冲池有, 从里面直接取, 初始化

2. 否则, 创建一个, 初始化

3. 关联搜索方法lookdict_string

4. 返回

结论

1. 关注对象缓冲池

2. 关注lookdict_string

销毁过程

方法定义

static void
dict_dealloc(register PyDictObject *mp)
{
    register PyDictEntry *ep;
    Py_ssize_t fill = mp->ma_fill;
    PyObject_GC_UnTrack(mp);
    Py_TRASHCAN_SAFE_BEGIN(mp)

    // 遍历销毁ma_table中元素 (ma_table可能指向small_table 或 外部)
    for (ep = mp->ma_table; fill > 0; ep++) {
        if (ep->me_key) {
            --fill;
            Py_DECREF(ep->me_key);
            Py_XDECREF(ep->me_value);
        }
    }

    // 如果指向外部, 销毁整个(上面一步只销毁内部元素)
    if (mp->ma_table != mp->ma_smalltable)
        PyMem_DEL(mp->ma_table);

    // 如果对象缓冲池未满且是PyDict_Type, 放入
    if (numfree < PyDict_MAXFREELIST && Py_TYPE(mp) == &PyDict_Type)
        free_list[numfree++] = mp;
    else
        // 否则回收
        Py_TYPE(mp)->tp_free((PyObject *)mp);
    Py_TRASHCAN_SAFE_END(mp)
}

PyDictObject对象缓冲池

定义

#ifndef PyDict_MAXFREELIST
#define PyDict_MAXFREELIST 80
#endif

static PyDictObject *free_list[PyDict_MAXFREELIST];
static int numfree = 0;

对象缓冲池的结构(跟PyListObject对象缓冲池结构基本一样)

结论

1. 最多会缓存80个对象

2. 只缓存 PyDictObject 本身, 其PyDictEntry全部会被回收

3. 缓存对象进去, 旧有的值没有变化, 取出来用的时候初始化时才改变

Dict 操作

查找/插入/resize/删除, 下个版本补

changelog

2014-08-11 first version

Python 源码阅读 - tuple

Sun, 10 Aug 2014 17:10:00 +0800

还差一篇……写完写简历>_<#

示例

>>> a = ()
>>> b = ()
>>> id(a) == id(b)
True

>>> a = (1, )
>>> b = (1, )
>>> id(a) == id(b)
False

源码位置 Include/tupleobject.h | Objects/tupleobject.c

结构

定义

typedef struct {
    PyObject_VAR_HEAD
    PyObject *ob_item[1];

} PyTupleObject;

说明

1. PyObject_VAR_HEAD
PyTupleObject在底层是个变长对象(需要存储列表元素个数).
虽然, 在python中, tuple是不可变对象

2. PyObject *ob_item[1];
指向存储元素的数组

3.

结构

构造方法

PyAPI_FUNC(PyObject *) PyTuple_New(Py_ssize_t size);

构造

看下构造方法定义

PyObject *
PyTuple_New(register Py_ssize_t size)
{
    register PyTupleObject *op;
    Py_ssize_t i;

    // 大小为负数, return
    if (size < 0) {
        PyErr_BadInternalCall();
        return NULL;
    }

    // 如果大小=0, 空元组, 直接取free_list第一个返回
#if PyTuple_MAXSAVESIZE > 0
    if (size == 0 && free_list[0]) {
        op = free_list[0];
        Py_INCREF(op);

#ifdef COUNT_ALLOCS
        tuple_zero_allocs++;
#endif

        return (PyObject *) op;
    }

    // 如果free_list可分配, 从free_list取一个
    if (size < PyTuple_MAXSAVESIZE && (op = free_list[size]) != NULL) {
        // 上面  op = free_list[size] 取得单链表头
        // free_list指向单链表下一个元素, 对应位置阈值--
        free_list[size] = (PyTupleObject *) op->ob_item[0];
        numfree[size]--;

#ifdef COUNT_ALLOCS
        fast_tuple_allocs++;
#endif

      // 初始化 ob_size和ob_type
      /* Inline PyObject_InitVar */
#ifdef Py_TRACE_REFS
        Py_SIZE(op) = size;
        Py_TYPE(op) = &PyTuple_Type;
#endif
        _Py_NewReference((PyObject *)op);
    }
    else
#endif   // free_list不可用
    {
        // 计算空间
        Py_ssize_t nbytes = size * sizeof(PyObject *);
        /* Check for overflow */
        if (nbytes / sizeof(PyObject *) != (size_t)size ||
            (nbytes > PY_SSIZE_T_MAX - sizeof(PyTupleObject) - sizeof(PyObject *)))
        {
            return PyErr_NoMemory();
        }

        // 分配内存
        op = PyObject_GC_NewVar(PyTupleObject, &PyTuple_Type, size);
        if (op == NULL)
            return NULL;
    }

    // 初始化ob_item每个元素
    for (i=0; i < size; i++)
        op->ob_item[i] = NULL;

    // 第一次分配空数组, 将其放入free_list第一个位置
#if PyTuple_MAXSAVESIZE > 0
    if (size == 0) {
        free_list[0] = op;
        ++numfree[0];
        Py_INCREF(op);          /* extra INCREF so that this is never freed */
    }
#endif


#ifdef SHOW_TRACK_COUNT
    count_tracked++;
#endif

    _PyObject_GC_TRACK(op);

    // 返回
    return (PyObject *) op;
}

简化步骤

1. 如果size=0, 从free_list[0]取, 直接返回

2. 否则, 确认free_list[size], 是否可用, 可用获取

3. 否则, 从内存分配新的空间

4. 初始化, 返回

回收

定义

static void
tupledealloc(register PyTupleObject *op)
{
    register Py_ssize_t i;
    // 获取元素个数
    register Py_ssize_t len =  Py_SIZE(op);

    PyObject_GC_UnTrack(op);
    Py_TRASHCAN_SAFE_BEGIN(op)


    if (len > 0) {
        i = len;
        // 遍历, 析构每个元素
        while (--i >= 0)
            Py_XDECREF(op->ob_item[i]);

         // 与对象缓冲池相关
#if PyTuple_MAXSAVESIZE > 0
        if (len < PyTuple_MAXSAVESIZE &&
            numfree[len] < PyTuple_MAXFREELIST &&
            Py_TYPE(op) == &PyTuple_Type)
        {
            op->ob_item[0] = (PyObject *) free_list[len];
            numfree[len]++;
            free_list[len] = op;
            goto done; /* return */
        }
#endif

    }
    // 调用回收
    Py_TYPE(op)->tp_free((PyObject *)op);

done:
    Py_TRASHCAN_SAFE_END(op)
}

简化流程

1. 回收ob_item每个元素

2. 如果符合条件, 放入到free_list

3. 否则, 回收

tuple对象缓冲池

定义

/* Speed optimization to avoid frequent malloc/free of small tuples */
#ifndef PyTuple_MAXSAVESIZE
#define PyTuple_MAXSAVESIZE     20
#endif

#ifndef PyTuple_MAXFREELIST
#define PyTuple_MAXFREELIST  2000
#endif

#if PyTuple_MAXSAVESIZE > 0

static PyTupleObject *free_list[PyTuple_MAXSAVESIZE];
static int numfree[PyTuple_MAXSAVESIZE];
#endif

结论

1. 作用: 优化小tuple的mall/free

2. PyTuple_MAXSAVESIZE = 20
会被缓存的tuple长度阈值, 20, 长度<20的, 才会走对象缓冲池逻辑

3. PyTuple_MAXFREELIST  2000
每种size的tuple最多会被缓存2000个

4. PyTupleObject *free_list[PyTuple_MAXSAVESIZE]
free_list, 指针数组, 每个位置, 存储了指向一个单链表头的地址

5. numfree[PyTuple_MAXSAVESIZE]
numfree, 一个计数数组, 存储free_list对应位置的单链表长度

6. free_list[0], 指向空数组, 有且仅有一个

free_list的结构

回头看回收跟对象缓冲池相关的逻辑

条件:

if (len < PyTuple_MAXSAVESIZE &&         // len < 20
    numfree[len] < PyTuple_MAXFREELIST && // numfree[len] < 2000
    Py_TYPE(op) == &PyTuple_Type) // 是tuple类型

操作

op->ob_item[0] = (PyObject *) free_list[len]; //ob_item指向free_list[len] 单链表头
numfree[len]++;  // len位置计数+1
free_list[len] = op; // op变成单链表的头
goto done; /* return */

即过程

1. 如果size=0, 直接从free_list[0]取

2. 如果size!=0, 判断size<20?

3.1 size < 20, 从free_list对应size位置的单链表, 取头部第一个位置

3.2 size < 20, free_list对应size位置还没有可用对象的话, 走内存分配逻辑

4 size > 20  走内存分配逻辑


------------------

回收时

如果size<20, 且free_list对应位置单链表长度没达到上限(2000), 将对象放入到单链表头

注意

1. 回收时, ob_item都会被回收, 只是本身对象缓存下来

2. 这里free_list, 复用ob_item作为链表指针, 指向下一个位置(通用整数对象池也是复用指针的方式, 不过用的是ob_type)

changelog

2014-08-10 first version

Python 源码阅读 - list

Sun, 10 Aug 2014 08:00:00 +0800

还剩 tuple 和 dict就把几个基本类型写完了, 然后歇歇先找工作>_<

源码位置 Include/listobject.h | Objects/listobject.c

定义

typedef struct {
    PyObject_VAR_HEAD

    PyObject **ob_item;

    Py_ssize_t allocated;
} PyListObject;

说明

1. PyObject_VAR_HEAD
PyListObject是变长对象

2. PyObject **ob_item;
指向列表元素的指针数组, list[0] 即 ob_item[0]

3. Py_ssize_t allocated;
allocated列表分配的空间, ob_size为已使用的空间
allocated 总的申请到的内存数量
ob_size 实际使用内存数量

等式:

    0 <= ob_size <= allocated
    len(list) == ob_size
    ob_item == NULL implies ob_size == allocated == 0

结构

构造

只有一个方法

定义如下

PyObject *
PyList_New(Py_ssize_t size)
{
    PyListObject *op;
    size_t nbytes;
#ifdef SHOW_ALLOC_COUNT
    static int initialized = 0;
    if (!initialized) {
        Py_AtExit(show_alloc);
        initialized = 1;
    }
#endif

    // 大小为负数, return
    if (size < 0) {
        PyErr_BadInternalCall();
        return NULL;
    }

    // 如果大小超过, 报错
    /* Check for overflow without an actual overflow,
     *  which can cause compiler to optimise out */
    if ((size_t)size > PY_SIZE_MAX / sizeof(PyObject *))
        return PyErr_NoMemory();

    // 计算需要的字节数(PyObject指针数组)
    nbytes = size * sizeof(PyObject *);

    // 如果缓冲池非空, 从缓冲池取
    if (numfree) {
        // 取缓冲池数组最后一个对象
        numfree--;
        op = free_list[numfree];

        // set refcnt=1
        _Py_NewReference((PyObject *)op);
#ifdef SHOW_ALLOC_COUNT
        count_reuse++;
#endif
    } else {

        // 否则, GC_New分配内存空间
        op = PyObject_GC_New(PyListObject, &PyList_Type);

        // 分配失败
        if (op == NULL)
            return NULL;
#ifdef SHOW_ALLOC_COUNT
        count_alloc++;
#endif
    }

    // 确定ob_item列表元素指针的值
    // 若大小<=0
    if (size <= 0)
        op->ob_item = NULL;
    else {
        // 分配内存
        op->ob_item = (PyObject **) PyMem_MALLOC(nbytes);
        if (op->ob_item == NULL) {
            Py_DECREF(op);
            return PyErr_NoMemory();
        }

        // 初始化, 填充
        memset(op->ob_item, 0, nbytes);
    }

    // ob_size = size
    Py_SIZE(op) = size;
    // allocated
    op->allocated = size;

    // gc用
    _PyObject_GC_TRACK(op);
    return (PyObject *) op;
}

简化步骤

1. 判断列表缓冲池是否为空, 是的话从缓冲池取(复用)
2. 否则, 从内存中分配空间
3. 然后初始化数据

结论

Py_SIZE(op) = size;
op->allocated = size;
第一次生成list, 其allocated = ob_size

list_resize

同时注意list_resize方法

extends方法, list_resize(self, m + n)
pop方法,  list_resize(self, Py_SIZE(self) - 1)
append方法, list_resize(self, n+1)

其定义

list_resize(PyListObject *self, Py_ssize_t newsize)
{
  ...........

  // 如果   allocated/2 <= newsize <= allocated
  // 直接修改ob_size
  if (allocated >= newsize && newsize >= (allocated >> 1)) {
      assert(self->ob_item != NULL || newsize == 0);
      Py_SIZE(self) = newsize;
      return 0;
  }


  //否则

  new_allocated = (newsize >> 3) + (newsize < 9 ? 3 : 6);
  new_allocated += newsize;

  .............

  Py_SIZE(self) = newsize;
  self->allocated = new_allocated;

}

即

if allocated/2 <= newsize <= allocated

    allocated 不变
    ob_size = newsize

else

    allocated =  newsize +   ((newsize >> 3) + (newsize < 9 ? 3 : 6))
    ob_size = newsize

回收和PyListObject对象缓冲池

看下缓冲池相关的定义

/* Empty list reuse scheme to save calls to malloc and free */
#ifndef PyList_MAXFREELIST
#define PyList_MAXFREELIST 80
#endif

// 80个
static PyListObject *free_list[PyList_MAXFREELIST];

static int numfree = 0;

我们先看下list_dealloc的定义

static void
list_dealloc(PyListObject *op)
{
    Py_ssize_t i;
    PyObject_GC_UnTrack(op);
    Py_TRASHCAN_SAFE_BEGIN(op)

    // 遍历ob_item, 释放所有类表内元素空间
    if (op->ob_item != NULL) {
        /* Do it backwards, for Christian Tismer.
           There's a simple test case where somehow this reduces
           thrashing when a *very* large list is created and
           immediately deleted. */
        i = Py_SIZE(op);
        while (--i >= 0) {
            Py_XDECREF(op->ob_item[i]);
        }
        PyMem_FREE(op->ob_item);
    }

    // 如果free_list还没满, PyListObject加入到列表中
    if (numfree < PyList_MAXFREELIST && PyList_CheckExact(op))
        free_list[numfree++] = op;
    else
        // free_list已经满了, 则回收内存
        Py_TYPE(op)->tp_free((PyObject *)op);

    Py_TRASHCAN_SAFE_END(op)
}

即

对一个列表对象PyListObject, 回收时, ob_item会被回收, 其每个元素指向的对象引用-1.
但是PyListObject对象本身, 如果缓冲池未满, 会被放入缓冲池, 复用

缓冲池结构

List的操作过程

插入

1. resize n+1
2. 确定插入点
3. 插入点后所有元素后移
4. 执行插入

示例

>>> a = [1, 2, 3]
>>> a.insert(0, 9)
>>> a
[9, 1, 2, 3]

append

1. resize n+1
2. 放入最后一个位置(ob_size)

示例

>>> a = [1, 2, 3]
>>> a.append(4)
>>> a
[1, 2, 3, 4]

extend

1. 计算两个list大小 m n
2. resize m+n(此时本身被复制)
3. 遍历长度为n的数组, 从ob_item+m的位置开始加入

示例

>>> m = [1, 2, 3]
>>> n = [4, 5]
>>> m.extend(n)
>>> m
[1, 2, 3, 4, 5]

删除

1. 找到要删除元素位置
2. 删除之, 后面元素前移

示例

>>> a = [1, 2, 3, 2]
>>> a.remove(2)
>>> a
[1, 3, 2]

changelog

2014-08-10 first version

Python 源码阅读 - string

Fri, 08 Aug 2014 08:00:00 +0800

本周进展不大(去掉北上, 选择余地太小了), 下周开始投简历:(

这一章, 就一张图, 代码比较多

PyStringObject

源码位置 Include/stringobject.h | Objects/stringobject.c

定义

typedef struct {
  PyObject_VAR_HEAD
  long ob_shash;
  int ob_sstate;
  char ob_sval[1];

  /* Invariants:
   *     ob_sval contains space for 'ob_size+1' elements.
   *     ob_sval[ob_size] == 0.
   *     ob_shash is the hash of the string or -1 if not computed yet.
   *     ob_sstate != 0 iff the string object is in stringobject.c's
   *       'interned' dictionary; in this case the two references
   *       from 'interned' to this object are *not counted* in ob_refcnt.
   */
} PyStringObject;

说明

1. PyObject_VAR_HEAD
PyStringObject是变长对象, 比定长对象多了一个ob_size字段

2. ob_shash
存储字符串的hash值, 如果还没计算等于-1
当string_hash被调用, 计算结果会被保存到这个字段一份, 后续不再进行计算

3. ob_sstate
如果是interned, !=0, 否则=0
interned后面说

4. char ob_sval[1]
字符指针指向一段内存, char数组指针, 指向一个ob_size+1大小数组(c中字符串最后要多一个字符`\0`表字符串结束)

结构

构造方法

PyAPI_FUNC(PyObject *) PyString_FromString(const char *);

PyAPI_FUNC(PyObject *) PyString_FromStringAndSize(const char *, Py_ssize_t);

两个构造方法其实区别不大,

PyString_FromStringAndSize 参数可以为`NULL`, 无论是否为`NULL`, 都会分配`size+1`个字节空间.(不为NULL的话字符数组会进行拷贝)

PyString_FromString, 参数不能为`NULL`, 且必须是`\0`结束的字符数组, 会调用c 语言string.h模块的strlen()函数计算字符串长度, 分配空间, 并将整个字符数组拷贝到ob_sval指向的内存

我们关注PyString_FromString就行

创建过程 PyString_FromString

定义

//默认未初始化, 均为NULL
static PyStringObject *characters[UCHAR_MAX + 1];
static PyStringObject *nullstring;

PyObject *
PyString_FromString(const char *str)
{
    register size_t size;
    register PyStringObject *op;

    assert(str != NULL);

    // 计算参数字符数组长度
    size = strlen(str);

    // 超长, 报错(PY_SSIZE_T_MAX平台相关,32位2GB)
    if (size > PY_SSIZE_T_MAX - PyStringObject_SIZE) {
        PyErr_SetString(PyExc_OverflowError,
            "string is too long for a Python string");
        return NULL;
    }

    // 长度=0, 且nullstring已定义, 返回nullstring
    if (size == 0 && (op = nullstring) != NULL) {
#ifdef COUNT_ALLOCS
        null_strings++;
#endif
        Py_INCREF(op);
        return (PyObject *)op;
    }

    // 字符缓冲池逻辑
    // 长度=1, 且characters[*str & UCHAR_MAX]字符已定义
    if (size == 1 && (op = characters[*str & UCHAR_MAX]) != NULL) {
#ifdef COUNT_ALLOCS
        one_strings++;
#endif
        Py_INCREF(op);
        return (PyObject *)op;
    }

    // 申请内存空间
    /* Inline PyObject_NewVar */
    op = (PyStringObject *)PyObject_MALLOC(PyStringObject_SIZE + size);
    if (op == NULL)
        return PyErr_NoMemory();

    // 初始化
    PyObject_INIT_VAR(op, &PyString_Type, size);
    op->ob_shash = -1; //未计算hash, -1
    op->ob_sstate = SSTATE_NOT_INTERNED;  //未intern, 0
    // 将字符数组拷贝到PyStringObject
    Py_MEMCPY(op->ob_sval, str, size+1);


    // 在nullstring和字符缓冲池对应位置未初始化时, 会走到这个逻辑
    /* share short strings */
    if (size == 0) {
        PyObject *t = (PyObject *)op;
        // 走intern, 后面说
        PyString_InternInPlace(&t);
        op = (PyStringObject *)t;

        // 初始化nullstring
        nullstring = op;
        Py_INCREF(op);
    } else if (size == 1) {
        PyObject *t = (PyObject *)op;
        // 走intern, 后面说
        PyString_InternInPlace(&t);
        op = (PyStringObject *)t;

        // 初始化字符缓冲池对应位置
        characters[*str & UCHAR_MAX] = op;
        Py_INCREF(op);
    }


    // 返回
    return (PyObject *) op;
}

步骤简化

1. 计算长度
2. 长度0, 空字符串, 是返回已定义好的nullstring
3. 长度1, 字符, 返回字符缓冲池里面的
4. 都不是, 分配内存, 初始化

结论

长度0/长度1, 会用到intern机制
注意, intern机制对长度>1的字符串也适用

interned机制

interned

/* This dictionary holds all interned strings.  Note that references to
strings in this dictionary are *not* counted in the string's ob_refcnt.
When the interned string reaches a refcnt of 0 the string deallocation
function will delete the reference from this dictionary.

Another way to look at this is that to say that the actual reference
count of a string is:  s->ob_refcnt + (s->ob_sstate?2:0)
*/
static PyObject *interned; //指针, 指向PyDictObject

interned定义

void
PyString_InternInPlace(PyObject **p)
{
    register PyStringObject *s = (PyStringObject *)(*p);

    PyObject *t;

    // 检查值使用在PyStringObject上, 派生类不适用
    if (s == NULL || !PyString_Check(s))
        Py_FatalError("PyString_InternInPlace: strings only please!");
    /* If it's a string subclass, we don't really know what putting it in the interned dict might do. */

    // 不是字符串类型, 返回
    if (!PyString_CheckExact(s))
        return;
    // 本身已经intern了(标志位ob_sstate), 不重复进行, 返回
    if (PyString_CHECK_INTERNED(s))
        return;

    // 未初始化字典, 初始化之
    if (interned == NULL) {
        // 注意这里
        interned = PyDict_New();
        if (interned == NULL) {
            PyErr_Clear(); /* Don't leave an exception */
            return;
        }
    }

    // 在interned字典中已存在, 修改, 返回intern独享
    t = PyDict_GetItem(interned, (PyObject *)s);
    if (t) {
        Py_INCREF(t);
        Py_DECREF(*p);
        *p = t;
        return;
    }

    // 在interned字典中不存在, 放进去
    if (PyDict_SetItem(interned, (PyObject *)s, (PyObject *)s) < 0) {
        PyErr_Clear();
        return;
    }

    // 加入interned字典(key-value), 会导致refcnt+2, 去掉, 保证当外部没有引用时, refcnt=0, 可以进行回收处理, (不-2, refcnt永远>=2)
    /* The two references in interned are not counted by refcnt.
       The string deallocator will take care of this */
    Py_REFCNT(s) -= 2;

    // 修改字符串对象的ob_sstate标志位, SSTATE_INTERNED_MORTAL
    PyString_CHECK_INTERNED(s) = SSTATE_INTERNED_MORTAL;
}

使用的地方

// 构造方法
PyAPI_FUNC(PyObject *) PyString_FromString(const char *);

PyAPI_FUNC(PyObject *) PyString_FromStringAndSize(const char *, Py_ssize_t);


// SSTATE_INTERNED_MORTAL, 计数0会被回收
PyObject *
PyString_InternFromString(const char *cp)
{
    PyObject *s = PyString_FromString(cp);
    if (s == NULL)
        return NULL;
    PyString_InternInPlace(&s);
    return s;
}


// SSTATE_INTERNED_IMMORTAL, 永远不会被销毁
void
PyString_InternImmortal(PyObject **p)

示例

>>> a = ''
>>> b = ''
>>> id(a) == id(b)
True

>>> a = 'x'
>>> b = 'x'
>>> id(a) == id(b)
True

>>> a = "abc"
>>> b = "abc"
>>> id(a) == id(b)
True

python源代码自己也大量使用

dict_str = PyString_InternFromString("__dict__")
lenstr = PyString_InternFromString("__len__")
s_true = PyString_InternFromString("true")
empty_array = PyString_InternFromString("[]")

好处

一旦字符串被intern, 会被python保存到字典中, 整个python运行期间, 系统中有且仅有一个对象. 下次相同字符串再进入, 不会重复创建对象.

字符缓冲池

定义

UCHAR_MAX 平台相关

static PyStringObject *characters[UCHAR_MAX + 1];

在上面PyString_FromString可以看到, 字符缓冲池在使用中初始化(存在直接返回, 不存在建一个, 放interned字典中, 初始化字符缓冲池对应位置)

PyObject *t = (PyObject *)op;
// 走intern, 后面说
PyString_InternInPlace(&t);
op = (PyStringObject *)t;

// 初始化字符缓冲池对应位置
characters[*str & UCHAR_MAX] = op;

字符串销毁过程

static void
string_dealloc(PyObject *op)
{
    // 是否intern
    switch (PyString_CHECK_INTERNED(op)) {
        // 非, 跳出 -> 回收内存
        case SSTATE_NOT_INTERNED:
            break;

        // 普通, 从interned字典中删除, 跳出 -> 回收内存
        case SSTATE_INTERNED_MORTAL:
            /* revive dead object temporarily for DelItem */
            Py_REFCNT(op) = 3;
            if (PyDict_DelItem(interned, op) != 0)
                Py_FatalError(
                    "deletion of interned string failed");
            break;
        // 永不回收的对象, 报错
        case SSTATE_INTERNED_IMMORTAL:
            Py_FatalError("Immortal interned string died.");

        default:
            Py_FatalError("Inconsistent interned string state.");
    }

    // 回收内存
    Py_TYPE(op)->tp_free(op);
}

性能相关

+与 join

'a' + 'b' + 'c'

or

''.join(['a', 'b', 'c'])

可以查看string_concat方法和string_join方法的源代码

string_concat, 一次加=分配一次内存空间, 拷贝两次. N次链接, 需要N-1次内存分配.
string_join, 计算序列所有元素字符串总长度, 用PyString_FromStringAndSize((char*)NULL, sz)分配内存空间, 然后逐一拷贝. 一次内存操作.

changelog

2014-08-08 first version

Python 源码阅读 - int

Wed, 06 Aug 2014 08:00:00 +0800

==========================

代码我也仅仅是粗粗读了一遍, 可能出现疏漏和理解错误, 发现了望指出哈.

今天面了一家靠谱的创业公司, 可惜不是Python向的, 想继续玩Python是有代价的, 选择余地太窄了……

话说写文章很耗时间, 这个花了两个多小时….主要还是自个绘图渣效率低:(

准备找工作事宜很占时间, 后面只能慢慢来了(好像还很多很多的样子)

示例

>>> a = 1
>>> b = 1
>>> id(a) == id(b)
True

>>> c = 257
>>> d = 257
>>> id(c) == id(d)
False

#在python2.x中, 对于大的序列生成, 建议使用xrange(100000) 而不是range(100000), why?

源码位置 Include/intobject.h | Objects/intobject.c

PyIntObject

typedef struct {
    PyObject_HEAD
    long ob_ival;
} PyIntObject;

结构

几个构造方法

# 从字符串, 生成PyIntObject对象
PyAPI_FUNC(PyObject *) PyInt_FromString(char*, char**, int);

# 从Py_UNICODE, 生成PyIntObject对象
#ifdef Py_USING_UNICODE
PyAPI_FUNC(PyObject *) PyInt_FromUnicode(Py_UNICODE*, Py_ssize_t, int);
#endif

# 从long值, 生成PyIntObject对象
PyAPI_FUNC(PyObject *) PyInt_FromLong(long);

PyAPI_FUNC(PyObject *) PyInt_FromSize_t(size_t);
PyAPI_FUNC(PyObject *) PyInt_FromSsize_t(Py_ssize_t);

这几个方法, 只需要关注

# 因为大家最后都调用这个方法完成对象生成
PyAPI_FUNC(PyObject *) PyInt_FromLong(long);

具体的构造方法 PyInt_FromLong

这个方法的定义

PyObject *
PyInt_FromLong(long ival)
{
    register PyIntObject *v;

    /* MARK: 如果, 值在小整数范围内, 直接从小整数对象池获取得到对象 */

    #if NSMALLNEGINTS + NSMALLPOSINTS > 0
    if (-NSMALLNEGINTS <= ival && ival < NSMALLPOSINTS) {

        /* MARK: small_ints是什么后面说 */
        v = small_ints[ival + NSMALLNEGINTS];
        // 引用+1
        Py_INCREF(v);

        /* 这里先忽略, 计数 */
        #ifdef COUNT_ALLOCS
            if (ival >= 0)
                quick_int_allocs++;
            else
                quick_neg_int_allocs++;
        #endif

        // 返回
        return (PyObject *) v;
    }
    #endif

    // 如果free_list还不存在, 或者满了
    if (free_list == NULL) {
        // 新建一块PyIntBlock, 并将空闲空间链表头部地址给free_list
        if ((free_list = fill_free_list()) == NULL)
            // 如果失败, 返回
            return NULL;
    }

    // 从free_list分出一个位置存放新的整数

    /* Inline PyObject_New */
    // 使用单向链表头位置
    v = free_list;

    // free_list指向单向链表下一个位置
    free_list = (PyIntObject *)Py_TYPE(v);

    // 初始化对象, 类型为PyInt_type, 值为ival
    PyObject_INIT(v, &PyInt_Type);
    v->ob_ival = ival;

    // 返回
    return (PyObject *) v;
}

注意这里的Py_TYPE()方法, 在我们第一篇文章里面有提到, 不知道的回去复习下对象的数据结构

#define Py_TYPE(ob)             (((PyObject*)(ob))->ob_type)

简而言之:

1. 先判断数值是否是小整数, 是的话从小整数对象池里面直接返回
(这个池固定大小, 下一点讲)

2. 如果不是, 从通用整数对象池里面取一个, 初始化返回
(如果这时候通用整数对象池还不存在或者已经满了, 新建一个池加入维护. 通用整数对象池后面讲)

小整数对象池

先看定义

#ifndef NSMALLPOSINTS
#define NSMALLPOSINTS           257
#endif

#ifndef NSMALLNEGINTS
#define NSMALLNEGINTS           5
#endif

#if NSMALLNEGINTS + NSMALLPOSINTS > 0
/* References to small integers are saved in this array
   so that they can be shared.
   The integers that are saved are those in the range
   -NSMALLNEGINTS (inclusive) to NSMALLPOSINTS (not inclusive).
*/

static PyIntObject *small_ints[NSMALLNEGINTS + NSMALLPOSINTS];
#endif

其实, 小整数对象池就是一个PyIntObject指针数组(注意是指针数组), 大小=257+5=262, 范围是[-5, 257) 注意左闭右开. 即这个数组包含了262个指向PyIntObject的指针.

结构

创建整数时, 如果在[-5, 257)范围, 直接返回已经存在的整数对象指针, 所以我们看到开头的例子, id比较一个true/一个false

小整数对象池, 在一开始就初始化了, 其初始化代码

int
_PyInt_Init(void)
{
    PyIntObject *v;
    int ival;

    // 注意这里, free_list再次出现

#if NSMALLNEGINTS + NSMALLPOSINTS > 0

    // 循环, 逐一生成
    for (ival = -NSMALLNEGINTS; ival < NSMALLPOSINTS; ival++) {
          if (!free_list && (free_list = fill_free_list()) == NULL)
                  return 0;

        // 注意这段代码, 和上面PyInt_FromLong那段代码一样的
        /* PyObject_New is inlined */
        v = free_list;
        free_list = (PyIntObject *)Py_TYPE(v);
        PyObject_INIT(v, &PyInt_Type);
        v->ob_ival = ival;

        // 放到数组里
        small_ints[ival + NSMALLNEGINTS] = v;
    }
#endif

    return 1;
}

代码很眼熟吧, 觉得不眼熟回上面看代码

结论

1. 小整数对象池缓存 [-5, 257) 内的整数对象, 数值在这个范围的整数对象有且只存在一个...

2. 小整数对象池, 只是一个指针数组, 其真正对象依赖通用整数对象池

通用整数对象池1 - 基础结构PyIntBlock

首先, 有个数据结构PyIntBlock

#define BLOCK_SIZE      1000    /* 1K less typical malloc overhead */
#define BHEAD_SIZE      8       /* Enough for a 64-bit pointer */
#define N_INTOBJECTS    ((BLOCK_SIZE - BHEAD_SIZE) / sizeof(PyIntObject))


struct _intblock {
    struct _intblock *next;
    PyIntObject objects[N_INTOBJECTS];
};

typedef struct _intblock PyIntBlock;

回忆一下PyIntObject结构(1个int, 1指针, 1个long), size=4+4+4(先这么算), N_INTOBJECTS = 82

结构

通用整数对象池2 - 创建过程及运行时结构

有两个指针

# 指向一个block
static PyIntBlock *block_list = NULL;

# 指向一个PyIntObject
static PyIntObject *free_list = NULL;

生成过程的定义

// 初始化一个PyIntBlock
static PyIntObject *
fill_free_list(void)
{
    PyIntObject *p, *q;
    // 建立一个新的block
    /* Python's object allocator isn't appropriate for large blocks. */
    p = (PyIntObject *) PyMem_MALLOC(sizeof(PyIntBlock));

    // 建立失败(内存耗光了)
    if (p == NULL)
        return (PyIntObject *) PyErr_NoMemory();

    // block_list指向新的PyIntBlock节点
    ((PyIntBlock *)p)->next = block_list;
    block_list = (PyIntBlock *)p;

    /* Link the int objects together, from rear to front, then return
       the address of the last int object in the block. */

    // p=block里面 PyIntObjects数组头地址, q是尾地址
    p = &((PyIntBlock *)p)->objects[0];
    q = p + N_INTOBJECTS;

    // 从尾部开始向首部移动, 利用对象里的ob_type指针(相当于使用这个字段, ob_type不作为原来的用途), 建立起一个单向链表
    // 这个单向链表的头部是数组的最后一个
    while (--q > p)
        Py_TYPE(q) = (struct _typeobject *)(q-1);
    Py_TYPE(q) = NULL; // 单向链表最后一个元素的next指向null

    // 返回单向链表的头地址!!!
    return p + N_INTOBJECTS - 1;

}

新建第一个时, 只有一个

从里面拿整数时, 取free_list指向的节点, 然后free_list指向链表下一个节点

当一个block用完了之后, 即free_list=NULL, 此时要新建另一个PyIntBlock

新建第二个

通用整数对象池3 - 删除一个整数时

定义

#define PyInt_CheckExact(op) ((op)->ob_type == &PyInt_Type)

static void
int_dealloc(PyIntObject *v)
{
    // 是整数类型, 将对象放入free_list单向链表头
    if (PyInt_CheckExact(v)) {
        Py_TYPE(v) = (struct _typeobject *)free_list;
        free_list = v;
    }
    else
        Py_TYPE(v)->tp_free((PyObject *)v); //不是整数类型, 对应类型析构
}

可以看到, 回收的时候, 把空间给放回到free_list了, 后面接着用

block_list维护着所有PyIntBlock列表, 查看源码注释可以看到

PyIntBlocks are never returned to the
 system before shutdown (PyInt_Fini).

即, PyIntBlock申请的所有内存, 在Python结束之前, 都不会被释放

所以, 使用range(100000), 运行后, 虽然程序结束了, 但是整数占用空间还在.

建议对大范围的序列生成使用xrange

python3.x不用担心这个问题

changelog

2014-08-07 first version

Python 源码阅读 - 类型

Tue, 05 Aug 2014 19:31:00 +0800

这篇主要涉及Python对象的类型机制

有点绕, 一定要思维清晰的时候再看哦:)

一个例子

>>> a = 1
>>> a
1

>>> type(a)


#等价的两个
>>> type(type(a))

>>> type(int)


#还是等价的两个
>>> type(type(type(a)))

>>> type(type(int))

我们反向推导一个int对象是怎么生成的.

1. 首先, 定义一种类型叫PyTypeObject

代码位置 Include/object.h

定义

 typedef struct _typeobject {

  /* MARK: base, 注意, 是个变长对象*/
  PyObject_VAR_HEAD
  const char *tp_name; /* For printing, in format "." */ //类型名
  Py_ssize_t tp_basicsize, tp_itemsize; /* For allocation */ // 创建该类型对象时分配的内存空间大小


  // 一堆方法定义, 函数和指针
  /* Methods to implement standard operations */
  printfunc tp_print;
  hashfunc tp_hash;

  /* Method suites for standard classes */
  PyNumberMethods *tp_as_number;   // 数值对象操作
  PySequenceMethods *tp_as_sequence; // 序列对象操作
  PyMappingMethods *tp_as_mapping; // 字典对象操作

  // 一堆属性定义
  ....

} PyTypeObject;

说明

1. PyObject_VAR_HEAD
变长对象

2. const char *tp_name
tp_name, 类型名字符串数组

所有Type都是PyTypeObject的"实例": PyType_Type/PyInt_Type

2. 然后, 用PyTypeObject初始化得到一个对象PyType_Type

代码位置 Objects/typeobject.c

定义

PyTypeObject PyType_Type = {
  PyVarObject_HEAD_INIT(&PyType_Type, 0)
  "type",                                     /* tp_name */
  sizeof(PyHeapTypeObject),                   /* tp_basicsize */
  sizeof(PyMemberDef),                        /* tp_itemsize */
  (destructor)type_dealloc,                   /* tp_dealloc */

  // type对象的方法和属性初始化值
  .....

};

说明

1. tp_name
类型名, 这里是"type"

2. PyVarObject_HEAD_INIT(&PyType_Type, 0)
PyVarObject_HEAD_INIT, 这个方法在 Include/object.h中,
等价于
        ob_refcnt = 1
        *ob_type = &PyType_Type
        ob_size = 0

即, PyType_Type的类型是其本身!

结构

第一张图, 箭头表示实例化(google doc用不是很熟找不到对应类型的箭头)

第二张图, 箭头表示指向

使用

# 1. int 的 类型 是`type`
>>> type(int)


# 2. type 的类型 还是`type`, 对应上面说明第二点
>>> type(type(int))

注意: 无论任何时候, ob_type指向的是 PyTypeObject的实例: PyType_Type/PyInt_Type…

3. 再然后, 定义具体的类型, 这里以PyInt_Type为例子

代码位置 Objects/intobject.c

定义

PyTypeObject PyInt_Type = {
  PyVarObject_HEAD_INIT(&PyType_Type, 0)
  "int",
  sizeof(PyIntObject),
  0,

  // int类型的相关方法和属性值
  ....

  (hashfunc)int_hash,                         /* tp_hash */

};

说明

1. "int"
PyInt_Type的类型名是int

2.PyVarObject_HEAD_INIT(&PyType_Type, 0)
PyInt_Type的

    *ob_type = &PyType_Type

结构

使用

>>> type(1)


>>> type(type(1))

4. 最后, 生成一个整数对象int

代码位置 Include/intobject.h

定义

typedef struct {
    PyObject_HEAD
    long ob_ival;
} PyIntObject;

结构

1. PyIntObject为整数类型

2. 声明一个整数后得到整数对象

3. 对象ob_type指向PyInt_type对象

到这里, 总结下

 1. 一切都是对象

 2. PyType_Type / PyInt_Type / PyString_Type ....等
 这些是`类型对象`, 可以认为是同级, 都是PyTypeObject这种`类型`的实例!

 3. 虽然是同级,
 但是其他PyXXX_Type, 其类型指向 PyType_Type
 PyType_Type 的类型指向自己, 它是所有类型的`类型`

 4. PyTypeObject 是一个变长对象

 5. 每个object, 例如PyIntObject都属于一种`类型`
 object初始化时进行关联

多态是如何实现的?

对象的多态, 例如hash

>>> hash(1)
1
>>> hash("abc")
1453079729188098211

从上面数据结构可以看到, 方法及属性, 在不同Type实例化时就确定了

PyTypeObject PyInt_Type = {
    ...
    (hashfunc)int_hash,                         /* tp_hash */
    ...
}


PyTypeObject PyString_Type = {
    ...
    (hashfunc)string_hash,                      /* tp_hash */
    ...
}

Python内部传递的是泛型指针PyObject *, 函数调用时, 找到其类型* ob_type, 然后调用

object -> ob_type -> tp_hash

即: 大量函数指针决定了该类型的具体行为

changelog

2014-08-05 first version

Python 源码阅读 - 对象

Tue, 05 Aug 2014 17:32:00 +0800

结束休息期, 开始准备面试事宜了, 发现要准备的东西好多(╯‵□′)╯︵┻━┻, 顺手整理下Python源码阅读笔记(力争在写完前找到工作)

参考内容: Python源码 + <>

用源代码+说明+图解的方式, 尽量说明白吧, 有一份注释在github上

内容:

-> 对象/类型
-> 各种内建类型对象及机制
-> 虚拟机相关(编译及执行)
-> 内存管理/动态加载/多线程等

PS: 画图的话google doc很好用

好的, 第一篇开始

一切皆为对象

对象, 在C语言是如何实现的?

Python中对象分为两类: 定长(int等), 非定长(list/dict等)

所有对象都有一些相同的东西, 源码中定义为PyObject和PyVarObject, 两个定义都有一个共同的头部定义PyObject_HEAD(其实PyVarObject有自己的头部定义PyObject_VAR_HEAD, 但其实际上用的也是PyObject_HEAD).

源码位置: Include/object.h

PyObject_HEAD

Python 内部, 每个对象拥有相同的头部.

定义

/* PyObject_HEAD defines the initial segment of every PyObject. */
#define PyObject_HEAD                   \
    _PyObject_HEAD_EXTRA                \
    Py_ssize_t ob_refcnt;               \
    struct _typeobject *ob_type;

说明

1. _PyObject_HEAD_EXTRA
先忽略, 双向链表结构, 后面垃圾回收再说

2. Py_ssize_t ob_refcnt
Py_ssize_t在编译时确定, 整型
ob_refcnt, 引用计数, 跟Python的内存管理机制相关(基于引用计数的垃圾回收)

3. struct _typeobject *ob_type
*ob_type 指向类型对象的指针(指向_typeobject结构体)
决定了这个对象的类型!

PyObject

定义

 typedef struct _object {
     PyObject_HEAD
 } PyObject;

说明

 1. 依赖关系
 PyObject -> PyObject_HEAD

结构

PyVarObject

定义

typedef struct {
    PyObject_VAR_HEAD
} PyVarObject;

#define PyObject_VAR_HEAD               \
  PyObject_HEAD                       \
  Py_ssize_t ob_size; /* Number of items in variable part */

说明

 1. 依赖关系
 PyVarObject -> PyObject_VAR_HEAD -> PyObject_HEAD

 2.Py_ssize_t ob_size
 ob_size, 变长对象容纳的元素个数

结构

代码关系

几个方法

跟对象相关的方法

#define Py_REFCNT(ob)           (((PyObject*)(ob))->ob_refcnt)
读取引用计数

#define Py_TYPE(ob)             (((PyObject*)(ob))->ob_type)
获取对象类型

#define Py_SIZE(ob)             (((PyVarObject*)(ob))->ob_size)
读取元素个数(len)

跟引用计数相关的方法

Py_INCREF(op)  增加对象引用计数

Py_DECREF(op)  减少对象引用计数, 如果计数位0, 调用_Py_Dealloc

_Py_Dealloc(op) 调用对应类型的 tp_dealloc 方法(每种类型回收行为不一样的, 各种缓存池机制, 后面看)

其他

几个参数涉及

ob_refcnt 引用计数, 与内存管理/垃圾回收相关
ob_type   类型, 涉及Python的类型系统

changelog:

2013-08-05 first version

Python后端相关技术/工具栈

Sat, 26 Jul 2014 08:00:00 +0800

整理下目前涉及到的python的技术栈和工具栈(用过或了解的, 其他的后续用到再补充)

编辑器

最常见: vim / SublimeText2 / PyCharm

Vim有兴趣可以看看 k-vim 适合Python/Golang开发

本地环境 pip/easy_install 包管理

viertualenv + virtualenvwrapper 库/版本管理, 环境隔离

ipython/ipdb

Web 框架 Python 的Web 框架非常多……

个人偏好[有分先后]

flask 轻量! 可以灵活组合各类组件进行开发(第三方组件很丰富), 简单高效, 便于快速开发和维护.

tornado 异步, 高性能, 最新版本4.0

django 有些重, 配置和约定众多, 可以快速开发一些"管理"性质的后台, 其版本更新非常快

其他:

bottle 类flask, 一个文件, 足够小

ORM SQLAlchemy

SQLAlchemy is the Python SQL toolkit and Object Relational Mapper that gives application developers the full power and flexibility of SQL.

似乎这个就足够了, 无出其右

模板

只提第三方(很多框架自带了, 例如Django/Tornado), 话说天下模板都大同小异

Jinja2, 最喜欢的一个, 之前写了篇 PYTHON模板-JINJA

Mako, 介绍PYTHON模板-MAKO

还有挺多的, 后续了解后补充

代码管理及Wiki

使用git, 搭建gitlab gilt针对项目级别, 可以用markdown写一些文档, 可以简单的code review, 可以进行讨论等等.

Wiki的选择:

gollum 很赞

trac老牌, 但是个人不大喜欢其语法编辑方式.

代码发布

fabric + rsync

rsync 用于生产代码目录的同步, 足够简单强大

fabric 用于自动化部署, 将流程固化到脚本中重复使用, 提高效率降低风险, PYTHON FABRIC实现远程操作和部署

Fabric is a Python (2.5-2.7) library and command-line tool for streamlining the use of SSH for application deployment or systems administration tasks.

项目部署

nginx 服务器, 主要用于负载均衡, 反代等

gunicorn a Python WSGI HTTP Server for UNIX, 用来运行Flask项目

Supervisor A Process Control System, 配置管理各种程序, 进程监控, 自动重启等

监控

nagios 服务器各类参数监控, 负载,内存,IO, 网络等, 也可以配置对进程进行监控报警

sentry 实时收集事件日志, 可以在管理后台查看到当前程序异常及报错具体信息, 很强大的平台, 支持多种语言的程序

statsd + graphic

statsd 实时服务数据收集(e.g. counters and timers) 收集后数据提供给graphic进行展示

graphic 企业级开源监控工具(数据绘图工具)，用于采集服务器实时信息并进行统计, Graphite 自己本身并不收集具体的数据，这些数据收集的具体工作通常由第三方工具或插件完成. 其控制台前端项目 tessera

NOSQL

redis 缓存/持久化/特殊需求(计数-排行榜-时间线等)

memcached 集群, 多用于有时限性质的缓存

mongodb 在技术选型玩了下, 没有正式在生产用过

数据库

mysql 不解释, 感觉是不是所有Python的底层db都是mysql……

postgresql 开发日志统计系统使用过, 学院派, 各种牛叉的功能, 对json的支持令人印象深刻.

抓取

beautifulsoup 配合urllib2或者requests库进项简单的抓取分析工作

scrapy 很牛的抓取框架, 适合规模较大,需求复杂的的抓取任务

搜索 solr

完成搜索功能, 虽然Python也有一些实现, 但是感觉还是使用成熟的方案会好些, 文档/资源丰富, 便于开发和维护. Solr, 足够简单及强大.

好用的第三方

requests HTTP for humans, 非常好用, 强烈推荐

jieba 中文分词

异步和队列

gearman 支持分布式的任务分发框架, 并行/不同语言之间的通信. 之前使用主要用来跨机器任务分发.

celery 分布式任务队列

zeromq 之前使用的消息系统是基于这个的, 没有研究过

日志

logstash 日志收集和分析, 支持不同来源不同格式, 进行统一收集和分析处理

Elasticsearch 数据

Kibana A log analyzing web interface for logstash and elasticsearch

三者组合

项目管理

tower

Log:

2014-07-24 first version

读书笔记-软件测试的艺术

Sat, 26 Jul 2014 08:00:00 +0800

这本书是三年前毕业时读的, 毕业时的职位是"测试开发工程师".

好吧, 这本书年龄比我还大:), 毕业那会绝版了, 读的是电子版的. 前阵子看到有在卖就买了一本珍藏, 最近重读了一遍.

可以作为测试入门读本.(测试界的经典书籍), 摘录一些, 一些关键字感兴趣可以自己google.

好吧, 在很多人眼里, 测试只是点点鼠标等没技术含量的工作, 干开发干不了才干测试. But, 这个观点是错误的, 测试还是非常博大精深的, 要求还是非常高的(需要懂各类语言, 需要写各种代码, 需要懂各种业务, 需要懂各类场景, 需要项目管理, 需要……).

什么是软件测试

所谓软件测试, 就是一个过程或一系列过程, 用来确认计算机代码完成了其应该完成的功能, 不执行其不该有的操作.

注意后半段.

测试的心理学

测试是为了发现错误而执行的过程

人的行为总是倾向于具有高度目的性. 所以需要将目标定为: 证明程序中存在错误(某些情况下, 测试人员的态度可能比实际的测试过程本身还重要)

所以, 要假设测试的程序是存在错误的.

软件测试的原则 (直接摘录了, 很多观点值得借鉴)

编号	原则
1	测试用例中一个必需部分是对预期输出或结果进行定义
2	程序员应当避免测试自己编写的程序
3	编写软件的组织不应当测试自己编写的软件
4	应当彻底检查每个测试的执行结果
5	测试用例的编写不仅应当根据有限和预料到的输入情况, 而且也应当根据无效和未预料到的输入情况
6	检查程序是否"未做其应该做的"仅是测试的一半, 测试的另一半是检查程序是否"做了其不应该做的"
7	应该避免测试用例用后即弃, 除非软件本身就是一个一次性的软件
8	计划测试工作时不应默许假定不会发生错误
9	程序某部分存在更多错误的可能性, 与该部分已发生错误的数量成正比
10	软件测试是一项极富创造性, 极具智力挑战性的工作

错误发现的越早, 改正错误的成本越低

so, 单元测试很重要, 代码走查很重要,

黑盒白盒

黑盒测试(数据驱动测试), 将程序视为一个黑盒, 不用去理解程序的内部结构(测试目标与程序内部机制和结构完全无关), 构造测试数据(来源于软件规范), 检查输出是否符合预期.

白盒测试(逻辑驱动测试), 对程序的逻辑结构进行检查, 从中获取测试数据.

具体分类

单元测试

功能测试

系统测试: 能力, 容量, 强度, 可用性, 安全性, 性能, 存储, 配置, 兼容性, 安装, 可靠性, 可恢复性, 服务/可维护性, 文档, 过程

验收测试

安装测试

测试用例的设计

白盒测试:

逻辑覆盖测试, 从弱到强依次是

语句覆盖,每个语句至少执行一次
判定覆盖(也称分支覆盖) 每个判断都至少有一个为真和为假的输出结果
条件覆盖, 确保将一个判断中的每个条件的所有可能结果都至少执行一次

黑盒测试:

等价划分, 穷举输入是不可能的, 但是可以将其划分成有限数量等价类, 获取一个子集输入.
边界值分析, 输入和输出等价类中那些恰好处于/大于/小于边界的状态
因果图, 需求规格 -> 因果关系分析 -> 因果图 -> 测试用例
错误猜测, 基于直觉和经验的猜测

做测试还是做开发?

我做了一年又三个月测试开发, 后来转职Python后端开发了.

原因? 兴趣, 仅此而已.

如果更在乎创造一些东西，做开发.

如果更喜欢发现一些东西，做测试开发(现在似乎没有单纯的测试了吧?)

(开发就像工匠, 测试就如寻宝的)

开发主动权在手中，测试需要更多的博弈.

(这么看来测试要求更高一些, 哈哈)

每个开发都应该懂些测试的基本思想和原则

写出的代码会更健壮. 多注意测试, 可以给后续维护以及重构节省一大笔时间.

可以拿这本书作为入门.

其他

不管有没有专职测试, 单元测试都是必须的.(最好要有, 重构复杂项目的时候会发现感动的哭了)

如果有专职测试, 开发测试比应该蛮高的, 好钢用在刀刃上, 对重要项目进行测试, 另外留出时间研究自动化测试/回归测试/测试工具等, 以及对项目流程进行优化, 最大化提高生产力.

没有专职测试, 需要开发人员足够靠谱, 并且需要建立一套完善的生产部署流程, 监控机制, 以及用户反馈机制, 以小步快跑, 频繁发布的方式处理需求, 同时关注反馈.

千里行纪&工作三周年小结

Tue, 22 Jul 2014 08:00:00 +0800

旅行结束好几天了, 狂睡了一天, 刷了三天书(打算把之前没看的看咯), 花一下午去仲裁(囧)……突然想想, 该写写了, 合着之前拖了两周的三周年小结一起.

千里行纪

7月4日, 毕业工作三周年(三年前的7月4日, 在杭州, 入职第一天), 刚好, 也在不久前正式离职, 还没想好去做什么, 还有些问题没有想清楚, 所以选择出去走走.

第一站杭州, 打算随走随玩, 无计划无时限, 一路北上, 走完一站再想下一站去哪, 累了就打道回府.

然后, 带着一个kindle, 一本笔记, 一个背包, 出发.

最终, 7月4日出发, 17日归, 从深圳, 动车到达杭州, 然后汽车转战安徽, 西递+黄山, 然后去了趟南京, 再转高铁到济南, 回学校逛了逛, 觉得累了, 买了张机票飞回来, 好好地睡了一整天.

日期	步数	公里	备注
7.4	3804	2.4	动车
7.5	31823	23.3	西湖, 曾经工作/住的地方
7.6	24202	17.2	再次西湖
7.7	14899	11.1	淘宝城/浙大
7.8	18180	13.3	灵隐龙井九溪六和塔
7.9	9071	5.9	屯溪/西递
7.10	24186	15.9	九龙瀑布/黄山后山
7.11	12586	6.9	下山/天都峰/南京
7.12	29551	21.2	玄武湖/中山陵
7.13	24232	16.9	明孝陵/总统府/南京大屠杀遇难者纪念馆/夫子庙/夜游秦淮
7.14	19112	15.3	高铁/经十路
7.15	23788	17.3	黑虎泉/泉城广场/趵突泉/大明湖一半/山大中心校区
7.16	19547	14.1	解放路/山大路/中心校区/大明湖另一半/齐鲁软件学院
7.17	4051	3.2	飞机
总计	259032	184

耗时13天, 行程应该有2800公里, 步行259032步, 共184公里, 平均每天14.1公里, 拍了1863张照片. 走最多的一天是到杭州第二天逛西湖, 原来每周骑车绕没觉得多远, 这次踏踏实实逛了一圈, 着实累, 要是车子还在就好了. 第二天陪同事再逛, 不过路线不同, 囧. 最累的一天是爬黄山, 整整一天都在爬台阶……第二天下山也累, 不过下山顺带爬了下天都峰, 不虚此行.

到了四个地方, 感受了四种不同的生活节奏.

杭州, 很熟悉怀念的感觉, 慢节奏(我快十点到的杭州, 一如既往, 大街上一片漆黑, 店基本关了, 一个人走了一公里多, 有点类似以前加班下班后回家的感觉)/美食(复习了三天外婆家, 没复习完…)/美景无限, 适合生活的地方, 记得在杭州的时候天天把景区当后院逛, 每次骑车冲山出来后, 都要惯例绕西湖一圈, 坐一坐, 然后会公司蹭水, 再回家歇着. 这次, 走过了西湖, 走过了龙井, 到之前工作的地方, 到之前住的地方, 行走, 回忆.

去黄山前先去了西递, 大巴转小车, 彻彻底底在农村住了一晚. 不记得已经有多少年, 没有感受到泥土的气息了, 或许从高中外出求学开始. 水墨画的景致, 典型的农家, 荷塘月色蛙鸣, 八九点基本都熄灯了, 走在青石小巷里的感觉, 很宁谧安定.

黄山, 值得一爬, 记忆里爬泰山就是爬台阶去了, 黄山还好. 黄山从后山上的, 早上三个小时爬了趟九龙瀑布, 刚到后山山口, 果断下山寄存了大部分东西吃了顿午饭再坐车到山口开始爬(好重, 差点给跪了).晚上订的宾馆床位略坑, 没睡好, 另外日出没看到…..下山爬天都峰, 体验了一把在云端的感觉, 陡且险, 顿觉不虚此行.

南京, 六朝古都, 下了黄山之后大巴当晚到, 地图一查找了个交通方便的地方住下了, 后来才发现那是南京最繁华的地方. 第二天, 一个人背着包带着相机, 雨中漫步玄武湖, 是周六, 但是好像没什么人, 沿湖边慢慢行走, 后来上了古城墙, 走了一段, 发现没人了, 整个城墙视野里就我一个人, 坐了很久才下来.然后去了九华山公园, 玄奘寺, 午间吃了顿热腾腾的南京汤包(很赞, 对我胃口), 还没热乎走几步, 被倾盆暴雨淋了个透心凉, 回酒店洗洗, 穿着拖鞋再出发, 中山陵. 第二天, 明孝陵/总统府/南京大屠杀遇难者纪念馆/夫子庙/夜游秦淮, 可能是住的地方的问题, 没感受到这个城市真正的生活气息(新街口下面地铁人来人往, 刚到的时候被吓到了, 这人也太多了吧….).

济南, 熟悉而又陌生的城市, 记得七年前北上来到这个城市. 呆了近四年, 时隔三年, 再次回到这座城. 刚下车, 很热, 非常热……在体育馆边坐了会, 昏黄的路灯, 旁边是繁忙的立交桥, 行人, 纳凉的大爷大妈, 感受了下这里的生活气息. 空气不是很好, 但是很熟悉, 熟悉的地名, 街道名, 公交线路. 最后一天, 回软件学院看了下, 听说要撤并, 不知道下次来了还在不在. 走在之前上课, 上自习, 吃饭, 图书馆, 实验室, 那些自己曾近踏足的路上, 感觉很奇怪. 很多东西没什么变化, 只有回忆, 景依旧, 人不在. 怀念自己上学的日子, 感叹那时不好好珍惜. 生活是把杀猪刀, 时间无情的推着我们前进.

以上差不多流水账的感觉, 后面是一些感受.

为何行走?

此次出行, 主要是, 一半, 走之前走过的路, 一半, 去几个新的地方. 想一些事情, 希望有些收获.

在南京的酒店里, 看电视, 听到了一首歌, «生来彷徨», 突然很有感觉.

生来彷徨, 小学, 初中, 中考, 到市里上学, 高考, 到山东上学, 到北京实习, 到杭州工作, 再到深圳, 一路过来, 发现在工作之前, 都是按部就班的走完了二十几年的路, 然后, 毕业进入社会, 选择权在自己手里, 突然某一天觉醒的感觉, 开始思考, 生活的意义, 如何选择, 彷徨迷茫, 不断行走与思考, 然后做一些或对或错的决定, 一路前行. 人生是一场单程票的旅行, 在一次次决定中, 我们在一个个岔路口选择下一段旅程, 最终到达终点.

为什么要行走? 为什么要旅行? 或许是我们在寻找些什么.

其实, 旅行, 远远没有宅在家里好吃好喝好玩, 行走, 往往就是一趟趟自虐的过程, 例如, 爬山…爬山是对自己体力,耐力,意志力的一次次挑战…每次爬山途中, 不上不下累得要死都告诉自己, 下回老子再也不来了, 但是, 每次依旧会乐此不疲.

但是, 依旧要旅行, 要行走, 特别是当你有些东西没有想明白的时候, 在自己固有的环境里, 在自己熟悉的生活模式和节奏里, 是很难想清楚的. 而在旅途中, 新的环境, 不同的人, 不同的事情, 飞快飘过的景物, 飞快发生的事情, 身体的极度劳累, 很多想法会进入大脑, 你开始意识到一些东西: 我拥有什么? 我又欠缺什么? 我该珍惜些什么? 什么地方好, 什么地方不好? 为什么? 慢慢地, 获得一些观点, 得到一些结论, 有些初步的想法. 这或许就是旅行的目的.

行走, 不只是为了拍照, 哈哈

放慢脚步, 感受生活

这次从走过之前走过的很多路, 突然发现, 过去的生活, 似乎太快了, 行色匆匆, 短短三年, 从指尖流逝, 似乎很少刻意觉察到, 然后慢下来, 感受下生活中点点美好. 这跟逛西湖类似, 以往骑车逛的时候, 一圈, 一小时不到, 效率杠杠的, 但是匆匆而过, 固定的线路, 在固定的几个地方停留坐坐, 看到那些熟悉的景色. 靠双腿行走, 却又是不同的感觉, 慢慢前行, 一步步丈量, 往往会发现很多之前没看过的东西, 曲径, 柳暗花明, 如果一直骑车, 永远不会看到这些.

so, 让自己成长强大, 可以更高效地搞定工作/学习等等那些事情, 让生活慢下来, 好好地感受生活. e.g. 我写这个脚本, 只为了以后每天可以省五分钟出来发发呆, 哈. 另外不要让自己陷入一种模式, 例如周一-周五+周六周日=一周=7天, 认认真真过好每一天, 不要被模式限制了, 过得充实些, 去热爱一些东西.

关于世界的猜想

有时候走着走着发现一个人都没有, 会想下

其实, 世界的本质就是一个系统, 你自个就是一个进程, 你看到的整个世界都是模拟出来的, 你跑到这个地方之所以看不到人, 是因为你跑太快了, 系统只来得及初始化地方, 还来不及初始化 NPC, 没给你挂起已经不错了, 慢点走吧, 别剧情(主线支线)逻辑还没走就空跑结束了……^_^

你想要的生活是什么?

这次出行, 看了 N 本知乎周刊, 一本小说«陆犯焉识», 半本«明朝那些事儿».«陆犯焉识», 有之前看«平凡的世界»的感觉. 然后, 有一个下午, 坐在杭州的马路牙子上, 看着夕阳余晖下, 马路边的车流人流.(上一次这么干好像是和在庐山下和景元邪真坐在马路边) 然后, 在黄山下, 一个小饭店里, 看着路口人来人往, 这里人们的生活, 还有游客. 然后, 刚到南京, 下地铁到了地下步行街, 穿越, 匆匆而行的人们. 到了济南, 又在马路牙子上坐了一会, 昏黄的路灯.

每个人有自己的生活, 我们生活在自己意识里的世界里, 抛却自己朝九晚五的日子, 到大街上看看, 并不是每个人的生活方式和你一样. 同时, 不要用自己的评价体系去评价别人的生活, 活得好不好, 快不快乐, 幸不幸福, 并不是你能评价的, 与你无关, 很多东西, 我们往往都只看到了表面, 按照自己的思维体系去判断, 但是, 很多事情, 都跟喝水一样, 冷暖自知.

感同身受, 大部分都是扯淡的, 很多时候, 只有亲身体验才知道.

很多时候, 我们生活在"大家"的评价中, 很多时候, 我们追求的是"大家"的"成功", 很多时候, 我们去做"大家"都做的事情.

并不是说"大家"的就是错的, 而是, 我们往往很难独立地去思考, 自己真正想要的是什么? 很容易陷入到"别人的眼光"和"大家的看法"里面.

天龙八部, 悲剧在于"求而不得", 但是"求啥得啥"或许就不是生活了, 人总要有点追求的吧, 追逐自己想要的.

但是, 这或许不重要:), 有时候想多了反而迷惘(好吧, 唉).

It’s easy to find out what you don’t like, but it’s hard to figure out what you really want.

so, 你想要的生活又是什么样的呢?

最近的感受时, 慢慢接受自己是一个怎样的人了, 不再为了"改变"而改变, 心安理得地做自己, 顺着自己的心意. be cool about it. 改变, 只因自己想变.

我自己, 似乎还是飘了太久了, 现在似乎该停下来, 思考下这个问题了. 有些初步的想法了.(«平凡之路»单曲循环……)

PS. 推荐一部电影«奇怪的她».

该以怎样的心态去看待一切

性格内向, 情商极低(低到自己都有些鄙视的地步), 很多时候思维相对偏激, 虽然不是处女座, 但是推崇完美主义(完美主义害死人), 所以, 总成了对待事物, 总容易形成两极分化. 好的东西偏执地喜欢, 不好的东西(自己的看法), 总是避免去了解接触.

总之, 看待事物心态不够open, 太过偏执. 在有些事情上, 属于冲动型, 快刀乱麻一路到黑, 在有些事情上, 容易犹犹豫豫婆婆妈妈, 纠结一些不该纠结的东西.

不要太过苛求完美, 就像你不可能把所有景点的路遍历一遍(深度优先广度优先都不行), 只能, 选择一条最优的路线.

人生太短, 心态放开, 不要浪费时间.

围城

围城, 围城啊.

三年多过去了, 这次一路, 见到了很多同学, 朋友, 曾经的同事, 城市不同, 职业不同, 每个人的境遇也不同, 都变化蛮大, 回头看看自己, 似乎没什么变化, 迄今了然一身, 总是自嘲自由.

生活就是座围城, 不管城里城外, 做好自己的选择, 走好自己的路, 也就够了吧.

记录&早起&读书

似乎该养成, 记录的习惯.

之前只会到特殊的日子, 写写小结, 前阵子开始用DayOne, 变得好些了.

很多东西, 过了, 没有记录. 美好或不美好, 酸甜苦辣, 烈日或阴雨.

虽然一直号称记忆力不错, 但是, 可以按秒按天按月按年去衡量时间, 可以轻易的说出一个长度, 但是无法回顾, 那些值得记录的东西.

早起, 以前都是忙到半夜, 早上八点多起, 旅途过程中, 基本都五六七点就起, 发现一天变得很长很充实, 能走很多地方, 做很多事情, 回来到现在, 生物钟一直保持吧.

读书, 身体和灵魂, 总有一个在路上, 如果不在途中,就多读些读书吧.

不要一个人旅行

一个人的旅行真的很累……

I don’t want to walk alone anymore!

工作三年小结

好吧, 我工作三年了, 很多时候不大想承认哈.

额, 三年了.

经验之谈, 扯一些有用没用的

经验很重要, 要学会积累

记得, 在学校和刚毕业那会, 对"xx年工作经验"总是嗤之以鼻, 不认为很重要, 但是实际上, 或许对于天才型的人是这样的, 但是大部分人都是平凡的, 我也是, 经验很重要.

三年, 见过一年有 N 年经验的(加班), 也见过 N 年只一年经验的, 所以, 如何保持持续成长, 积累经验值很重要, 这跟你挂机在野外平砍小怪或者开挂刷副本是一个道理, 后者给力很多, 当然, 跟环境和团队也有一定关系.

但个人的成长, 主要还是跟自身相关性最大, 自己需要为自己负责.

效率&工具

有一段时间, 我在追求高效, 应该有小半年吧, 那段时间研究了下工作中自己的瓶颈所在, 从前辈那里取得一些真经, 同时也看了很多时间管理的东西, 研究了下 GTD, 各种快捷键, 快捷工具, 很庆幸, 那时候也顺带深入搞了把VIM和Shell. 然后逐渐形成了自己的工作方式和风格.

后来又有段时间, 大概三个月吧, 彻彻底底的工具党, 试用各种系统, 各种浏览器, 各种编辑器, 各种 GTD 工具, 还有快速启动, 系统管理, 记录等等. 结果发现重心在工具而不是自己所作的事情上了.

后来的后来, 脱离了工具党(可能是某一天悟了吧), 不在花时间在各种工具上, 工具只是工具, 在精不在多, 找到了适合自己的就行, 集中一段时间研究下适合自己的工具还是值得的, 将受益终身(e.g. markdown/VIM).

first, 你必须在平时了解一下自己的痛点(例如以事不过三的原则, 当一个事情重复三次, 就要注意了)

然后想办法解决之.

学会从一些渠道知道一些优秀的工具, 然后选择其中的佼佼者, 以开放的心态去试用, 找到适合自己的, 然后花点时间研究下, 事半功倍

唯一的目标: 事半功倍. 所以不要care什么编辑器之争, 语言之争(下一个谈).很浪费时间.(当然, 选择时候要花点时间对比的, 但不要去争论)

语言

在毕业前, 连写了三年多Java, 当时一直认为毕业后从事Java相关的工作, 后来工作中自学了Python, 然后转职成了Python后端, 间带学习了下Golang, 今年业务需要认真学了一把之前偶尔要用到的JavaScript. 最近离职间隙, 打算重新捡一下Java, 认真学习下C.

Python是世界上最好的语言……

语言, 你可以选择自己喜欢的语言, 但是不要局限自己不去学习其他的, 起码, 要有第二门辅助性质的语言, 然后第三门, 第四门……一年一门, 不算过分吧?

每种语言的思维模式都不同, 尝试去学习和使用, 有利无害.

当你深入学习一门语言后, 再学习其他语言其实是非常快的, 很多东西都是相同的.

基础知识很重要

算法/数据结构/IO 模型等等, 很多基础的东西, 例如算法, 可能平时用不到, 但这并不意味着不需要去学习, 基础很重要.

> @左耳朵耗子: 很多人都并不知道，哪些知识是用来生存的，哪些知识是用来改变命运的//@左耳朵耗子: “学好英文，算法，系统原理，基础知识没用啊？反正工作中又用不到！”，有这样想法的人不在少数，这个想法相当务实。同理，对于一个人来说，初中毕业所掌握的知识对于生存来说就够了，也没必要上什么高中和大学了。当然，我们都知道只有初中毕业的人在这社会上会是啥样。这对于程序员也是同理。

微博&RSS&知乎&笔记&博客&github

前三者是输入, 后三者输出

很多人不用微博, 但是微博作为我获取信息的主要渠道, 每天还是会花时间刷一刷的, 不停地关注/取关, 最终形成稳定的信息渠道. 例如上面那条微博, 你能获取到很多东西, 而不是把自己困守在一个狭窄的世界.

然后就是RSS订阅和知乎.

从这些渠道, 看到了很多好的文章, 好的资源, 好的工具

自从开始用markdown后, 所有笔记从原先doc开始逐渐全部转换成markdown了, 分门别类, 应该有上千了. 定期梳理, 主要用于在学习某些新的东西时, 能获取最优的学习路径, 或者, 能够在短暂时间内搜索到自己曾经记录的东西.

笔记多了, 定期总结汇总, 维持规模, 其中一些梳理出来, 变成了blog.

github和bitbucket作为开源和私有的代码库, 写一些东西, 存一些东西, 关注一些东西.

读书

单反穷三代, kindle富一生.

kindle成为了我今年最值得购买的东西.

非技术书, 可以往杂里读, 还可以研究一些自己感兴趣的东西, 或者方法论等等.

然后就是技术书籍, 基本都买了纸质版的, 迄今不习惯电子版的, 因为要做好多笔记, 反复看, 或者脱水.

对于知识体系的系统构建, 以及深入, 主要还是靠书本, 网络的很多东西作为补充.

三年间, 感觉自己变化不大, 性格上, 依旧内向, 依旧是我, 很多东西不会改变. 生活上, 依旧单身(人艰自拆, maybe I need to think about: 择一城终老, 遇一人白首).

三年间, 感觉自己变化蛮大的, 从菜鸟开始慢慢蜕变了, 有了独立的意识, 有了目标, 开始尝试去挣脱一些东西, 追求一些东西, 去掌控一些东西. 最大的变化, 还是从无意识 -> 有意识了.

三年间, 形成了自己的做事方法和风格, 有了一些准则, 有了一套工具栈, 开始完善自己的知识体系.

三年间, 36个月, 在两个城市生活过, 跳过一次槽, 涨过五次薪, 工资翻了三倍不到, 拿过三次年终奖, 当然, 其中一次只有1000块(冲动的后果, 囧).

三年间, 经历了两家公司, 很庆幸遇到了两位很nice的老大, 以及很多给力的同事, 在他们的帮助下, 一步步成长, 很感激大家! Always, Thank you for everyting.

三年间, 感觉自己还是对得起"靠谱"二字, I hope I didn’t make anyone disappointed, If I did, I am sorry.

三年间, 经历了很多.

时间飞逝, 人生又有多少个三年.

且行(码)且珍惜

(感叹完毕!)

关于未来

未来是多远?

未来一周, 刷书, 好多没看的, 看了, 该留留, 该出的出, 堆得太多压力大.

未来两周到一个月(or 两个月?), 更新简历, 开始找工作了, 深圳或者杭州, 创业团队or BAT, 寻找后端开发方面的工作, 希望去做一些有价值的事情, 给力的产品

未来一两年, 继续走技术这条路吧, 当前目标:Linux后端全栈, 长期的目标是, 成为某一方面的技术专家or系统架构师(需努力).

工作上, 快起来, 生活上, 慢下来.

要考虑更多的事情了.

我在三年前毕业的博文里面写的:

未来，不敢说太远，今后五到十年，好好努力吧，好好奋斗

好吧, 现在才过了三年, 仍需努力.

最后, 前不久看到的一句话

不要放任梦想, 而要把它当做一种习惯去培育 –拉里佩奇

诸位共勉.

2014-07-22 于深圳

wklken

简单搜索系统组成总结

Mon, 09 Jun 2014 08:00:00 +0800

最近在进行离职前交接工作了, 对之前做的一些东西也大概进行了下简单总结.

今天整理了下, 搜索系统组成简要描述, 一些思想, 不涉及太多具体实现.

这套系统从开始设计到最终完成, 前前后后花了3个月的样子(计算所有时间投入), 也算是做得感觉比较完善的一套系统.

上线接近一年, 支持快玩游戏搜索业务(快玩盒子/快玩网站/移动端等), 系统每天百万级的搜索(峰值在250w左右, 应用层两台机器负载均衡, 单机核心层, 单机引擎), 很遗憾, 由于业务所限, 一直没有看到这套系统能支持的量上限, 即使在峰值, 核心层qps大概也才50左右, 预计搜索量到千万级应该没什么压力, 当然, 优化的余地还很多.

外面正在狂风骤雨, 开始吧

目标

当系统数据达到一定量时, 搜索就成为了除类目以外的第二大入口.

更好的搜索结果(指标: 召回率, 转化率, 排序效果)
更好的用户体验(下拉提示点击率,相关搜索准确率等)

搜索流程

用户在输入框输入关键词, 此时输入框会下拉提示一些词, 用户可以选择进行搜索
用户点击, 进行搜索, 前端调用搜索接口

应用层

 3.1 请求关键词改写, 获得改写后词
 3.2 查询缓存是否存在, 存在直接返回缓存内容. 此时, 会记录搜索日志
 3.3 不存在缓存, 调用解析输入, 调用核心层接口

核心层, 调用引擎接口, 获取搜索结果, 并整合信息, 返回应用层
应用层, 获取结果, 此时根据需要, 可能调用相关搜索和热门词服务, 获取必要信息, 最终进行页面渲染, 记录日志, 返回给客户端

系统结构图

实现: java(solr)只需配置 + python(所有服务) + golang(suggestion)

系统组成(简单描述)

对外服务

搜索整体系统,对外提供服务包括

基本搜索服务用户输入query, 系统返回筛选并且排序后的结果, 在前端进行展现
下拉提示服务用户在输入框输入query时, 下拉框根据输入提示搜索关键词, google/baidu的搜索框
相关搜索服务在搜索结果页,根据用户所在的系统(客户端/移动端/网站等)以及关键词,提示搜索query相关的搜索
热门搜索在某些业务中,或者前端,展示热门搜索关键词
关键词改写对用户输入关键词进行改写, 以获取更好的搜索结果, 或者进行关键词纠错, 转换

缓存

缓存在整个搜索系统中起到很关键的作用, 各个服务都需要使用缓存进行优化

系统使用memcached/redis分别进行处理. 整个搜索中用得最多的是下拉提示suggestion, 用户输入关键词整个过程中存在变动都会发起一次请求.

业务(应用层+核心层)

核心层, 提供单一职责, 灵活且性能足够的接口

应用层, 根据不同系统的业务需求进行编写, 调用核心层接口获取数据, 整合搜索结果, 并进行展示渲染

元信息(数据元信息+排行信息等)

业务本身的核心数据, 包含元信息, 元信息中只有少部分需要导入引擎, 建立索引 or 存储, 元信息中还可能包含排序相关的信息, 例如评分等

排行信息, 主要来自后端统计系统

引擎

对元信息, 进行分析并处理, 建立索引, 存储内容

并提供搜索, 可以决定排序规则

日志系统

负责记录各个服务的日志, 用于统计以及其他服务的数据挖掘

可以记录每次搜索的时间,用户,关键词,改写词,是否有结果,结果信息, 翻页信息等等

算法模块

对记录日志进行分析, 使用算法生成其他服务需要的数据

报告系统

对日志进行统计, 计算搜索pv/uv, 无结果率, 搜索关键词排行, 下拉提示点击率等等

用于关键性指标的统计, 方便针对性优化

接下去, 分块简要说明下

搜索服务-数据层

数据存储跟各自业务有关系, 信息录入渠道主要是运营录入或者抓取导入等, 存储使用mysql/postgresql等数据库

rank data 主要是由日志系统统计出一些根据涉及排序相关的数据, 例如用户点击次数, 玩次, 评分等等, 会直接影响到结果排序

注意, 由于这些数据都会存在变更, 所以, 需要存储update_time, 用于引擎增量建立索引.

搜索服务-引擎

实现上, 使用的是开源的 apache solr, 版本4.5, 刚才看了下最新版到了4.8了.

曾经一度想自己去实现, 结果发现复杂化了, 系统设计中, 切忌把实现问题的手段当做问题本身去处理.

还有很多同类引擎, 可以去对比下.

选中solr的原因: 简单

输入, 足够简单的数据提供方式, 通过配置文件定义数据库及sql等信息, 就可以建立元数据到引擎数据的关系, 且有接口可以方便地进行全量/增量更新
配置简单, 可以配置索引处理方式, 例如中文分词,拼音搜索等, 可以配置不同接口的排序, 可以配置缓存等. ps: 拼音搜索可以使用EdgeNGram索引处理实现.
输出, 足够强大的查询接口

对于引擎, 很重要一块是搜索结果排序, solr 可以很方便地支持自定义排序, 可以依赖于输入数据中的排序字段, 进行公式计算, 得到最终的加权和, 用于决定排序. 这里的公式需要针对业务中影响排序的因素进行分析, 然后不断调整因素的权重, 得到最终的排序效果.

如果要进行一些其他处理, 可以在应用层或核心层进行额外处理.

下拉提示服务

前后做了两个版本, 一个版本基于分词-统计-cache实现的, 后面一个版本基于 trie树-cache实现.

元信息直接导出, 以游戏为例, 游戏名+图标+类型+玩次等信息

主要是针对游戏名进行处理:(原词+拼音+拼音首字母)

植物大战僵尸 -> [植物大战僵尸, zhiwudazhanjiangshi, zwdzjs]

然后, 在内存中建立前缀树. 这里使用的是double-arry-trie实现

double-array-trie文章: What is Trie | An Implementation of Double-Array Trie

用户输入query, 没发生一次变化, 发送请求到下拉提示服务, 首先会去命中缓存, 未命中, 进入trie树搜索前缀, 获取此前缀所有后缀, 即获取提示关键词集合, 排序获取权重最高的进行返回(是这个流程, 但实际上没那么简单, 要考虑性能).

如果不开缓存，实时计算的话，对cpu占用率非常高，每次都要搜索trie树，所以开启了memcached外部缓存.

开源了一份, 但并不是线上的实现, 而是优化版本, 但是一直没有机会上到线上看下效果, 有兴趣可以看下 suggestion

关键词改写

关键词改写, 主要分成两类, 一类是输入关键字错误导致无结果(错别字/缺字/多字等), 另一类是输入关键字是业务上某些名称的别名, 系统内没有, 需要转换.

通过改写, 可以实现纠错以及转换的目的, 使用户能正确获取结果

关于纠错, 目前处理方式, 用户搜索关键词链, 处理成 [无结果词 - 有结果词], 另外还有用户下拉提示点击 [无结果输入词 - 有结果点击词], 然后进行统计, 根据一系列规则进行筛选, 获取改写列表.(目前是基于规则的, 优化空间还很大)

关于业务上的改写, 需要提供入口, 提供给运营人员针对一些术语进行改写, 例如[gta -> 侠盗猎车手]

这个服务比较简单粗暴, 计算完成后直接将键值对刷入缓存, 对外提供服务.

关键词改写需要进行持续的优化, 定期获取新的日志进行批量处理, 加入列表. 优化余地很大, 可以有效降低无结果率.

统计

主要对每日的搜索日志进行统计, 得到两部分信息:

报表数据: 不同平台不同渠道的每日pv/uv, 无结果率, 下拉提示点击率等
排行数据: 不同纬度下搜索排行, 用于反向作用于搜索引擎排序

一些坑

系统使用的memcached集群作为缓存, 遇到一些坑, 例如key最大长度250, key不能包含空格和控制字符, 存储数据最大1M. 即, 默认对用户的输入不信任(看日志才知道有多少奇葩的搜索query). 切成redis或许会好一些.
关于备份. 由于业务初期流量一直不大, 所以除了应用层使用nginx做负载均衡外, 核心层和solr都使用单机实例. 带来的问题是, 虽然整体负载不高, 但是没有备份, 出现过一次solr引擎挂到导致搜索整体失效30分钟的故障, 后面对每个单机服务都进行了服务备份, 失效启用.
需要对整体系统进行监控, 使用sentry和statsd, 可以实时监测到流量变化以及程序错误.
日志很重要, 要针对自己需要了解的指标以及需要统计分析的字段, 设计尽可能完整的日志记录.

一些感想

需要确认整体目标, 然后建立关键性指标, 实现基础方案, 上线, 并持续地关注数据, 分析日志以及bad case, 然后进行优化, 观察指标变化. 记得系统最初的召回率84%, 后来一步步提升到了92%. 这是一个长期的, 不断优化的过程.

很多东西, 都需要自己一步步去摸索和尝试.

当然, 这只是一个小型的搜索系统, 其中每一个模块都可以针对性地扩展和优化, 使用更好的算法, 达到更好的效果.

It’s simple, but it works, that’s enough:)

系统总是跟随业务逐渐成长变化的, 很可惜, 业务夭折, 这个系统可能失去了在这里继续进化的可能.

希望提供一些可供大家借鉴的方法. That’s all.

先这样吧

wklken

2014-06-09 于深圳

JavaScript学习补充

Sun, 25 May 2014 08:00:00 +0800

以下笔记全部摘录和整理(缩减)自互联网文章, 太多了已然没法找到对应作者, 在此感谢分享者>)

null 和 undefined

Undefined相当于一个变量并没有明确的被赋值(是否被赋值, 可能无心忽略, 逻辑问题) JS的怪异之处就在于undefined真的是一个可以使用的值。

> var foo;
> foo
undefined
同理，当缺失参数时 JavaScript 会分配一个 undefined：

> function id(x) { return x }
> id()
undefined

a = 1;
a !== undefined // true

a = undefined
var b
a === b //true

Null相当于变量被明确指定了没有值，而不是由于意外的原因被忽略掉了(赋值null, 正当逻辑)

参与运算

JS的null如果进入运算，真的会被解析成为0或false：

(1 + null) # 1 (1 * null) # 0 (1 * null) # Infinity

undefined进入运算，一律得到NaN：

(1 + undefined) # NaN (1 * undefined) # NaN (1 / undefined) # NaN

逻辑判断

null和undefined逻辑判断时都认为是false。

只用一个判断，就可以同时检验这两项是否为真:

//也会把 false, -0, +0, NaN 与 '' 当成“空值”
if (v) {
    // v 有值
} else {
    // v 没有值
}

但是如果碰到大坑==的时候

var foo;
console.log(foo == null); // true
console.log(foo == undefined); // true
console.log(foo === null); // false
console.log(foo === undefined); // true
console.log(null == undefined); // true

好的做法, 一律使用===

判断一个量已定义且非空，只使用：if (a !== null && a !== undefined)。

=== 和 ==

1.==用来判断两个值是否相等

当两个值类型不同时，会发生自动转换，得到的结果非常不符合直觉，这可能不是你想要的结果。

"" == "0" // false
0 == "" // true
0 == "0" // true
false == "false" // false
false == "0" // true
false == undefined // false
false == null // false
null == undefined // true
" \t\r\n" == 0 // true

2.===

类型+值比较

“如果两边的操作数具有相同的类型和值，===返回true，!==返回false。"——《JavaScript：语言精粹》

最佳实践:

任何时候在比较操作中使用 === 和  !==

json操作

var person = {name :'Saad', age : 26, department : {ID : 15, name : "R&D"} };

var stringFromPerson = JSON.stringify(person);
/* stringFromPerson is equal to "{"name":"Saad","age":26,"department":{"ID":15,"name":"R&D"}}"   */

var personFromString = JSON.parse(stringFromPerson);
/* personFromString is equal to person object  */

to string

var obj = {
    name: 'myObj'
};

JSON.stringify(obj);

函数对象及匿名函数

1.函数对象赋值

var slice_func = [].slice
//slice_func()

var a = function() {
};
// a()

var a = {
    fun : function() {
    };
}
// a.fun()

someElement.addEventListener("click", function(e) {
    // I'm anonymous!
});

以及

var f = function foo(){
    return typeof foo; // foo是在内部作用域内有效
};
// foo在外部用于是不可见的
typeof foo; // "undefined"
f(); // "function"

匿名函数

from

var name = 'Chris';
var age = '34';
var status = 'single';
function createMember(){
// [...]
}
function getMemberDetails(){
// [...]
}

var myApplication = function(){
var name = 'Chris';
var age = '34';
var status = 'single';
return{
createMember:function(){
// [...]
},
getMemberDetails:function(){
// [...]
}
}
}();
// myApplication.createMember() and
// myApplication.getMemberDetails() now works.

最佳实践

1.定义多个变量时，省略var关键字，用逗号代替

var someItem = 'some string';
var anotherItem = 'another string';
var oneMoreItem = 'one more string';

更好的做法

var someItem = 'some string',
    anotherItem = 'another string',
    oneMoreItem = 'one more string';

2.谨记，不要省略分号, 不要省略花括号

省略分号,可能导致更大的,未知的,难以发现的问题

var someItem = 'some string'
function doSomething() {
return 'something'
}

更好的做法

var someItem = 'some string';
function doSomething() {
return 'something';
}

3.使用{}代替 new Ojbect()

在JavaScript中创建对象的方法有多种。可能是传统的方法是使用”new”加构造函数，像下面这样:

var o = new Object();
o.name = 'Jeffrey';
o.lastName = 'Way';
o.someFunction = function() {
console.log(this.name);
}

更好的做法

var o = {}; //空对象

var o = {
name: 'Jeffrey',
lastName = 'Way',
someFunction : function() {
    console.log(this.name);
}
};

只要把多个全局变量都整理在一个名称空间下，拟将显著降低与其他应用程序、组件或类库之间产生糟糕的相互影响的可能性。——Douglas Crockford

4.使用[]代替 new Array()

var a = new Array();
a[0] = "Joe";
a[1] = 'Plumber';

更好的做法：

var a = ['Joe','Plumber'];

5.typeof判断

typeof一般只能返回如下几个结果：number,boolean,string,function,object,undefined

expr:

typeof xx === ''
typeof xx !== ''

e.g.

// Numbers
typeof 37 === 'number';
typeof 3.14 === 'number';
typeof Infinity === 'number';
typeof NaN === 'number'; // 尽管NaN是"Not-A-Number"的缩写,意思是"不是一个数字"

// Strings
typeof "" === 'string';
typeof "bla" === 'string';
typeof (typeof 1) === 'string'; // typeof返回的肯定是一个字符串

// Booleans
typeof true === 'boolean';
typeof false === 'boolean';

// Undefined
typeof undefined === 'undefined';
typeof blabla === 'undefined'; // 一个未定义的变量,或者一个定义了却未赋初值的变量

// Objects
typeof {a:1} === 'object';
typeof [1, 2, 4] === 'object'; // 使用Array.isArray或者Object.prototype.toString.call方法可以分辨出一个数组和真实的对象
typeof new Date() === 'object';

// Functions
typeof function(){} === 'function';
typeof Math.sin === 'function';

typeof null === 'object'; // 从JavaScript诞生以来,一直是这样的.

6.三元运算符 :强大且风骚

语法

expression ? xxx : yyy

bad

var direction;
if(x < 200){
  direction = 1;
} else {
  direction = -1;
}

good

var direction = x < 200 ? 1 : -1;

7.使用逻辑 AND/OR 做条件判断

var foo = 10;
foo == 10 && doSomething(); // 等价于 if (foo == 10) doSomething();
foo == 5 || doSomething(); // 等价于 if (foo != 5) doSomething();

//默认值
a = b || 'default'
return b || c || d > 1 ? 0 : 2

8.给一个变量赋值的时候不要忘记使用var关键字

给一个未定义的变量赋值会导致创建一个全局变量。要避免全局变量

9.自我调用的函数

自调用匿名函数（Self-Invoked Anonymous Function）或者即时调用函数表达式（IIFE-Immediately Invoked Function Expression)。这是一个在创建后立即自动执行的函数

(function(){
    // some private code that will be executed automatically
})();

(function(a,b){
    var result = a+b;
    return result;
})(10,20)

10.避免使用 eval() 和 Function 构造函数

Eval=邪恶, 不仅大幅降低脚本的性能（译注：JIT编译器无法预知字符串内容，而无法预编译和优化），而且这也会带来巨大的安全风险，因为这样付给要执行的文本太高的权限，避而远之

使用 eval 和 Function 构造函数是非常昂贵的操作，因为每次他们都会调用脚本引擎将源代码转换成可执行代码。

var func1 = new Function(functionCode);
var func2 = eval(functionCode);

11.避免使用 with()

使用 with() 会插入一个全局变量。因此，同名的变量会被覆盖值而引起不必要的麻烦

12.脚本放在页面的底部

记住——首要目标是让页面尽可能快的呈献给用户，脚本的夹在是阻塞的，脚本加载并执行完之前，浏览器不能继续渲染下面的内容。因此，用户将被迫等待更长时间

13.避免在For语句内声明变量

bad

for(var i = 0; i < someArray.length; i++) {
var container = document.getElementById('container');
container.innerHtml += 'my number: ' + i;
console.log(i);
}

good

var container = document.getElementById('container');
for(var i = 0, len = someArray.length; i < len;  i++) {
container.innerHtml += 'my number: ' + i;
console.log(i);
}

14.给代码添加注释

// 循环数组，输出每项名字（译者注：这样的注释似乎有点多余吧）.
for(var i = 0, len = array.length; i < len; i++) {
console.log(array[i]);
}

15.instanceof

instanceof 方法要求开发者明确地确认对象为某特定类型

var oStringObject = new String("hello world");
console.log(oStringObject instanceof String);   // 输出 "true"

// 判断 foo 是否是 Foo 类的实例
function Foo(){}
var foo = new Foo();
console.log(foo instanceof Foo)//true

// 判断 foo 是否是 Foo 类的实例 , 并且是否是其父类型的实例
function Aoo(){}
function Foo(){}
Foo.prototype = new Aoo();//JavaScript 原型继承

var foo = new Foo();
console.log(foo instanceof Foo)//true
console.log(foo instanceof Aoo)//true

16.apply/call

someFn.call(this, arg1, arg2, arg3);
someFn.apply(this, [arg1, arg2, arg3]);

apply

Function.apply(obj,args)方法能接收两个参数

obj：这个对象将代替Function类里this对象
args：这个是数组，它将作为参数传给Function（args-->arguments）

call

Function.call(obj,[param1[,param2[,…[,paramN]]]])
obj：这个对象将代替Function类里this对象
params：这个是一个参数列表

使用哪个取决于参数的类型

扩展阅读

书籍

Limu：JavaScript的那些书 mozilla js文档

编程风格

Javascript编程风格

this

完全理解关键字this | 详解JavaScript中的this | 解密 JavaScript 中的 this | JavaScript中this的工作原理以及注意事项

性能

编写快速、高效的JavaScript代码

Javascript执行效率小结

JavaScript的性能优化：加载和执行

闭包

学习Javascript闭包（Closure）

模块化编程

Javascript模块化编程（一）：模块的写法

深入研究JavaScript的Module模式

为现代JavaScript开发做好准备

面向对象

Javascript定义类（class）的三种方法

JavaScript面向对象15分钟教程

如何编写可维护的面向对象JavaScript代码

拥抱原型面向对象编程

Javascript 面向对象编程 | 再谈javascript面向对象编程

全面理解面向对象的 JavaScript

JavaScript原型和继承 | JavaScript中的原型和继承

事件

生动详细解释javascript的冒泡和捕获

DOM事件简介

你若触发，我就处理——浅谈JavaScript的事件响应

设计模式

console

通过console.table()做高级JavaScript调试

tools

JavaScript基础工具清单

给开发者提供的 35 款 JavaScript 图形图表库 + 百度图标库Echarts

其他

Responsive Javascript 是什么？

JavaScript 跨域总结与解决办法

Javascript的10个设计缺陷

从零开始写JavaScript框架（一） | 从零开始写JavaScript框架（二

我的mac app列表

Sat, 24 May 2014 08:00:00 +0800

我曾经说过, 买mac是2013年自己做的最正确的决定之一

转眼一年多过去了, mac为我节省的时间,带来的便捷,以及给自己工作和生活带来的变化是没法估量的

整理下自己app列表, 瞅了下连带系统自带的一共125个app

效率

Alfred 2

神器,不解释

DEVONthink Pro

资源素材收集整理分类, 知识管理

OmniFocus Pro

GTD

Vitanmin-R 2

番茄时间工作法

BetterTouchTool

触控板/鼠标功能扩展

Keyboard Maestro

键盘大师, 门槛较高

aText

关键字扩展 (准备尝试TextExpander)

Moom

窗口管理

ClipMenu

剪贴板

PopClip

类iphone选中工具,拥有很多给力的插件,例如打开选中下的链接

1Password 4

密码管理

Bartender

MenuBar管理

HyperSwitch

最好的切换工具(better than km or manico)

Manico

应用切换, 辅助

编辑器

MacVim

编辑器之神,不解释, 配置见 k-vim

Mou

markdown编辑

haroopad

markdown编辑

Sublime Text

源码查看

Chocolat

临时文件编辑

Day One

日记

iA Writer

写作工具,支持markdown

Atom

下一代编辑器,下了尝鲜

开发

iTerm

终端利器

Dash

文档速查

Xcode

写app用

CodeBox

代码片段

OhMyStar

github star项目管理

Gas Mask

host快速切换

浏览器及阅读

Google Chrome

一号浏览器

Firefox

二号浏览器

Safari

三号浏览器

Pocket

read it later

ReadKit

rss 订阅

Kindle

电子书

社交

QQ

常年挂机

RTX

内部交流

WeChat

微信,妈蛋这货不保存聊天记录

AliWangwang

淘宝

云

Dropbox

重要文件

Evernote

云笔记

百度云同步盘

资源文件

GTD

Wunderlist

记录待办事项

Fantastical

日历管理

Eggscellent

番茄钟

界面

Flux

色温调整

爱壁纸HD

壁纸管理

影音

MPlayerX

播放器

Xiami

虾米

diumoo

豆瓣

iTunes

自带

办公

Keynote Numbers Pages

三件套

XMind

脑图

Airmail

邮件

Swift Publisher 3

pages 增强

Balsamiq Mockups

原型图

系统工具

Parallels Desktop

虚拟机

Path Finder

增强finder

CleanMyMac 2

垃圾清理

Snip

切图

Folx 3 / Thunder

下载

Caffeine

保持屏幕常亮

Lock Screen Plus

锁屏

Keka

压缩解压

GoAgentX

科学上网

LICEcap

录屏

Better Rename 9

批量文件重命名

Gemini

重复文件查找

MacHider

文件隐藏

MagicanRest

休息提醒

smcFanControl

自动控制风扇

其他

LIMBO

一个很虐的游戏

读书笔记--你就是极客!软件开发人员生存指南

Sat, 03 May 2014 08:00:00 +0800

BeingGeek:The Software Developer’s Carrer Handbook

五一三天,读完五本书…..这本算是重读

写作风格类似<黑客与画家>

10分标准,打个7.5

个人职业生涯面临的种种境遇和问题:跳槽,面试,管理,招聘,危机处理,沟通,合作,团队建设,演讲,绩效考核等,甚至还有一篇是专门写给我们背后的支持者的(例如女朋友,如果有的话…..).

书上关于团队管理,沟通,换工作的几章,可以重点看下

里面包含了很多观点,隔一段时间来重看认识会有不同,摘录几点…..算是读书摘要吧

阅读时,要不断重复3个问题(明确方向)

1.我正在做什么?
2.我真正想做的是什么?
3.我在乎的是什么?我关心的是什么?

致胜之道

系统思维:

我们寻找"定义"来了解
"系统",以便找出
"规则",这样我们才能
明白下一步该做什么
并最终获得胜利

只要投入足够的时间和精力,是可以完全地认识系统的

麻烦的"人", 人总是会把事情搞砸,他们是系统故障的根源

提高胜率:为不可预测事件做好准备

只有自己,才能成就自己的事业.认为身边所有人都要对你的职业生涯负责的想法是错误的.

三要素

将职业发展与管理哲学归结为三要素

1.技术方向
最接近代码的人最有资格为工作设定技术方向
你才是代码的拥有者,你需要关心它,每天都要
你是否主动地确定产品的技术方向?

2.保持成长
不进则退,不胜则亡,成长的基本单位是知识
增长代表一种战略.可以学到更多,完成更多的工作,获得晋升,改善自己,并承担更多责任.
你是否明白要做的哪些事情才能一直成长?

3.交付工作
言出必行,兑现承诺,重视自己的信誉
你是否能按时完成工作?兑现承诺?言出必行?

工作之痒

检验:我满意现在的工作么?你对自己的工作有多投入?你的动机是什么?

不要在一气之下换工作.没有什么比愤怒更能让人失去理智.

你需要以自信的立场来考虑换工作.不应该是为了逃避一个错误.而应该是去迎接一个新的机遇.

关于移交工作:工作永远是做不完的,从来没有哪个时刻是适合辞职离开的

公司文化

如果想获得提拔,就要成功地满足某一群人的需求.

问题是,永远要想在管理着前面,

沟通

不要用借口来回答问题

每次开口,应该言之有物,在令人不安的沉默中,应该坚持这种观点,而不是把自己放在受害者的角度上寻求借口

处理危机

几点:

1.如果缺乏指引,人么会追随错误的导向

2.人们不停地讨论正在面对的危机,以互相提供群体治疗

3.每个人都想了解全部的真相

三场会议

1.一对一面谈
2.部门会议
3.成果检查会议

系统的游戏化

让某些事情变得有趣,积极参与

1.规则必须是明确的
2.规则必须是不可违反的
3.不到万不得已,不要拿金钱作为奖励手段

后巷桥牌

在工作中,应该和同事保持多近的距离?

彼此信任和尊重的团队会更加多产且高效.我们的目标不适合每个人都成为朋友,而是建立一组关系,这组关系中,我们互相相信对方是可靠地,诚实的,有能力的,有毅力的.

任务列表

每天的任务事项:

1.今天,必须今天完成的
2.稍后,不需要今天,稍后搞定即可
3.永不,我永远不会去完成这项任务

不需要等级结构,标签,不需要优先级,不需要设定日期.

保持极简

涓滴列表

坚持长期投入零散的时间,最后能做到的就远远超乎自己的想象.

例如:人,写作,读书….

充分利用零散时间

工具的狂热法则

合适的工具将使生产力指数增长

狂热法则:

1.貌似简单
2.不受工作场所限制
3.设计的目的都是免除重复动作
4.只做我让他们做的事情
5.只属于我自己
6.我的工具一直为自己的生存而战

面对责难

1.承认你搞砸了这个问题
2.承认"我不知道"
3.具体地解释你准备查明问题的步骤,并给自己定下最后期限.

绩效考核

描述:

1.完成了什么工作
2.完成得如何
3.下一步需要做什么

对机遇的完整步法

1.我打算去哪里?
2.我打算创造什么?
3.我打算如何创造出来?

注意缺口

每个人都是可替代的

经验

你的经验和你努力拼搏的过去,这些给你做决定所以来的有用的,有价值的直觉

经验有半衰期

了解我的世界,预测下一步会发生什么?

仅仅是现在做得很棒,并不意味着你是成功的
困难是有益的
冲突就是学习

后端不高兴——关于协作和沟通

Thu, 24 Apr 2014 08:00:00 +0800

==================

再过两月毕业三周年，回顾一下，突然想起了一些问题，顺手记录一下

选择后端的原因之一，代码写得好一些，然后改需求的时候，刷刷刷改几行代码发布，然后泡杯茶站在前端同学后面看他们苦逼地改页面:)

工作那么久，逐渐变得“冷血”，要学会说no，学会排期，学会去“降低”一些人的期望甚至是“无情”扼杀，所以或许初次合作会给人一种不“友好”的印象。

但是在“友好”和“效率”，我选择了后者，记得当初很菜很菜的时候，我还是很“友好”的。(妈蛋，一天要处理N多问题，跟运营运维产品前端测试等等沟通，还得挤时间码代码测试发布上线，只能高效至上了)

不扯了，归正题，聊一些平时沟通合作遇到的问题

PS:这里后端偏指服务端开发，当然，问题普适于各个角色

1. 问问题的方式

之前在微博看见人说过的一个现象，再次提一下

假如有人找你咨询一个问题

A: 在? (在么?/在不在?)
B: 额
A: xxx功能你知道么？
B: 知道
A: xxx有个功能有问题了，能帮看下么
B: 什么地方
A: xxxxxxxx
B: 算了你切个图过来吧
A: [图]

这个，首先，可能我在写代码，闪动弹窗对有轻微强迫症的人来说，必须要点开的啊（妈蛋），然后，我即时响应了，可能由于你有事什么的，过一会回答，但是这个等待过程中我又很那去投入一件事，很容易投入没几分钟被打断…这几句对话可能跨度是几分钟，甚至几个钟头（跑去吃了个饭回来看到消息给才给回复，哥都快忘了），其次，我真的很吝啬打那么多字>_<#

效率杀手之一

最有效率的其实是：

A: 在吗?xxx功能你知道么?现在有问题了，xxx异常，访问链接 http://xxxxxxx，截图如下
   （给力一点的还会圈起来标注说明）
B: ok，稍等我看下
.....
B: 已修复，验证下
A: 好的

感受下吧

推荐一篇文章如何提问 | 一本书学会提问

2. 搞明白“这事谁的问题”

当一个人发现一个问题的时候，总是很兴奋地，迫不及待想要证实

然后就会有如下

A: xxx系统是不是挂了，我登陆不上去【有时候是页面差异，系统操作失败等】

B: 稍等，我看下
三分钟后
B: 后台正常，刚才重新走了一遍流程，没问题，[切图]
   你再试下，可能xxx问题
A: 我忘改xxx了/登陆超时了/xxx了/我忘记做xxx操作了

吐血的问题，很多时候，都是自己机器的问题，可能是host/网络/浏览器/系统登陆等等因素导致的，但是大多数人已发现问题，总是认为是别人的问题(系统的问题)，然后迫不及待，然后，我们要花费时间来排查各个可能的问题，跳转N多机器，检查N多服务，而且，相信我，这个过程不会很有趣，而且问题本身的种类很难导致很难将其自动化….《论排查问题的复杂性》

当然，如果是可以自动化而你偏偏要每次人肉查而且乐在其中，那我没办法了。

后来就变成

A: xxx系统是不是挂了，我点发布了但是前台没更新

B: 重做一遍，10分钟后没更新通知我 【够冷血吧】

这类问题次数少也就忍了，担心的是对应人员新人进来的时候，没有老员工带或者培训，那么系统开发者往往一次又一次成为“义务培训导师”…..

另外遇到问题也要忍住证实的欲望，先自己确认下

有一本书推荐《你的灯亮着么》

3. Suprise

后端最讨厌的是suprise，安排和做事情的节奏都会被打乱。

我的原则是，不接受&unhappy，紧急的会去配合做，当然心情不会happy

方案设计，评审，开发，测试那么多环节都没发现，要上线前，需求变更或者xxx有问题，suprise

然后，上线时间有时候又是固定的，所以必须要配合处理

当然，作为一枚“有责任感”的后端，肯定都会全力配合处理，不高兴是一回事，把事情完美地搞完是一回事。

但这时候，往往会发现，时间不等人，所有人都盯着你，瞬间亚历山大，如果没搞好还很容易成为“责任人”，延期什么的很容易落到你头上，属于吃力不讨好的角色，前期按时完成，suprise却要背负所有，心里瞬间失衡(╯‵□′)╯︵┻━┻

问题是，这个suprise的来源. 才是问题所在，更多的应该反思这里，否则很容易造成后续合作困难。

另外，suprise很容易导致黑逻辑、补丁、牛皮糖、硬编码等等，将一块干净的自留地变成垃圾桶，而且破窗理论，所以，要控制。

4. 要明白一个道理

1个人1个月能干好一件事情，不代表30个人在1天能把这件事做了

很简单的一个道理，但是很容易被人忽视

5. 关于估时间

后端需要信任，虽然我们有时候估时间不大准，但是基本都能在少于估算的时间内完成，超过的情况并不多。

而且随着工作经验积累，估算时间会越来越准。(三小时就是三小时，额，上下误差几分钟)

一般问题过来，很简单顺手做了，复杂的会给个完成时间。

不要站在自己的角度去给后端的估时间，常见的理由是：“就简单加一个xxx”，“修改一下而已”等，你要知道有些系统并没有那么简单，你要的可能是一个现在能用的东西，但我们需要一个以后无论怎么改都好改而且能用的东西。（相信我，差异很大），同理，不要估工作量啊（2天的量估0.5天，要做完，那另外1.5天怎么破，哥做不到>_<）

记住，除非火烧眉毛，否则，能在承诺完成时间内搞定的，不要催。

我们需要的是冷静和清晰的思路。催促和打断于事无补。

6. 上帝，同一时间内有且仅只有一个

所有人，都认为自己的需求优先级最高。

对后端来说，合作和沟通的每个人都是上帝。

但是要记住，上帝，同一时刻内只有一个。

所以，有了优先级这一说，会排期，一次只做一件事。

再给力的后端也不是超人，一次处理N件事情效率很低容易出错，非常不明智的

所以，要学会接受排期，除非排的时间不合理要去沟通。

你会发现，在截止日期到来的前一刻，后端小伙伴的东西已经搞完提供了。

7. 合理使用项目管理工具/邮件/IM/电话

综合使用工具进行沟通

涉及项目跟踪通知等，请用项目管理工具(目前tower)

极重要事情，请邮件

极紧急事情，请当面，或者电话

其他，IM

小事，确认，疑问，突发奇想？灵机一动？等等，注意除非这个沟通有可能导致你必须要去等，否则不到万不得已不要杀过去打断一个程序员的思路。

打断是效率杀手，如果不用电话，那恕我只能定期去查，异步回复，所以就不要傻等。

8. 被开会

不重要的会议不要勾选抄送我，谢谢

冗长无聊相关性不大的会议允许早退，或者过了跟自己相关的部分允许早退

超紧急临时会议，没问题

其他临时会议，没提前发邀约提前通知的会议都是耍流氓，要知道本来用来码代码的两小时被突如其来的会议占用，打乱了计划安排，那么晚上就得花一个小时加班补回来【别问我为啥是一个小时】

9. 拿到承诺

如果有一件事，你提给后端，不说明问题，优先级，截止时间，或者，压根你就扔给后端就不管了。（被动等待会等到海枯石烂的）

然后你期望他把事情给做了，把结果给你，或者将事情跟完。很多时候，这都是你的幻想。

如果我们没做出承诺，可能这件事情就被排后了，至于完成的时间，完全与取决于工作安排和工作量。

所以，一般提给后端的时候，可以多问一句，“什么时候能搞定”，拿到承诺，一般没问题了。

10. 当面沟通时提供上下文

遇到次数不多，但是还是会遇到，干活中都是有“状态”的

有时候在做一件事情，一半

然后例如这样

A: 把xxx字段改成xxxx.... blablablabla.......

B: 啊？（脑补痴呆状）

或者这样

A: 把xxx字段改成xxxx.... blablablabla.......

B: 不合适吧，xxxxxxx.......

A: 我在说xx问题

B: 我以为你说XXX问题

其实可以这样:

A: 关于xx的问题，我们..........

你要相信，大部分后端都是善良的孩子……

而且大部分后端，一个人干N个人的活(N>=2), (╯‵□′)╯︵┻━┻

JavaScript一站式入门笔记

Sun, 20 Apr 2014 08:00:00 +0800

大二开始接触的javascript，到现在，五年过去了，中间断断续续用了一些，但是主要是搞后端的，没有正儿八经“学习”一下。

对其了解不成系统，最近做了一个系统涉及前端框架，所以借此机会学习总结了下。

入门笔记，非初学者可以绕道哈:)

后续打算深入学习一下，顺带去玩玩node.js

参考教程

入门: 【已完成】

gitbook javascript教程【简单】
w3cschool教程【简单，较全】
Jquery:JavaScript101 【质量高】
JavaScript Tutorial 【全面，不错】

进阶：【待阅读】

Learning Advanced JavaScript

其他资料

书籍

javascript 权威指南

注意：笔记全部来自于以上资料

 第一部分：简介(Getting Started)
  1.HTML/CSS/JavaScript
  2.JavaScript书写和位置
  3.简单语法
 第二部分：基本语法
  1.变量(varivalbes)
  2.操作符(operators)
  3.真值判断 - 比较
  4.控制流
    分支
    循环
 第二部分：函数
  1.Functions
  2.global functions
 第三部分：对象
  1.Array
  2.Object
 第四部分：内置对象
  1.字符串(string)
  2.math
  3.date
  4.boolean
 第五部分: DOM 操作
 第六部分：其他
  1.正则
  2.this关键字
  3.异常处理
  4.作用域
    Global Scope
    Local Scope
  5.闭包
  6.typeof(Testing Type)
  7.Timers

第一部分：简介(Getting Started)

1.HTML/CSS/JavaScript

关系

HTML is for Content
CSS is for Presentation
JavaScript is for Interactivity

2.JavaScript书写和位置

external,外部js文件引入

inline,本页面

attribute


Click Me!

BP:将

3.简单语法

code sample

var hello = "Hello";
var world = "World";

// Message equals "Hello World"
var message = hello + " " + world;

分号 ;

分号用于分隔 JavaScript 语句。
通常我们在每条可执行的语句结尾添加分号。
使用分号的另一用处是在一行中编写多条语句。

注释

// 单行,This is a comment, it will be ignored by the interpreter
var a = "this is a variable defined in a statement";

/*
多行
This is a multi-line comment,
it will be ignored by the interpreter
*/
var a = "this is a variable defined in a statement";

对代码行进行折行 - 可以对js代码通过反斜杠，拆分换行

JavaScript 会忽略多余的空格。可以向脚本添加空格，来提高其可读性。(空格和折行无关紧要)

javaScript 中的所有事物都是对象：字符串、数字、数组、日期，等等。

第二部分：基本语法

1.变量(varivalbes)

命名

必须以字母开头, 也能以 $ 和 _ 符号开头（不过我们不推荐这么做）
可以包含数字
名称大小写敏感（y 和 Y 是不同的变量）
不能使用保留字

注意：变量命名不要使用保留字 Reserved Words

声明和赋值

var age;
age = 26;
//or
var age = 26;

var age, height, weight, gender;
//or
var name="Gates", age=56, job="CEO";

//注意，只声明不赋值，其值为undefined
var x;
x === undefined; // true

//=================

// This works:
var test = 1;
var test2 = function() { ... };
var test3 = test2( test );

// And so does this:
var test4 = 1,
    test5 = function() { ... },
    test6 = test2( test );

变量类型 Types

Numbers
    Float: a number, like 1.21323, 4, -33.5, 100004 or 0.123
    Integer: a number like 1, 12, -33, 140 but not 1.233
String: a line of text like "boat", "elephant" or "damn, you are tall!"
Boolean: either true or false, but nothing else
    // Boolean values.
    var okay = true;
    var fail = false;
Arrays: a collection of values like: 1,2,3,4,'I am bored now'
Objects: a representation of a more complex object

null
    // Define a null value. 可用于清空变量
    var foo = null;
undefined, 表示变量不含值
    // Two ways to achieve an undefined value.
    var bar1 = undefined;
    var bar2;

2.操作符(operators)

算术(Arithmetic Operators)

Operator Description
+        Addition
-        Subtraction
*        Multiplication
/        Division
%        Modulus (remainder)
++       Increment by one
--       Decrement by one

Increment: Given a = 5
    c = a++, Results: c = 5 and a = 6
    c = ++a, Results: c = 6 and a = 6
Decrement: Given a = 5
    c = a--, Results: c = 5 and a = 4
    c = --a, Results: c = 4 and a = 4

注意

减法(-)
将两边的操作数都转换为数字

加法(+)
1. 两边的操作数首先被转换成原始值.这里我们称之为A 和 B.
2. 如果有任意一个原始值是字符串,则把另一个也转换成字符串,执行A和B的连接操作并返回连接后的字符串.
3. 否则把A和B都转换为数字,返回两个数字的和

< 同 +

赋值操作符(Assignment Operators)

Operator    Description
=           Assignment, a = 3
+=          (a+=3 is the same as a=a+3)
-=          (a-=3 is the same as a=a-3)
*=          (a*=3 is the same as a=a*3)
/=          (a/=3 is the same as a=a/3)
%=          (a%=3 is the same as a=a%3)

字符串操作符(String Operators)

Operator    Description
+           Concatenation (var greeting = "Hello " + firstname;)
+=          One step concatenation and assignment (var greeting = "Hello "; greeting += firstname;)

"hello".concat(" world")// "hello world"

注意区别
// Addition vs. Concatenation
var foo = 1;
var bar = "2";
console.log( foo + bar ); // 12

// Coercing a string to act as a number.
var foo = 1;
var bar = "2";

console.log( foo + Number(bar) ); // 3

三元运算(Ternary Operator)

test ? expression1 : expression2

test
任何 Boolean 表达式。
expression1
如果 test 为 true，则返回表达式。 可能是逗号表达式。
expression2
如果 test 为 false，则返回表达式。 可以使用逗号表达式链接多个表达式。

e.g.
// Set foo to 1 if bar is true; otherwise, set foo to 0:
var foo = bar ? 1 : 0;

默认值(Default Operator)

Operator    Description
||          Used to assign a default operator

var yourName = prompt("Your Name?","") || "Stranger";

比较运算符(Comparison operators)

==  Equals
!=  Doesn't equal
=== Strictly equals
!== Doesn't strictly equal
>   Is greater than
<   Is less than
>=  Is greater than or equal to
<=  Is less than or equal to

== / === 的区别
== 值相等， === 值相等，且类型相同

BP: 相等比较总是使用 === 和 !===

//=====================

e.g.
var foo = 1;
var bar = 0;
var baz = "1";
var bim = 2;

foo == bar; // false
foo != bar; // true
foo == baz; // true; but note that the types are different

foo === baz;             // false
foo !== baz;             // true
foo === parseInt( baz ); // true

foo > bim;  // false
bim > baz;  // true
foo <= baz; // true

3.真值判断 - 比较

真值判断

// Values that evaluate to false:

false
"" // An empty string.
NaN // JavaScript's "not-a-number" variable.
null
undefined // Be careful -- undefined can be redefined!
0 // The number zero.

// Values that evaluate to true:

true
// Everything else evaluates to true, some examples:
"0"
"any string"
[] // An empty array.
{} // An empty object.
1 // Any non-zero number.

逻辑运算

//短路运算
&&  and (a == b && c != d)
||  or (a == b || c != d)
!   not !(a == b || c != d)

--------------------

// Logical AND and OR operators

var foo = 1;
var bar = 0;
var baz = 2;

// returns 1, which is true
foo || bar;

// returns 1, which is true
bar || foo;

// returns 0, which is false
foo && bar;

// returns 2, which is true
foo && baz;

// returns 1, which is true
baz && foo;

--------------------

if(x > 10 && x < 20) {
    ...
}

if(country === 'England' || country === 'Germany') {
        ...
}


if ( (name === "John" || name === "Jennifer") && country === "France")

--------------------

//其他用法
// Do something with foo if foo is truthy.
foo && doSomething( foo );

// Set bar to baz if baz is truthy;
// otherwise, set it to the return value of createBar()
var bar = baz || createBar();

4.控制流

分支

if-eles

if (conditions) {
    statements;
} else if (conditions) {
    statements;
} else {
    statements;
}

e.g.

if (time<10)
{
    x="Good morning";
} else if (time<20)
{
    x="Good day";
} else
{
    x="Good evening";
}

switch

在判断情况大于2种的时候，使用 switch/case 更高效，而且更优雅（更易于组织代码）。但在判断的情况超过10种的时候不要使用 switch/case

switch (expression) {
    case value :
        statements;
    case value :
        statements;
    default :
        statements;
}

e.g.

//记得break
var quantity = 1;
switch (quantity) {
    case 1 :
        alert("quantity is 1");
        break;
    case 2 :
        alert("quantity is 2");
        break;
    default :
        alert("quantity is not 1 or 2");
}

循环

for

for (initialization; conditions; change) {
    statements;
}

e.g.

for(var i = 0; i < 10; i = i + 1){
    // do this code ten-times
}

var i = 0;
for(; i");
    i++;
}

for/in

谨慎使用for-in, 遍历一个对象中的成员（属性，方法），如果用来遍历数组的到的结果并不是预期中数组每项的值，方法神马的会被遍历出来

for (var index in array) {
    statements;
    //array[index]
}

for (var key in object) {
    statements;
    //object[key]
}
for (var name in object) {
    if (object.hasOwnProperty(name)) {
        // do something with name
    }
}

e.g.

while

while (conditions) {
    statements;
}

e.g.

var i = 0, x = "";
while (i < 5) {
    x = x + "The number is " + i;
    i++;
}

do-while

do {
    statements;
} while (conditions);

e.g.

do {
    // Even though the condition evaluates to false
    // this loop's body will still execute once.
    alert( "Hi there!" );
} while ( false );

break/continue

break 语句用于跳出循环。
continue 用于跳过循环中的一个迭代。

label:
    语句

break labelname;
continue labelname;

e.g.

// Stopping a loop
for ( var i = 0; i < 10; i++ ) {
    if ( something ) {
        break;
    }
}

// Skipping to the next iteration of a loop
for ( var i = 0; i < 10; i++ ) {
    if ( something ) {
        continue;
    }
    // The following statement will only be executed
    // if the conditional "something" has not been met
    console.log( "I have been reached" );

}

第二部分：函数

1.Functions

声明

// Function declaration.
function foo() {
    // Do something.
}

// Named function expression.
var foo = function() {
    // Do something.
};

function myFunction(var1,var2)
{
    //function statements go here
}

e.g.

function double(x) {
    return 2 * x;
}

or

var double = function(x) {
    return 2 * x;
};

参数

function changeBg(color){
    document.bgColor = color;
}

返回值

function myFunction()
{
    var x=5;
    return x;
}
var myVar=myFunction();

e.g.

// A simple function.
var greet = function( person, greeting ) {
    var text = greeting + ", " + person;
    console.log( text );
};

greet( "Rebecca", "Hello" ); // "Hello, Rebecca"


// A function that returns a value.
var greet = function( person, greeting ) {
    var text = greeting + ", " + person;
    return text;
};

console.log( greet( "Rebecca", "Hello" ) ); // "Hello, Rebecca"


// A function that returns another function.
var greet = function( person, greeting ) {
    var text = greeting + ", " + person;
    return function() {
        console.log( text );
    };
};

var greeting = greet( "Rebecca", "Hello" );

greeting(); // "Hello, Rebecca"

Immediately-Invoked Function Expression (IIFE)

参阅文章 IIFE

创建并立刻执行.This pattern is extremely useful for cases where you want to avoid polluting the global namespace with code – no variables declared inside of the function are visible outside of it.

// An immediately-invoked function expression.

(function() {
    var foo = "Hello world";
})();

console.log( foo ); // undefined!

方法作为参数

方法可以赋值给变量，且，可以作为函数参数传递

// Passing an anonymous function as an argument.
var myFn = function( fn ) {
    var result = fn();
    console.log( result );
};

// Logs "hello world"
myFn( function() {
    return "hello world";
});

// Passing a named function as an argument
var myFn = function( fn ) {
    var result = fn();
    console.log( result );
};

var myOtherFn = function() {
    return "hello world";
};

myFn( myOtherFn ); // "hello world"

2.global functions

These “global” functions we have discussed above are actually methods of the window object, but as window is assumed if no object is referenced, we don’t need to explicitly write window.parseFloat() or window.isNaN(). Also, some of these functions such as Number() and String() are really function constructors for creating new String and Number objects. For now, just remember that you can use these functions to ensure you are working with a String or Number.

Number(object)

一个数值包装器

Number的属性

MAX_VALUE
MIN_VALUE
NEGATIVE_INFINITY
POSITIVE_INFINITY

方法

toExponential ,  toExponential 方法以指数形式返回 数字的字符串表示
toFixed, 四舍五入
toPrecision
toString
valueOf, valueOf 方法返回调用它的对象类型的原始

转为数字，如果失败返回NaN(Not a Number)

var strNum1 = "1";
var strNum2 = "2";
var strSum = strNum1 + strNum2; //returns 12
alert(strSum);

var intNum1 = Number(strNum1);
var intNum2 = Number(strNum2);
var intSum = intNum1 + intNum2; //returns 3
alert(intSum);

// 四舍五入一个数字，保留N位小数
var num =2.443242342;
num = num.toFixed(4);  // num will be equal to 2.4432

Boolean(object)

Boolean 是一个代表 true 或 false 值的对象

Boolean 对象有多个值，这些值

相当于 false 值（0、 -0、null 或 “” [一个空字串]），未定义的 (NaN)，当然还有 false。
所有其他布尔 值相当于 true 值

var myBoolean = true; if(myBoolean == true) { // If the condition evaluates to true } else { // If the condition evaluates to false }

String(object)

转为字符串

var intNum1 = 1;
var intNum2 = 2;
var intSum = intNum1 + intNum2; //returns 3
alert(intSum);

var strNum1 = String(intNum1);
var strNum2 = String(intNum2);
var strSum = strNum1 + strNum2; //returns 12
alert(strSum);

具体见string 方法

isNaN(object)

判断是否为数字，或者是否可以被转为数字。如果是数字，return false，否则，return true;

isNaN(4) //false
isNaN('4') //false

isNaN('hello') //true
isNaN(0/0) //true

parseFloat() and parseInt()

The parseFloat() 如果字符串以数字开头，将会将字符串开头数字部分转为数字。否则，返回NaN

The parseInt() 如果字符串以数字开头，将会将字符串开头数字部分转为数字。否则，返回NaN

parseInt(string, radix), radix=[2,36], radix不设or0, 根据string, “0x”16进制, “0"8进制

var race = "26.2 miles";
parseFloat(race); //26.2
parseInt(race);  //26

race = "Marathon";
parseFloat(race); //NaN
parseInt(race); //NaN

第三部分：对象

1.Array

声明

//语法
new Array();
new Array(size);
new Array(element0, element1, ..., elementn);

// Creating an array with the constructor:
var myarray = new Array();

// Creating an array with the array literal syntax:
var bar = [];

========================

// A simple array with constructor.
var myArray1 = new Array( "hello", "world" );

// Literal declaration, the preferred way.
var myArray2 = [ "hello", "world" ];

========================

var bar = new Array( 100 );
alert( bar[ 0 ] ); // undefined
alert( bar.length ); // 100

var foo = [ 100 ];
alert( foo[ 0 ] ); // 100
alert( foo.length ); // 1

a = new Array(3) // [undefined × 3]
a[0] // undefined

赋值

var myArray = [];

myArray[ 0 ] = "hello";
myArray[ 1 ] = "world";
myArray[ 3 ] = "!";

//Missing indices will be filled with undefined.
console.log( myArray ); // [ "hello", "world", undefined, "!" ];

读取

// Accessing array items by index
var myArray = [ "hello", "world", "!" ];
console.log( myArray[ 2 ] ); // "!"

属性-length

// Length of an array
var myArray = [ "hello", "world", "!" ];
console.log( myArray.length ); // 3

原生数组函数

遍历

// For loops and arrays - a classic
var myArray = [ "hello", "world", "!" ];
for ( var i = 0; i < myArray.length; i = i + 1 ) {
    console.log( myArray[ i ] );
}

// for/in
var x
var mycars = new Array()
mycars[0] = "Saab"
mycars[1] = "Volvo"

for (x in mycars)
{
    console.log(mycars[x]);
}

常用方法

方法-push/pop

// Pushing and popping

var myArray = [];

myArray.push( 0 ); // [ 0 ]
myArray.push( 2 ); // [ 0 , 2 ]
myArray.push( 7 ); // [ 0 , 2 , 7 ]
b = myArray.pop();     // [ 0 , 2 ] , b=7

方法-concat

var myArray = [ 2, 3, 4 ];
var myOtherArray = [ 5, 6, 7 ];
// 返回新数组
var wholeArray = myArray.concat( myOtherArray ); // [ 2, 3, 4, 5, 6, 7 ]

//附加（append）一个数组到另一个数组上
var array1 = [12 , "foo" , {name: "Joe"} , -2458];
var array2 = ["Doe" , 555 , 100];

Array.prototype.push.apply(array1, array2);
/* array1 will be equal to  [12 , "foo" , {name "Joe"} , -2458 , "Doe" , 555 , 100] */

方法-join

// Joining elements
var myArray = [ "hello", "world", "!" ];

// The default separator is a comma. 默认逗号
console.log( myArray.join() );     // "hello,world,!"

// Any string can be used as separator...
console.log( myArray.join( " " ) );  // "hello world !";
console.log( myArray.join( "!!" ) ); // "hello!!world!!!";

// ...including an empty one.
console.log( myArray.join( "" ) );   // "helloworld!"

// 拼标签
"" + tdcell.join('') + ""

方法-indexOf

var fruits = ["Banana", "Orange", "Apple", "Mango"];
var a = fruits.indexOf("Apple");
//2

方法-slice

// Slicing
var myArray = [ 1, 2, 3, 4, 5, 6, 7, 8 ];
var newArray = myArray.slice( 3 );

console.log( myArray );  // [ 1, 2, 3, 4, 5, 6, 7, 8 ]
console.log( newArray ); // [ 4, 5, 6, 7, 8 ]

方法-splice

myArray.splice( index, length, values, ... );
Index – The starting index.
Length – The number of elements to remove.
Values – The values to be inserted at the index position.

var myArray = [ 0, 7, 8, 5 ];
myArray.splice( 1, 2, 1, 2, 3, 4 ); //from index 1, cut 2 elements, and insert 1,2,3,4
console.log( myArray ); // [ 0, 1, 2, 3, 4, 5 ]

方法-sort

// Sorting without comparing function.
var myArray = [ 3, 4, 6, 1 ];
myArray.sort(); // 1, 3, 4, 6

// Sorting with comparing function.
function descending( a, b ) {
    return b - a;
}
var myArray = [ 3, 4, 6, 1 ];
myArray.sort( descending ); // [ 6, 4, 3, 1 ]

方法-reverse

var myArray = [ "world" , "hello" ];
myArray.reverse(); // [ "hello", "world" ]

方法-shift

// Queue with shift() and push()
var myArray = [];

myArray.push( 0 ); // [ 0 ]
myArray.push( 2 ); // [ 0 , 2 ]
myArray.push( 7 ); // [ 0 , 2 , 7 ]
b = myArray.shift();   // [ 2 , 7 ],  b=0

方法-unshift

//Inserts an element at the first position of the array:
var myArray = [];

myArray.unshift( 0 ); // [ 0 ]
myArray.unshift( 2 ); // [ 2 , 0 ]
myArray.unshift( 7 ); // [ 7 , 2 , 0 ]

方法-forEach

Element – The element itself.
Index – The index of this element in the array.
Array – The array itself.

// Native .forEach()
function printElement( elem ) {
    console.log( elem );
}

function printElementAndIndex( elem, index ) {
    console.log( "Index " + index + ": " + elem );
}

function negateElement( elem, index, array ) {
    array[ index ] = -elem;
}

myArray = [ 1, 2, 3, 4, 5 ];

// Prints all elements to the console
myArray.forEach( printElement );

// Prints "Index 0: 1", "Index 1: 2", "Index 2: 3", ...
myArray.forEach( printElementAndIndex );

// myArray is now [ -1, -2, -3, -4, -5 ]
myArray.forEach( negateElement );

获取数字数组中最大最小值

var  numbers = [5, 458 , 120 , -215 , 228 , 400 , 122205, -85411];
var maxInNumbers = Math.max.apply(Math, numbers);
var minInNumbers = Math.min.apply(Math, numbers);

清空一个数组

var myArray = [12 , 222 , 1000 ];
myArray.length = 0; // myArray will be equal to [].

改变length可以进行数组截断或者扩增(扩增的项是undefined)

不要使用 delete 来删除一个数组中的项

var items = [12, 548 ,'a' , 2 , 5478 , 'foo' , 8852, , 'Doe' ,2154 , 119 ];
items.length; // return 11
delete items[3]; // return true
items.length; // return 11
/* items will be equal to [12, 548, "a", undefined × 1, 5478, "foo", 8852, undefined × 1, "Doe", 2154,       119]   */

使用

var items = [12, 548 ,'a' , 2 , 5478 , 'foo' , 8852, , 'Doe' ,2154 , 119 ];
items.length; // return 11
items.splice(3,1) ;
items.length; // return 10
/* items will be equal to [12, 548, "a", 5478, "foo", 8852, undefined × 1, "Doe", 2154,       119]   */

2.Object

Objects包含一个或多个键值对，键：任意字符串，值：数字，字符串，array，其他objects，函数等

声明

// Creating an object with the constructor:
var person1 = new Object;
person1.firstName = "John";
person1.lastName = "Doe";

alert( person1.firstName + " " + person1.lastName );

// Creating an object with the object literal syntax:
var person2 = {
    firstName: "Jane",
    lastName: "Doe"
};

alert( person2.firstName + " " + person2.lastName );

//包含方法
var myObject = {
    sayHello: function() {
        console.log( "hello" );
    },
    myName: "Rebecca"
};

myObject.sayHello(); // "hello"

console.log( myObject.myName ); // "Rebecca"

嵌套

// As mentioned, objects can also have objects as a property.
var people = {};

people[ "person1" ] = person1;
people[ "person2" ] = person2;

alert( people[ "person1" ].firstName );
alert( people[ "person2" ].firstName );

获取属性：寻址方式

name=person.lastname;
name=person["lastname"];

删除属性

b = { 'b1': 1, 'b2':2 }
delete b['b2']
//Object {b1: 1}

读取未定义的属性

// Properties that have not been created are undefined.
var person = { name: "John Doe" };
alert( person.email ); // undefined

访问对象的方法

objectName.methodName()

第四部分：内置对象

1.字符串(string)

字符串可以是引号中的任意文本

声明

// Single quotes can be used
var str = 'Our lovely string';

// Double quotes as well
var otherStr = "Another nice string";

//In Javascript, Strings can contain UTF-8 characters:
"中文 español English हिन्दी العربية português বাংলা русский 日本語 ਪੰਜਾਬੀ 한국어";

连接字符串

//规则是：如果把数字与字符串相加，结果将成为字符串
var bigStr = 'Hi ' + 'JS strings are nice ' + 'and ' + 'easy to add';

长度

// Just use the property .length
var size = 'Our lovely string'.length;

常用方法

方法-trim

var str = "       Hello World!        ";
alert(str.trim());

方法-match

str.match("world")

方法-replace

语法

StringObject.replace(searchValue,replaceValue)

StringObject:字符串
searchValue：字符串或正则表达式
replaceValue:字符串或者函数

replaceValue可以是字符串。如果字符串中有几个特定字符的话，会被转换为特定字符串

$&  与正则相匹配的字符串
$`  匹配字符串左边的字符
$’ 匹配字符串右边的字符
$1,$2,$,3,…,$n 匹配结果中对应的分组匹配结果

实例

str.replace(/Microsoft/,"W3School")

a = 'hello world'
"hello world"
a.replace(/l/, 'a')
"healo world"
a.replace(/l/g, 'a')
"heaao worad"

var sStr='讨论一下正则表达式中的replace的用法';
sStr.replace(/正则表达式/,'{$&}');//讨论一下{正则表达式}中的replace的用法

'abc'.replace(/b/,"$`");//aac
'abc'.replace(/b/,"$'");//acc"'`")

'nimojs@126.com'.replace(/(.+)(@)(.*)/,"$2$1")//@nimojs

replaceValue 是函数

'JAVASCRIPT'.replace(/[A-G]/g,function(){
    return arguments[0].toLowerCase();
})//JaVaScRIPT

function logArguments(){    
    console.log(arguments);//["nimojs@126.com", "nimojs", "@", "126.com", 0, "nimojs@126.com"] 
    return '返回值会替换掉匹配到的目标'
}
console.log(
    'nimojs@126.com'.replace(/(.+)(@)(.*)/,logArguments)
)

方法-split(delimiter)

var s = "A,B,C,D";
var a = s.split(",");
document.write(a[2]);
//Returns C

方法-indexOf(substring,startPosition)

str.indexOf("Hello")
// if not exists, return -1
code.indexOf('a') === -1

webucator.indexOf("cat");
//Returns 4

webucator.indexOf("cat", 5);
//Returns -1

方法-lastIndexOf(substring,endPosition)

webucator.lastIndexOf("cat");
//Returns 4

 webucator.lastIndexOf("cat", 5);
 //Returns 4

方法-substr(startPosition,length)

webucator.substr(4, 3);
//Returns cat

webucator.substr(4);
//Returns cator

方法-substring(startPosition,endPosition)

webucator.substring(4, 7);
//Returns cat

webucator.substring(4);
//Returns cator

方法-slice(startPosition,endPosition)

webucator.slice(4, 7);
//Returns cat

var str="Hello happy world!"
str.slice(6)// happy world!
str.slice(6,11) //happy

方法-slice(startPosition,positionFromEnd)

webucator.slice(4, -2);
//Returns cat

方法-toLowerCase()/toUpperCase()

webucator.toLowerCase()
//Returns webucator

webucator.toUpperCase();
//Returns WEBUCATOR

方法-charAt(position)

webucator.charAt(4)
//Returns c (the fifth character)

方法-charCodeAt(position)

webucator.charCodeAt(4)
//Returns 99

方法-fromCharCode(characterCodes)

String.fromCharCode(169)
//Returns ©

2.math

Math（算数）对象的作用是：执行常见的算数任务

属性

//Math.PI Pi (Π)
Math.PI;
//3.141592653589793

//Math.SQRT2  Square root of 2.
Math.SQRT2;
//1.4142135623730951

Math.abs(number)

Math.abs(-12);
//Returns 12

Math.ceil(number)

Math.ceil(5.4);
//Returns 6

Math.floor(number)

Math.floor(5.6);
//Returns 5

Math.max(numbers)

Math.max(2, 5, 9, 3);
//Returns 9

Math.min(numbers)

Math.min(2, 5, 9, 3);
//Returns 2

Math.pow(number, power)

Math.pow(2, 5);
//Returns 32

Math.round(number)

Math.round(2.5);
//Returns 3

Math.random();

//Returns random
//number from 0 to 1
Math.random()
var rndDec = Math.random();

Math.power()

3.date

处理日期和时间

定义

//Syntax: new Date();
var myDate=new Date()
"从 1970/01/01 至今已过去 " + myDate.getTime() + " 毫秒"

var now = new Date();
document.write(now);

//Syntax: new Date("month dd, yyyy hh:mm:ss);")
var redSoxWin = new Date("October 21, 2004 12:01:00");
document.write(redSoxWin);

//Syntax: new Date(yyyy, mm, dd, hh, mm, ss, ms);
redSoxWin = new Date(2004, 9, 21, 12, 01, 00, 00);
document.write(redSoxWin);

// 计数从0开始
var d = new Date(2012, 4, 15);        // 2012年5月15日
alert(d.getMonth());            // 结果为4

Date.parse 的返回结果不是一个Date对象，而是从1970-01-01午夜（GMT）到给定日期之间的毫秒数。可以用Date的构造函数将其转换为Date对象

new Date(Date.parse("8/2/2012"));    // 正确识别为2012年8月2日
new Date(Date.parse("2012-08-02"));    // 正确识别为2012年8月2日
new Date(Date.parse("2012-8-2"));    // 不能识别

方法

getDate() Returns the day of the month (1-31).

rightNow.getDate();
//Returns 14

getDay() Returns the day of the week as a number (0-6, 0=Sunday, 6=Saturday).

rightNow.getDay();
//Returns 4

getMonth() Returns the month as a number (0-11, 0=January, 11=December).

rightNow.getMonth();
//Returns 3

getFullYear() Returns the four-digit year.

rightNow.getFullYear();
//Returns 2011

getHours() Returns the hour (0-23).

rightNow.getHours();
//Returns 0

getMinutes() Returns the minute (0-59).

rightNow.getMinutes();
//Returns 23

getSeconds() Returns the second (0-59).

rightNow.getSeconds();
//Returns 54

getMilliseconds() Returns the millisecond (0-999).

rightNow.getMilliseconds();
//Returns 650

getTime() Returns the number of milliseconds since midnight January 1, 1970.

rightNow.getTime();
//Returns 1113452634650

getTimezoneOffset() Returns the time difference in minutes between the computer of user and GMT.

rightNow.getTimezoneOffset();
//Returns 240

toLocaleString() Returns the Date object as a string.

rightNow.toLocaleString();
//Returns Thursday, April 14,
//2011 12:23:54 AM

toGMTString() Returns the Date object as a string in GMT timezone.

rightNow.toGMTString();
//Returns Thu, 14 Apr 2011
//04:23:54 UTC

4.boolean

布尔（逻辑）只能有两个值：true 或 false

var x=true
var y=false

对象

var myBoolean=new Boolean()

所有的代码行均会创建初始值为 false 的 Boolean 对象。

var myBoolean=new Boolean();
var myBoolean=new Boolean(0);
var myBoolean=new Boolean(null);
var myBoolean=new Boolean("");
var myBoolean=new Boolean(false);
var myBoolean=new Boolean(NaN);

所有的代码行均会创初始值为 true 的 Boolean 对象：

var myBoolean=new Boolean(1);
var myBoolean=new Boolean(true);
var myBoolean=new Boolean("true");
var myBoolean=new Boolean("false");
var myBoolean=new Boolean("Bill Gates");

第五部分: DOM操作

DOM

当网页被加载时，浏览器会创建页面的文档对象模型（Document Object Model）。 HTML DOM 模型被构造为对象的树

HTML DOM 树

JavaScript 能够改变页面中的所有 HTML 元素
JavaScript 能够改变页面中的所有 HTML 属性
JavaScript 能够改变页面中的所有 CSS 样式
JavaScript 能够对页面中的所有事件做出反应

通过id查找

var x=document.getElementById("intro");

本例查找 id=“main” 的元素，然后查找 “main” 中的所有

元素：

var x=document.getElementById("main");
var y=x.getElementsByTagName("p");

改变输出

document.write(Date());

改变html

document.getElementById(id).innerHTML=new HTML

改变html属性

document.getElementById(id).attribute=new value

改变css

document.getElementById(id).style.property=new style

HTML Event Handlers

onblur ,onchange ,onclick ,ondblclick ,onfocus ,onkeydown ,onkeypress ,onkeyup ,onload ,onload ,onmousedown ,onmousemove ,onmouseout ,onmouseover ,onmouseup ,onreset ,onselect ,onsubmit ,onunload ,onunload

创建节点


这是一个段落
这是另一个段落

删除节点


这是一个段落。
这是另一个段落。

第六部分：其他

1.正则

RegExp 对象用于存储检索模式。通过 new 关键词来定义 RegExp 对象

var patt1=new RegExp("e");

RegExp 对象的方法 RegExp 对象有 3 个方法：test()、exec() 以及 compile()。

var patt1=new RegExp("e");
patt1.test("The best things in life are free"); //true

patt1.exec("The best things in life are free"); //["e"]

var patt1=new RegExp("e","g");
do
{
	result=patt1.exec("The best things in life are free");
	document.write(result);
}while (result!=null)

compile() 方法用于改变 RegExp。
compile() 既可以改变检索模式，也可以添加或删除第二个参数

var patt1=new RegExp("e");
document.write(patt1.test("The best things in life are free"));
patt1.compile("d");
document.write(patt1.test("The best things in life are free"));

JavaScript中的正则有几个不同于其他语言的地方

2.this关键字

“this"是一个特殊的关键字，用在方法中，指向调用该方法的对象。this的值 In JavaScript, as in most object-oriented programming languages, this is a special keyword that is used in methods to refer to the object on which a method is being invoked. The value of this is determined using a simple series of steps:

1.调用方式是Function.call() 或者 Function.apply(), this将会被赋值为传递给.call()/.apply()的第一个参数.如果第一个参数是null或者undefined,this会指向global object.

// A function invoked using Function.call()
var myObject = {
    sayHello: function() {
        console.log( "Hi! My name is " + this.myName );
    },
    myName: "Rebecca"
};

var secondObject = {
    myName: "Colin"
};

myObject.sayHello();                    // "Hi! My name is Rebecca"
myObject.sayHello.call( secondObject ); // "Hi! My name is Colin"

2.如果函数调用使用的是Function.bind(), this 会被赋值为传递给.bind()的第一个参数

// A function created using Function.bind()

var myName = "the global object";
var sayHello = function() {
    console.log( "Hi! My name is " + this.myName );
};
var myObject = {
    myName: "Rebecca"
};
var myObjectHello = sayHello.bind( myObject );

sayHello();      // "Hi! My name is the global object"
myObjectHello(); // "Hi! My name is Rebecca"

3.如果函数是作为对象的一个方法被调用，this指向该对象

// A function being attached to an object at runtime.

var myName = "the global object";
var sayHello = function() {
    console.log( "Hi! My name is " + this.myName );
};
var myObject = {
    myName: "Rebecca"
};
var secondObject = {
    myName: "Colin"
};

myObject.sayHello = sayHello;
secondObject.sayHello = sayHello;

sayHello();              // "Hi! My name is the global object"
myObject.sayHello();     // "Hi! My name is Rebecca"
secondObject.sayHello(); // "Hi! My name is Colin"

当在一个大的命名空间内调用函数，可以通过给一个变量赋值减少代码量，但是，注意方法赋值和对象赋值，在调用时this的区别,可能会会导致bug.

var myNamespace = {
    myObject: {
        sayHello: function() {
            console.log( "Hi! My name is " + this.myName );
        },
        myName: "Rebecca"
    }
};

var hello = myNamespace.myObject.sayHello;

hello(); // "Hi! My name is undefined"

or

var myNamespace = {
    myObject: {
        sayHello: function() {
            console.log( "Hi! My name is " + this.myName );
        },
        myName: "Rebecca"
    }
};

var obj = myNamespace.myObject;

obj.sayHello(); // "Hi! My name is Rebecca"

3.异常处理

语法

try
{
    //在这里运行代码
}catch(err)
{
    //在这里处理错误
}

e.g.

function message() {
    try {
        adddlert("Welcome guest!");
    }catch(err) {
        txt="There was an error on this page.\n\n";
        txt+="Error description: " + err.message + "\n\n";
        txt+="Click OK to continue.\n\n";
        alert(txt);
    }
}

throw 语句允许我们创建自定义错误。

正确的技术术语是：创建或抛出异常（exception）。
如果把 throw 与 try 和 catch 一起使用，那么您能够控制程序流，并生成自定义的错误消息。
语法
throw exception

function myFunction() {
    try {
        var x=document.getElementById("demo").value;
        if(x=="")    throw "empty";
        if(isNaN(x)) throw "not a number";
        if(x>10)     throw "too high";
        if(x<5)      throw "too low";
    } catch(err)
    {
        var y=document.getElementById("mess");
        y.innerHTML="Error: " + err + ".";
    }
}

4.作用域

Global Scope

如果一个变量或函数是全局的，可以在任意地方获取。对浏览器，全局作用域是window对象。

如果一个变量在函数外面定义，则这个变量是全局的

var x = 9;

//anywhere
window.x or x

Local Scope

在函数体中使用var定义的变量，是局部变量

function myFunc() {
    var x = 5;
}

console.log( x ); // ReferenceError: x is not defined

注意如果不适用var进行定义，则该变量默认全局

function myFunc() {
    x = 5;
}

console.log( x ); // 5

Immediately-Invoked Function Expressions(IIFE) 可以避免全局变量(立刻定义和调用),在jQuery库中可以看到

(function() {
    var jQuery = { /* All my methods go here. */ };
    window.jQuery = jQuery;
})();

局部变量在整个函数内可见，所以对于函数嵌套,内层可以访问外层变量:

function outer() {
    var x = 5;
    function inner() {
        console.log( x );
    }
    inner(); // 5
}

外层不能访问内层变量

function outer() {
    var x = 5;
    function inner() {
        console.log( x );
        var y = 10;
    }
    inner(); // 5
    console.log( y ); // ReferenceError: y is not defined
}

在函数中声明变量，没有使用var，javascript将作为全局变量处理，会到全局域去寻找该变量是否定义，如果未预定义，将会在全局域中定义该变量，造成一些不可预期的结果。

// Functions have access to variables defined in the same scope.

var foo = "hello";

var sayHello = function() {
    console.log( foo );
};

sayHello(); // "hello"

console.log( foo ); // "hello"

全局变量和局部变量可以重名

var foo = "world";
var sayHello = function() {
    var foo = "hello";
    console.log( foo );
};

sayHello(); // "hello"

console.log( foo ); // "world"

When, within a function, you reference a variable defined in an outer scope, that function can see changes to the variable’s value after the function is defined.

var myFunction = function() {
    var foo = "hello";
    var myFn = function() {
        console.log( foo ); //指向该变量
    };
    foo = "world"; // change 变量对应的值变更了
    return myFn;
};

var f = myFunction();

f(); // "world"

一个复杂的例子演示：

(function() {
    var baz = 1;
    var bim = function() {
        console.log( baz );
    };
    bar = function() {
        console.log( baz );
    };
})();

console.log( baz ); // baz is not defined outside of the function, ReferenceError

bar(); //  1, 外部可见，全局的

bim(); // ReferenceError: bim is not defined

局部变量会在函数运行以后被删除。

全局变量会在页面关闭后被删除。

5.闭包

可以参考入口

简单例子

var buildMultiplier = function(x) {
    return function(y) {
        return x * y;
    }
}

var double = buildMultiplier(2);
var triple = buildMultiplier(3);

double(3); // => 6
triple(3); // => 9

Closures are an extension of the concept of scope.

通过闭包，函数可以获取在函数定义位置作用域范围内的变量

闭包需要通过实例去理解。

下面这个例子，最终每个函数的i将会是函数循环结果的最后一个值

// Each function executed within the loop will reference
// the last value stored in i (5).
// This won't behave as we want it to - every 100 milliseconds, 5 will alert
for ( var i = 0; i < 5; i++ ) {
    setTimeout(function() {
        alert( i );
    }, i * 100 );
}

闭包可以避免这种情况，为每个循环建立独立的可见范围–将变量的每个独立值存储在其可见域内。

// Using a closure to create a new private scope
// fix: “close” the value of i inside createFunction, so it won't change
var createFunction = function( i ) { //可见范围，i被保存，独立
    return function() {
        alert( i );
    };
};

for ( var i = 0; i < 5; i++ ) {
    setTimeout( createFunction( i ), i * 100 );
}

闭包还通常和this关键字配合

// Using a closure to access inner and outer object instances simultaneously.
var outerObj = {
    myName: "outer",
    outerFunction: function() {

        // Provide a reference to outerObj through innerFunction's closure
        var self = this;
        var innerObj = {
            myName: "inner",
            innerFunction: function() {
                console.log( self.myName, this.myName ); // "outer inner"
            }
        };

        innerObj.innerFunction();

        console.log( this.myName ); // "outer"
    }
};

6.typeof(Testing Type)

typeof关键之用于判断一个变量的类型

type checking

// Testing the type of various variables.
var myFunction = function() {
    console.log( "hello" );
};
var myObject = {
    foo: "bar"
};
var myArray = [ "a", "b", "c" ];
var myString = "hello";
var myNumber = 3;
var myRegExp = /(\w+)\s(\w+)/;

typeof myFunction; // "function"
typeof myObject;   // "object"
typeof myArray;    // "object" -- Careful!
typeof myString;   // "string"
typeof myNumber;   // "number"
typeof null;       // "object" -- Careful!
typeof undefined;  // "undefined"
typeof meh;        // "undefined" -- undefined variable.
typeof myRegExp;   // "function" or "object" depending on environment.


if ( myArray.push && myArray.slice && myArray.join ) {
    // probably an array (this is called "duck typing")
}

if ( Object.prototype.toString.call( myArray ) === "[object Array]" ) {
    // Definitely an array!
    // This is widely considered as the most robust way
    // to determine if a specific value is an Array.
}

7.Timers

Timers are started and stopped with the following four methods of the window object:

setTimeout(code_to_execute, wait_time_in_milliseconds)
clearTimeout(timer)

setInterval(code_to_execute, interval_in_milliseconds)
clearInterval(interval)

test

Vim技巧补充

Sun, 13 Apr 2014 08:00:00 +0800

读了一些文章，重新理一理，大部分是平常操作中容易忽视的,很容易忘了其实还可以这么干

Text Object

y/d/c + text-object-operation

    * iw …inner word
    * aw …a word
    * iW …inner WORD
    * aW …a WORD

    * is …inner sentence
    * as …a sentence

    * ip …inner paragraph
    * ap …a paragraph

    -------------------------

    * i( or i) …inner block
    * a( or a) …a block
    * i< or i> …inner block
    * a< or i> …a block
    * i{ or i} …inner block
    * a{ or a} …a block

    * i" …inner block
    * a" …a block
    * i` …inner block
    * a` …a block

替换

命令格式

:[range]s/pattern/string/[c,e,g,i]

range,范围， 1,7指从第一行到第七行  1,$第一行到最后一行
pattern,被替换字符串，可以用regexp来表示
string,替换成的字符串

c: confirm，每次替换前询问
e: 不提示error
g: globe, 不询问，整行替换[默认只替换第一个]
i: ignore,不区分大小写

e.g.

:s/vivian/sky/
替换当前行第一个vivian为sky

:s/vivian/sky/g
替换当前行所有vivian为sky，g表示global

:n,$s/vivian/sky/
替换第n行开始到最后一行中每一行的第一个vivian为sky，n为数字

:.,$s/vivian/sky/g
替换当前行开始到最后一行中每一行所有vivian为sky

:%s/vivian/sky/g（等同于 :g/vivian/sky/g）
替换每一行中所有 vivian 为 sky

:s/vivian\//sky\//
替换当前行第一个vivian/为sky/，可以使用\作为转义符

:1,$s/^/some string/
在文件的第一行至最后一行的行首前插入some string

:%s/$/some string/g
在整个文件每一行的行尾添加some string

:%s/\s\+$//
去掉所有的行尾空格，“\s”表示空白字符（空格和制表符），“\+”对前面的字符匹配一次或多次（越多越好），“$”匹配行尾（使用“\$”表示单纯的“$”字符）

反向引用

%s/\(aa\)/\1-/g

修改

1.字符修改-大小写

v选中, U切换大写，u切花小写
~      光标所在之处字符大小写呼唤
guw    光标下的单词变为小写
gUw    光标下的单词变为大写

2.字符互换

xp  左右交换光标处两字符的位置

3.行-合并

J   上下两行连起来
选中多行，然后 J    多行连起来

4.操作

命令格式

c{motion}
删除并进入输入模式 c$  ct!

e.g.

ciw  change inner word, 修改当前光标下单词
cis  change inner sentence, 修改一整个句子

#text-object
ci"
ci(

cw   修改一个单词
cc   change the whole line,剪切光标所在行并进入插入模式

ctx  剪切光标至字符x，进入插入模式

删除

dG 删除至文件末尾
dgg 删除只文件开头

查找和跳转

跳转到当前行某个位置

fx  到第一个x
2fx 到第二个x

Fx  往回查找

跳转到某行

50G 移动到 50行
:50

标记并跳转

#对26个字母有效
ma 标记书签
'a 跳到书签
'.  最后一次编辑的地方

段落跳转

{   上一段(以空白行分隔)
}   下一段(以空白行分隔)

) 下一个句子
( 上一个句子

选中

操作

v   按字符
V   按行
ctrl+v 按块

命令格式

va or vi

object ：
    w 一个单词， W 一个以空格为分隔的单词，
    s 一个句子，
    p 一个段落。
    也可以是一个特别的字符："、 '、 )、 }、 ]。
注意，这里v换成d/y就成了删除，拷贝的命令

e.g.

假设你有一个字符串
    (map (+) ("foo")).

而光标键在第一个 o 的位置。
vi" → 会选择 foo.
va" → 会选择 "foo".
vi) → 会选择 "foo".
va) → 会选择("foo").
v2i) → 会选择 map (+) ("foo")
v2a) → 会选择 (map (+) ("foo"))'"

选中括号里的内容

v% 光标在一侧括号

全选

ggVG

保存和退出

:e file 打开文件
ZQ  无条件退出
ZZ  存盘退出

保存部分内容

:1,10 w a.txt
:1,10 w >> a.txt

另存为

:saveas new_file

执行外部命令

:!cmd
:r!cmd  指向外部命令的结果插入到当前

关于vim学习的建议

来自网上两篇文章

更多的是技能而非知识
更多的是双手而非头脑
Vim技巧
不贪图一下子掌握
不断实践
不是由头脑来搜索该用哪条操作技巧
而是建立手指的自然反应

一定要阅读一下Bram Moolenaar(vim的作者)写的Seven habits of effective text editing(七个有效的文本编辑习惯)

七个习惯

快速移动
不要两次键入同样的东西
错误修复
经常需要编辑不止一个文件
协同作业
文本是结构化的
养成习惯

其他

大写的

D 删除当前到行尾，不要用d$
Y 复制整行，建议改写成复制当前到行尾
C 修改当前到行尾

repeat:

. → (小数点) 可以重复上一次的命令
N → 重复某个命令N次

宏录制和使用

待补充

读书笔记--高效能人士的七个习惯+执行4原则

Sun, 30 Mar 2014 08:00:00 +0800

今天打算写的是，关于两本“成功学”的书

《高效能人士的七个习惯》和《高效能人士的执行4原则》

一直以来对“成功学”都不感冒，“虚”，“扯淡”，“毫无意义”，一直没搞明白为什么那么多人，会专门去花费大量金钱学习和研究这些东西

以前不感冒，当然，现在也是，一如既往

以上两本书，一本书是刚毕业那会部门老大推荐的，跳槽之后，新的老大也推了这本书，所以从书堆里翻出来，认认真真地看完了（很惊讶走了那么多地方书还能留着），后面一本是亚马逊kindle上捞到的。

这两本，算是成功学，也不算，很多东西讲到了点上，有些道理，认同，也会去遵循

值得一看，能从中能借鉴一些东西

高效能人士的七个习惯

习惯一：积极主动——个人愿景的原则
习惯二：以终为始——自我领导的原则
习惯三：要事第一——自我管理的原则
习惯四：双赢思维——人际领导的原则
习惯五: 知彼解己——移情沟通的原则
习惯六: 统合综效——创造性合作的原则
习惯七：不断更新——平衡的自我更新的原则

习惯一：积极主动——个人愿景的原则

人性的本质是主动而非被动地——人类确实能主动努力以提升生命价值(主观能动性)

积极主动，不仅指行事的态度，还意味着为人一定要对自己的人生负责

积极主动的人专注于“影响圈”，专心做自己力所能及的事情，能量是积极的，是影响圈不断扩大

影响圈的核心就是，作出承诺与信守诺言的能力

其他习惯的基础！！！

习惯二：以终为始——自我领导的原则

以你的人生目标作为衡量一切的标准。由个人最重视的期许或价值观来决定一切

在做任何事情之前，都需要认清方向——定目标

你以什么为中心？你为谁而活？

以原则为中心！！！！

以永恒不变的原则作为生活重心，就能建立高效能的思维定势，也就能正确审视所有其他的生活中心。(一个人的思维定式能决定他的态度和行为)

原因：主动的选择，没有受到环境和他人的影响；最有效的选择，且长期可预料；基于原则所作出的选择，能提高自身的价值。

所以，撰写使命宣言并付诸实践(确定角色和目标)

书写个人使命宣言 —— 即人生哲学或基本信念（个人宪法，基于正确原则的个人使命宣言也同样是评价一切的标准）

习惯三：要事第一——自我管理的原则

把最重要的事情放在第一位，先做重要的事情

矩阵：重要/不重要 * 紧急/不紧急

关注重要不紧急的事情

重要不紧急的事情：建立人际关系，撰写使命宣言，规划长期目标，防患于未然等等

在必要时，勇于说“不”

学会授权

习惯四：双赢思维——人际领导的原则

双赢 - 不断地在人际交往中寻求双边利益

要明确意识到其重要性

基础：信任

双赢关系

双赢的精髓就是信用，即情感账户

双赢过程：

1.要从对方的角度看问题，真正理解对方的想法
2.认清主要问题和顾虑（而非立场）
3.确定大家都能接受的结果
4.实现这种结果的各种可能途径

习惯五知彼解己——移情沟通的原则

首先寻求去了解对方，然后再争取让对方了解自己。（进行有效人际交流的关键）

你真的听懂了么？

移情聆听

以理解为目的的聆听，要求听者站在说话者的角度理解他们的思维模式和感受

不仅要耳到，还要眼到，心到。用眼睛去观察，用心灵去体会

有效的沟通：

1.第一阶段，复述语句，至少能使人专心聆听
2.第二阶段，加入解释，纯用自己的词句表达，用左脑的逻辑思考去理解
3.第三阶段，深入个人的感觉，右脑发挥作用，开始体会对方的心情
4.即加以理解，又带有感情，左右脑并用

如果你真正爱一个人，那么花时间了解对方将有益于今后的坦诚相待

习惯六统合综效——创造性合作的原则

统合综效的基本心态是——如果一位具有相当聪明才智的人跟我意见不同，那么对方的主张必定有我尚未体会的奥妙，值得加以理解

有分歧才有收获

统合综效就是整体大于部分之和

统合综效的精髓就是判断和尊重差异，取长补短

所谓统合综效的沟通，是指敞开胸怀，接纳一切奇怪的想法，同时也贡献自己的浅见

尊重差异，要尊重，不偏激

即使处于不利的境地，也不应该放弃追求统合综效。

习惯七：不断更新——平衡的自我更新的原则

拥有财富，并不代表经济独立，拥有创造财富的能力才真正可靠

自我提升和完善的四个层面：身体，精神，智力，社会/情感

不断更新，意味着要兼顾这四种要素

身体层面：

健康饮食、充足休息以及定期锻炼

    耐力：源于有氧运动
    韧性：源于伸展运动
    力量：源于持久的肌肉运动

精神层面：

人的本质，核心，对价值体系的坚持，是生活中非常私人但是至关重要的领域

智力层面：

主要靠教育，借此不断学习知识，魔力心智，开阔视野

养成定期阅读优秀文学作品的习惯

另一种有效的方式是写作，不断记录自己的想法，经历深刻见解和学习心得

社会、情感层面

在与他人的日常交往中完成，还需要必要的练习

坚守原则，肯定自我，与人为善，相信人生不止输赢两种抉择

平衡，要把握平衡！！！！！

螺旋式上升，良性循环，学习-坚持-时间，并沿着螺旋式上升的路线不断提高实践的层次

高效能人士的执行4原则

原则1：聚焦最重要的目标(Focus on the Wildly Important)

将你最好的精力集中到一两个重要的目标（能够使你得到革命性结果的事情）

日常事务（周而复始，要做但不是重点）-> <- 新目标（聚集精力在此）

好主意的数量总会超出执行能力的范围（learn to say no）

（How）最重要的目标是能够给你的组织带来巨大变化的目标：如果其他方便都保持现状的话，改进哪一个会给我们带来巨大的收益？

两类：来源于日常范围之内的（改进提升）来源于日常范围之外的（创新）

注意：没有任何团队可以同时关注两个以上的最重要目标。你选择的局部战斗必须要为赢得整个战争服务。领导可以否决，但不能独断。所有最重要的目标必须要有完成的时限和标准（SMART原则）

原则2：关注引领性指标(Act on the Lead Measures)

引领性指标是指那些和达成最终目标关系最为紧密的事情

滞后性指标（不能改变些什么，已经发生了，更容易获得，更直观）可以告诉你是否完成了目标，而引领性指标（预见性，可控性）可以教会你怎样做才能去完成目标

引领性指标，指针对最终目标而制定的，可预见可控的阶段性目标（杠杆作用->高效益）显著特征：预见性，意味着一旦某个引领性指标发生变化，你就可以根据这个推断出滞后性指标之后会有什么变化。可控的，可以被你的团队所影响，你们可以靠自己的力量使促使引领性指标发生变化

引领性指标的数据往往比滞后性指标数据更难以获取

原则3：坚持激励性计分表(Keep a Compelling Scoreboard)

这是一条激励士气的原则

确保每个人都能随时获知自己的成绩，这样他们才能知道自己领先还是落后（当面对成绩时，人们的表现将会发生变化）

将引领性指标和滞后性指标->看得见摸得着的量化指标

一个伟大的团队，在任何时候都知道自己的进度是否成功

建立激励性的选手型记分表：1.它是否简单？2.它是否显而易见3.是否能同时展示引领性指标和滞后性指标4.能否一眼从记分表上看出是否胜利

原则4：建立规律的问责制(Create a Cadence of Accountability)

建立有规律的责任机制，一个对过去表现和未来计划的有规律的周期性问责

最重要目标会议：每周，20-30分钟之内，有一套完整流程并快速进行，为工作确定每一周的节奏，从而带动最重要目标的不断进展。

两条原则：1.应该在每周的同一天的同一时间召开 2.永远不要把日常事务带到最重要目标会议中来

组成部分：

1.问责：汇报工作计划的完成情况
2.回顾记分表：寻找成功和不足
3.计划：清除障碍，作出新计划

Golang笔记-06-struct

Sun, 09 Mar 2014 06:00:00 +0800

struct

struct，一组字段的集合，类似其他语言的class

放弃了大量包括继承在内的面向对象特性，只保留了组合(composition)这个最基础的特性

1.声明及初始化

type person struct {
    name string
    age  int
}

//初始化

func main() {
    var P person

    P.name = "tom"
    P.age = 25
    fmt.Println(P.name)

    P1 := person{"Tom1", 25}
    fmt.Println(P1.name)

    P2 := person{age: 24, name: "Tom"}
    fmt.Println(P2.name)
}

2.struct的匿名字段(继承)

type Human struct {
    name string
    age int
    weight int
}

tyep Student struct {
    Human //匿名字段，默认Student包含了Human的所有字段
    speciality string
}

mark := Student(Human{"mark", 25, 120}, "Computer Science")

mark.name
mark.age

能够实现字段继承，当字段名重复的时候，优先取外层的,可以通过指定struct名还决定取哪个

mark.Human = Human{"a", 55, 220}
mark.Human.age -= 1

struct不仅可以使用struct作为匿名字段，自定义类型、内置类型都可以作为匿名字段,而且可以在相应字段上做函数操作

3.method

type Rect struct {
    x, y float64
    width, height float64
}

//method

Reciver 默认以值传递，而非引用传递，还可以是指针
指针作为Receiver会对实例对象的内容发生操作，而普通类型作为Receiver仅仅是以副本作为操作对象，而不对原实例对象发生操作

func (r ReciverType) funcName(params) (results) {

}

如果一个method的receiver是*T，调用时，可以传递一个T类型的实例变量V，而不必用&V去调用这个method

func (r *Rect) Area() float64 {
    return r.width * r.height
}

func (b *Box) SetColor(c Color) {
    b.color = c
}

4.method继承和重写

采用组合的方式实现继承

type Human struct {
    name string
}

type Student struct {
    Human
    School string
}

func (h *Human) SayHi() {
    fmt.Println(h.name)
}

//则Student和Employee的实例可以调用
func main() {
    h := Human{name: "human"}
    fmt.Print(h.name)
    h.SayHi()

    s := Student{Human{"student"}}
    s.SayHi()

}

还可以进行方法重写

funct (e *Student) SayHi() {
    e.Human.SayHi()
    fmt.Println(e.School)
}

读书笔记——我编程，我快乐

Sat, 08 Mar 2014 08:00:00 +0800

这是读到的第四本和37signals有联系的书

春节在回家的动车上读完的(飞机火车阅读效率加成>_<)，有些收获，今天翻出来重读了一次

一系列观点和方法论，很多还是值得借鉴和思考的

记录观点以及自己一两句话的总结整理

这本书还是值得一读的，建议入手

PS:年后买纸质书需三思再三思，开始多读电子书吧

简而言之:

1.选好技术和领域: 通才和专家
2.跟上潮流
3.学会更好更高效地工作：目标，计划，沟通，协作，写作，执行力....很多（重点）
4.避免思维僵固
5.写博客
6.维护自己的开源项目

帮你成就更卓越、更有意义的人生，工作只是其中的一部分

如果生活的大部分时间都被工作占据着，那么热爱工作就是热爱生活

制定自己的计划

1.选择市场——关注的技术和商业领域
2.投资——知识和技术
3.执行——更好地产出
4.市场

第一章选择市场

1. 稳定成熟的技术还是未成熟的技术？

前瞻性，业界

决定权在你自己手中

无论做出哪种选择，最终的目的是，产生利润

2. 供应和需求

供需关系导致的薪资变化

不要再价格上竞争，你承受不起

需要在能力上与之抗争,更高层面

发现市场上的不平衡

3. 只会编程是不够的

必须要深入了解你所处的领域

你的行业经历应该成为你的重要才能

仔细思考在哪个商业领域投入时间

4. 做团队中最差的

和优秀的人一起工作

与一个团队合作时间长了，会对自身的能力产生持久的影响

你身边的人会对你产生很大的影响，明智地选择你的圈子

5. 在思维上投资

没人给过我机会….?要学会抓住机遇

6. 不要听从父母

父母总不希望儿女去冒险

在职业道路上，需要一些有目的性的冒险。别让恐惧征服了你

7. 做一名通才

传说中的全栈？

通才很少，所以珍贵

IT职业分解

- 职业阶梯的各层
- 平台和操作系统
- 代码和数据
- 系统和应用
- 业务和IT

学会适应以及胜任不同角色的价值所在

你的技术应该超越技术平台

8. 成为一名专家

很多人认为专攻某种技术就简单地意味着不知道其他技术

很显然，这是错误的

能搞定工作中遇到80%可预见的问题，并且有足够的知识来应付另外还未出现的20%的问题

9. 切忌孤注一掷

以特定技术厂商为中心的观点，缺乏远见

的确如此，厂商悲催了，你承受不了代价

10. 热爱它，不然就离开它

工作，因为你无法停止工作

第二章在产品上投资

11. 学会钓鱼

需要主动问，不要等着别人来告诉你

要自己主动学习，自学能力

12. 学习行业是如何运转的

只有了解了一个行业后，你才能创造性地有所建树

业务领域很重要

13. 寻找良师

可以依赖别人，但需确保这个人是靠得住的

减少试错成本

14. 做一名良师

想要弄明白自己是不是真的懂得某一知识，那就把它讲给其他人听

做导师不会下岗

15. 练习、练习、再练习

需要刻意练习

在极限处练习

16. 做事的方法

想要拥有自己的步骤，那就执行它

学习，实践某些方法论，优化工作流

17. 站在巨人的肩膀上

从现有的程序中得到领悟

学习其他程序猿是如何系统地解决某一特定问题的

用现有的程序反思自己的程序

需要有更开阔的眼界

18. 在工作中，将自己自动化

找出消耗你时间的东西，自动化之

第三章执行

19. 就是现在

流程问题？拖延症等？

就现在，我们能做些什么？

帕金森定律：工作会自动膨胀到占满所有可用的时间

开始行动，不要总是安于现状，要做推动者(活血这正是我目前缺乏的)

20. 读心术

仔细观察，倾听，了解所需要做的，所能改善的(前提，你了解的信息时正确的)

读心术用得好，人们就会信任你

21. 每日成绩

每天都有可汇报的成绩

记录目标，并记录下来

22. 别忘了你在为谁工作

确保你的目标和工作与你公司的目标一致

即使不愿意，但需要绝对的执行力

在结构良好的环境中，经历的目标，就是整个团队的目标，解决了经历的问题，就是解决了整个团队的问题

好的经理的职责应该是为团队设定优先级，确保团队具备完成工作的一切需要，保证团队保持干劲和工作效率，并出示团队最终顺利完成工作。

23. 安分守己

要有雄心，但不必路人皆知

专注于现在的工作

做好当下正确的事情

24. 今天我能把工作做到多好？

你能为工作增添多少乐趣

发挥创造力来应对那些平凡的工作

25. 你的价值多少

了解公司在你身上的开销和你的产出

问自己"今天实现自己的价值了么"

26. 一桶水中的鹅卵石

如果你明天离开公司，对公司造成的影响与其他同事离开有没有区别？

永远不要高枕无忧

小心，别让成功冲昏了头脑

要学会让自己不可替代，要建立一种友好的工作关系

同时也要知道，每个人都不是不可替代的，清楚知道这一点，并努力工作

27. 爱上维护

人们都喜欢创造

维护也可以成为自由和创造的沃土

最小开支维持软件正常运行

可以设计更可见的改进

可以有机会和其他客户直接进行交流

最讽刺的是，项目工作其实就是维护，只要项目团队写下来的第一行编码。

28. 8小时激情燃烧

在工作上，更少的工作时间可以有更高的效率

创造力和工作质量

做项目像是马拉松，而不是全速短跑

减少工作时间，你的收获更多

29. 学习如何失败

带着防御性错失进行编程是很重要的

每个错误的音调离正确的音调不过一步之遥

解决计数、沟通或者项目管理中的错误

- 发现错误第一时间提出，不要企图隐瞒错误
- 接受批评
- 提供解决方法
- 寻求帮助

充满压力的时候是赢得忠诚的最好时机

30. 说"不"

为了避免失望而说“是”，就是在说谎

这不是个好习惯

要勇于诚实

31. 不要恐慌

英雄从不恐慌

恐慌会导致丧失判断力

遇到问题，分析情境，获取意见，换角度思考问题

32. 说出来、行动、展示

承诺 - 做计划

状态报告可以帮助你推销自己

做计划时要时刻谨记的是，出现在计划上的每一项工作必须是要与后续工作相关，要么被完成、推迟、去除或被替代

碰到问题，做出计划来解决问题，而不是抱怨

第四章推销,不仅仅是迎合

表面上看，宣传自己很简单

你的目标有两个

- 让别人知道你的存在
- 以及让他们知道，当他们碰到难题时，你是那个可以解决问题的人

33. 不要忽视感觉

如果你非常出色，但并没有人知道，那你真的优秀么？谁会在意？没人会在意(很残酷，但是是对的)

绩效考核永远不会是客观的(很不幸，这句也是对的)

任何地方对你的评价都是主观的，意味着对你做出的评价总是基于别人对你的感觉

34. 探险向导

客户害怕您

让人们了解到你的沟通能力是非常重要的

35. 学会沟通，善与写作

文字表达能力非常重要

你自己就是你需要解释的内容

36. 到场

能够与上司和客户面对面地沟通是你的优势，不要浪费这个机会

面对面沟通是必要的

了解你的同事

37. 适当的语言

请用行业术语推销你的成就

38. 改变世界

带着任务去上班，并确保别人知道你的任务

如果你不知道自己要做的改变是什么，那你就没有在做任何改变

如果你没有主动让自己获得承认，那你就还没有获得承认

39. 让人们听到你的声音

暮光放的更远一些，不要把自己局限在某一特定公司中的程序员

博客文章代码

40. 创建自己的商标

你的名字就是你的商标

Google永远不会忘记

41. 发布你编写的程序

开源

人人都能使用Rails,但很少有人能开发出Rails

42. 变为卓越的能力

卓越的意思是值得被关注

展示或者让它死亡

43. 建立关系

恐惧感是我们无法接近专业人士

第五章保持技术领先

44. 已经过时的技术

需要想想，哪些为何过时，哪些又不会？

你引以为傲的新技术已经过时了

时间就是一切，学习之前要先动动脑子

这就像是赌博，但是如果你不参加，就一定会输(….)

向前看，清楚地知道你的技术发展方向

45. 你已经失去工作了

你不是你的工作

任何事情都是处于变化之中

永远不要把自己当成一名程序员（记住这一点）

不要给自己设限

46. 没有终点的道路

职业生涯，最重要的部分不是晋升或者加薪，而是想这些发展方向努力工作的过程，或者，更重要的是，你抛开着一切忘我工作的过程

不要关注结果，需要关注做事情的过程

（但是考核的时候，结果为导向?）

都有个度的问题

47. 给自己一份蓝图

不要原地踏步

个人产品路线蓝图是用来判断你是否在不断向前发展的依据

48. 要注意观察市场变化

留意那些技术达人

防止被淘汰哈

49. 镜子里的胖子

自身很那去观察注意自己的职业发展

找一个可信赖的第三方，是衡量进步的简单方法

开发员们，要自我反省

评价系统！

50. 南印度捉猴陷阱

价值僵固：当你过于坚信某事的价值时，就会无法客观地来评判它

价值僵固是你脆弱

语言之争，编辑器之战等等

51. 避免瀑布型职业计划

职业改变不仅是有可能的，并且是非常必要的

从实践中学习，不断改变你的目标

52. 每天都有进步

每一个改变之后，你可能无法看到整体发生明显的不同

量变引起质变

即使一点小进步，你也应该感到高兴

人，总是不断在进步和成长的，多读些书，多学写一些东西

53. 独立

独立不是件简单的事情，这把你所有的技术作为一个专业来测试

把它当做是个人发展项目

好奇，是一种优点

读书笔记——写给大家看的设计书

Sun, 02 Mar 2014 08:00:00 +0800

对设计，知之甚少，战5渣

读到这本书，感觉蛮有收获的，起码会有一个基本的设计意识和概念，有些作用

这本书主要围绕设计的四个基本原则展开说明，有详细的说明和对比案例

设计原则

得到优秀的设计

1.学习四大基本原则
2.认识到自己没有运用这些原则
3.应用基本原则

1.亲密性

将相关项目组织在一起：移动这些项，使它们的物理位置互相靠近。
相关的项将被看做凝聚为一体的一个组，而不再是一堆彼此无关的片段

亲密性意味着存在关联

注意，人们查看时的视觉感受，顺序(视线如何移动的，起点-路径-结束)、停留、重点。将有很近的亲密性的多个项目放一起，成为一个视觉单元

如果某些元素在理解上存在关联，或者相互之间存在某种关系，那么这些元素在视觉上也应当有关联

亲密性也同时意味着，对非亲密项进行隔离（利用空白、线、图等）,使孤立

位置是否靠近可以体现出元素之间是否存在关系

需要对所有元素有一个分类组织的过程

亲密性的根本目的是视线组织性(条理性)

条理，意味着更容易被阅读和记住

要避免的问题

不要仅仅因为有空白就把元素放在角落或者中间
避免一个页面上有太多孤立的元素
不要再元素之间留出相同大小的空白，除非各组同属于一个子集
不属于同一组的元素之间一定不要建立关系

2.对齐

任何元素都不能在页面上随意安放，每一项都应当与页面上的某个内容存在某种视觉联系

对齐-更内聚的单元，虽然其物理位置可能是彼此分离的

建立一种看不见的关联

应该找到一条明确的对齐线，并用它来对齐(皆为线)

左对齐和右对齐看起来外观更为清晰,效果更分明，而居中对齐不是，所以，尽量避免，多留意居中对齐的效果是否是你想要表达的。当然，慎用两端对齐

勇敢一些，不要畏缩

在得到更多培训之前，一定要坚持一个原则：页面上只是用一种文本对齐（所有文本都左对齐、右对齐或者居中）,避免混合使用多种对齐方式

如果使用两种，需要懂得，聚聚项目之间的布局关系

根本目的

是页面统一而且有条理

统一性：页面上所有元素看上去统一、有联系而且彼此相关，需要在各个单独的元素之间存在某种视觉纽带

要特别注意元素放在哪里。应当总能在页面上找出与之对齐的元素，尽管这两个对象的物理位置可能相距很远

3.重复

设计的某些方面需要在整个作品中重复

读者看到的任何方面都可以作为重复元素：字体，线，项目符号，颜色，设计要素，某种格式，空间关系

重复有助于组织信息:利于将设计中单独的部分统一起来，可以帮助读者浏览各个页面

重复的最大好处是是各项看起来同属一组,虽然元素看起来都不完全相同.变换成一致的外观

重复，将各个部分连在一起，从而同意并增强整个作品，否者这些部分只是彼此孤立的单元

根本目的：

统一，并增强视觉效果

如何实现

可以认为是保持一致性：需要把现有的一致性更向前推进一步

要避免的问题

避免太多地重复一个元素，重复太多会让人讨厌.要注意对比的价值

4.对比

如果两个项不完全相同，就应当使之不同，而且应当是截然不同

要想实现有效地对比，对比就必须强烈！千万不要畏畏缩缩

设计页面很少只是用某一种原则

在页面上增加对比能吸引眼球，我们的眼睛喜欢看到对比的事物

根本目的

增强页面效果：更有意思，更好的可读性
有效于信息的组织

如何实现

最简单方法是实现字体对比，也可以利用线宽、颜色、大小、空间、元素之间间隔、材质等形成对比
重要的是：对比一定要强烈

避免的问题

不要犹豫，如果想形成对比，就加大力度

提高视觉敏感度

从好的设计中获得理念，寻找灵感

5.设计过程

1.从中心点开始
确定希望读者最新看什么。除非你已经决定要建立一个非常协调的设计，否则就应该创建一个有强烈对比的中心店

2.将信息分组
按逻辑进行你分组，确定这些组之间的关系。通过组之间靠近与否来显示这些关系
在页面上组织文本和图片时，要建立并维护明确的对齐
创建重复，或者找出可以重复的项，建立重复
除非你已经决定要建立一个非常协调的设计，否则就应该创建强烈的对比

书中还有关于颜色选择、字体设计的部分章节，需要可以自查

总的来说，很好的一本书，推荐

wklken

2014-03-02 于深圳

Golang笔记-05-函数

Sun, 02 Mar 2014 05:00:00 +0800

函数

Go语言里面的核心设计，通过关键字func来声明

func funcName(input type1, input2 type2) (output1 type1, output2 type2) {
    //logical code
    return value1, value2
}

基本语法

1.语法

//一般函数
func func_name(a int) {
    println(a)
}

//多参数，无返回值
func func_name(a, b int, c string) {
    println(a, b, c)
}

//单个返回值
func func_name(a, b int) int { //同类型，可以省略  a, b int
    return a + b
}

//多个返回值
func func_name(a, b int) (c int, err error) {  //返回值还可以是   (int, error)
    return a+b, nil
}

func SumAndProduct(A, B int) (int, int) {
    return A+B, A*B
}

2.说明：

关键字func声明
可以有一个或多个参数，每个参数后面带有类型,通过","分隔函数可以返回多个值
返回值声明，可以只声明类型
    如果没有返回值，可以省略最后的返回信息
    如果有返回值，必须在外层添加return


Go函数不支持嵌套(nested),重载（overload）和默认参数(default parameters)
支持：
    1.无需声明原型
    2.不定长度变参
    3.多返回值
    4.命名返回值参数
    5.匿名函数
    6.闭包

注意：
    函数使用func开头，左大括号不能另起一行

小写字母开头的函数指在本包内可见，大写字母开头的函数才能被其他包调用

多返回值及命名返回参数

可以像python那样返回多个结果，只是非tuple

对于不想要的返回值，可以扔垃圾桶_

如果用命名返回参数，return语句可以为空。return 不为空，返回值顺序是return的顺序而非在函数头声明的顺序

package main

func change(a, b int) (x, y int) {
    x = a + 100
    y = b + 100

    return   //101, 102
    //return x, y  //同上
    //return y, x  //102, 101
}

func main(){
    a := 1
    b := 2
    c, d := change(a, b)
    println(c, d)

如果命名返回参数被代码块中的同名变量覆盖了，就必须使用显式return返回结果

不需要强制命名返回值，但是命名后的返回值可以让代码更加清晰，可读性更强

参数传递:传值与传指针

指针, Go保留指针，用".“而非”->“操作指针目标对象成员操作符

& 取变量地址
* 通过指针间接访问目标函数

func add1(a int) int {
    a = a + 1
    return a
}

x := 3
x1 := add1(x)
x //3
x1 //4
传值，x1的值没有改变

func add2(a *int) int {
    *a = *a + 1
    return *a
}
x := 3
x1 := add2(&x)
x // 4
x1 // 4

传指针多个函数能操作同一个对象

传指针比较轻量级(8byte)，只是传内存地址，我饿们可以用指针来传递体积大的结构体

Go语言中，string,slice,map这三种类型的实现机制类似指针，所以可以直接传递，而不用取地址后传指针

注意，若函数需要改变 slice长度，仍需要取地址传指针

参数传递:可变参数

变参本质上就是一个slice，且必须是最后一个形参

将slice传递给变参函数时，注意用…展开，否则会被当做dang单个参数处理，和python类似

package main

func sum(s string, args ...int)  {
    var x int
    for _, n := range args {
        x += n
    }
    println(s, x)
}
func main(){
   sum("1+2+3=", 1, 2, 3)

   x := []int{0,1,2,3,4}
   sum("0+1+2+3=", x[:4]...)
}

...type类型只能作为函数的参数类型存在，并且是最后一个参数
本质上是一个数组切片，即[]type

任意类型的不定参数

func Printf(format string, args ...interface{}) {
}

匿名函数

f := func(x,y int) int {
    return x + y
}

函数作为值、类型

在Go语言中，函数也是一种变量，可以通过type来定义它,它的类型就是所有拥有相同的参数，相同的返回值

语法
type typeName func (input1 inputType1, input2 inputType2 [, ....]) (result1 resultType1 [,....])

用法e.g.1

type testInt func(int) bool //声明了一个函数类型

func filter(slice []int, f testInt) []int {
    var result []int
    for _, value := range slice {
        if f(value) {
            result = append(result, value)
        }
    }
}

func isOdd(integer int) bool {
    if integer % 2 == 0 {
        return false
    }
    return true
}

filter(a, isOdd)

这种用法，在写接口的时候非常有用

用法e.g.2

可以定义函数类型，也可以将函数作为值进行传递(默认值nil)

package main

//定义函数类型callback
type callback func(s string)

//定义一个函数，可以接收另一个函数作为参数
// sum为参数名称， func(int, int) int为参数类型
func test(a, b int, sum func(int, int) int)  {
    println( sum(a,b) )
}

func main(){
    //演示1
    var cb callback
    cb = func(s string) {
        println(s)
    }
    cb("hello world")

    //演示2
    test(1, 2, func(a, b int) int {return a + b})
}

结果：

hello world
3

Golang笔记-04-array/slice/map

Sun, 02 Mar 2014 04:00:00 +0800

一.Array

在Go语言中，数组是一个值类型(value type)

所有的值类型变量在赋值和作为参数传递时都将产生一个复制动作

如果作为函数的参数类型，则在函数调用时参数发生数据复制，在函数体中无法修改传入数组的内容

数组相等用 = != 比较，不能用 < >

1.声明&赋值

初始化

语法
var VarName [n]type     // n>=0

e.g.
var a [5]int //[0 0 0 0 0]
var c [2][3]int //二维

var b int = [5]int{1,2,3,4,5} //声明并初始化

a := [3]int{1,2,3}
b := [10]int{1,2,3} //前三个元素，其他为0
c := [20]int{19:1} //第20个元素初始化为1，其他默认0
d := [...]int{4,5,6} //自动计算长度
e := [...]int{0:1, 1:2, 19:3} //自动推断


二维数组
doubleArray := [2][4]int{[4]int{1,2,3,4}, [4]int{5,6,7,8}}
easyArray := [2][4]int{{1,2,3,4}, {1,2,3,4}}
多维 [...][n] 前者可推断，但是后者必须显示赋值

数组的长度是该数组类型的一个内置常量

arrLength := len(arr)

注意，数组长度也是类型的一部分，因此不同长度数组为不同类型(内置常量)

即[3]int和[4]int是不同类型，并且数组不能改变长度

数组之间的赋值是值的赋值，即当把一个数组作为参数传入函数的时候，传入的其实是该数组的副本(一次复制操作)，而不是它的指针，如果要传入指针，使用slice

2.元素访问

for i:=0; i < len(array); i++ {
    fmt.Println(i, array[i])
}

for i, v := range array {
    fmt.Println(i, v)
}

可以用new创建数组

p := new([10]int)
返回一个指向数组的指针

注意区分

指向数组的指针
a := [100]int{}
var p *[100]int = &a

指针数组
x, y = 1, 2
a := [...]*int{&x, &y}

二.Slice

数组切片就像一个指向数组的指针，但更复杂，实际上它拥有自己的数据结构，而不仅仅是指针(指向原生数组的指针 + 数组切片中元素个数 + 数组切片已分配的存储空间)

一个引用类型，总是指向一个底层array，声明可以向array一样，只是不需要长度

slice就像一个结构体，包含三个元素

一个指针，指向数组中slice指定的开始位置
长度，即slice的长度
最大长度，也就是slice开始位置到数组的最后位置的长度

1.声明&赋值

通过array创建

var myArray [10]int = [10]int{1,2,3,4,5,6,7,8,9,10}
var mySlice []int = myArray[:5]

a := [5]int{1,2,3,4,5}
b := a[2:4]
b := a[:4]
b := a[2:]

从数组或已存在的slice再次声明
var ar [10]byte {'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j'}

var a, b []byte
a = ar[2:5]
b = ar[3:5]

直接创建

myslice1 := make([]int, 5)
myslice2 := make([]int, 5, 10) //初始个数5，预留10个元素的存储空间
myslice3 := []int{1,2,3,4,5}

2.元素访问

for i:=0; i


3.其他操作
大小和容量
len获取slice的长度
cap获取slice的最大容量

动态增减元素
append想slice里面追加一个或者多个元素，然后返回一个和slice一样类型的slice

//append
mySlice = append(mySlice, 1, 2, 3) //增加三个元素
mySlice = append(mySlice, mySlice2) //增加另一个

注意，append会改变slice所引用的数组的内容，从而影响到引用统一数组的其他slice，
     但当slice中没有剩余空间，此时动态分配新的数组空间返回的slice数组指针将指向这个空间，
     而原数组的内容将保持不变，其他引用此数组的slice不受影响(坑，可能引入bug)

内容复制
copy，从源slice的src中复制到目标dst，并且返回复制元素的个数
copy(dst, source) //会按短的个数复制

slice1 := []int{1,2,3,4,5}
slice2 := []int{5,4,3}

copy(slice2, slice1) //复制slice1前三个 1 -> 2
copy(slice1, slice2) //复制slice2的前三个 2 -> 1

切片
默认开始位置0，ar[:n]等价于ar[0:n]
第二个序列默认是数组长度 ar[n:] 等价于 ar[n:len(ar)]
从一个数组直接获取slice，可以是ar[:]

slice是引用类型，所以当改变其中元素的时候，其他的所有引用都会改变
aSlice = array[3:7]
bslice = aSlice[:3]

三.Map
Python中字典的概念
map是无序的,长度不固定，内置的len可以用于map,可以方便的修改
1.声明&赋值
map[keyType]valueType

var m map[string] PersonInfo
m = make(map[string] personInfo[, 100])

var numbers map[string]int
or
numbers := make(map[string]int)
numbers["one"] = 1

初始化一个字典
2.元素访问
rating := map[string]float32 {"c":5, "Go":4.5}

csharpRating, ok := rating["C#"]
if ok {
    fmt.Println("get the value")
} else{
    fmt.Println("error")
}

3.基本操作
赋值
m["1234"] = PersonInfo{}

删除
delete(m, "1234")

四.其他
make和new操作
make用于内建类型(map,slice,channel) 的内存分配。

new用于各种类型的内存分配

new本质上和其他语言中同名函数一样, new(T)分配了零值填充的T类型的内存空间，并返回其地址，即一个*T类型的值
即，返回一个指针，指向新分配的类型T的零值
make(T, args)，只能创建slice,map,channel，并返回一个有初始值（非零值）的T类型，而不是*T。
本质来讲，导致这三个类型有所不同的原因是，指向数据结构的引用在使用前必须被初始化



Golang笔记-03-控制流
Sun, 02 Mar 2014 03:00:00 +0800
控制结构分为： 条件+选择+循环
IF
1.说明
条件表达式没有括号
支持一个初始化表达式（可以是多变量初始化语句）
初始化语句中定义的都是只能在block级别中使用的局部变量，不能在block之外使用
左大括号必须和条件语句在同一行(必须与if/else在同一行)
go没有三元运算符

if判断语句条件不需要括号
在判断语句里卖弄允许声明一个变量，其作用域只在逻辑块内，其他地方不起作用
花括号一定存在，且必须与if/else在同一行

2.语法
//基本
if a > 0 {  //无括号
     dosomething()
} else if a == 0 { //必须用花括号
     doothertings()
} else {
     donothing()
}

//单行模式
if a > 0 { a += 100 } else { a -= 100 }

3.示例
package main

func main(){
    a := 10

    if a > 0 {
        a += 100
    } else if a == 0 {
        a = 0
    } else {
        a -= 100
    }
    println(a)

    b := 101
    if b > 0 { b += 100 } else { b -= 100 }
    println(b)
}

//支持一个初始化语句
if a:=1; a<10 { //允许在条件之前执行一个简单语句，由此语句定义的变量作用域仅在if/else范围内
    return a
}
if a, b := 1,2; a+b == 10 {
}

if x := computedValue(); x > 10 {
} else {
}

4.结果
110
201

注意，在有返回值的函数中，不允许将“最终的”return语句放到if … else … 结构中，否则编译失败
func example(x int) int {
    if x == 0 {
        return 5
    } else {
        return x
    }
}

FOR
for是go的"while", 只支持for关键字.有三种形式
1.语法
for init; condition; post {
    //init不支持逗号，只能平行赋值
    //condition每次循环开始都会检查，不建议在里面使用函数，建议用计算好的变量/常量代替
    //post后面必须跟花括号,每轮循环结束的时候调用
}

for i:=0; i<10; i++ {
}

-----------------------------

for condition {
    dosomething()
}

i:=1
for i<10 {
}

-----------------------------

for { //无限循环
    dosomething()
}

for {
    a++
    if a > 10 {
        break
    }
}

-----------------------------

2.说明
a. 初始化和步进表达式可以使多个值：必须使用平行赋值
    i, j:=0,len(a)-1; i

3.示例
package main

func main(){
    ss := "abcd"
    for i:=0; i

得到：
97
98
99
100

4.配合range
for循环和保留字range一起使用，完成迭代器iterator操作
string, array, slice, map, channel都可以用range进行迭代器操作
range返回序号和值，若是不想要，可以用_
  for i, c := range "abc" {
      fmt.Printf("s[%d] = %c\n", i, c)
  }

得到
  s[0] = a
  s[1] = b
  s[2] = c

SWITCH
python里面没有
1.语法
支持初始化表达式
switch a:=5; a { //默认break，匹配成功后不会自动向下执行其他case,而是跳出整个switch
    case 0:         //普通
        println(a)
    case 1, 2:      //多个分支，逗号分隔
        println(a)
    case 100:       //什么都不做
    case 5:
        println(a)
        fallthrough   //进入后面的case 进行处理，而不是跳出block
    default:
        println(a)    //默认
}
注意，不需要break来明确退出一个case，一旦条件符合，自动终止,除非使用fallthough

--------------

可以不带表达式
switch sExpr {
        case expr1: //sExpr和expr1必须类型一致,不限制为常量或者证书，可以用任何类型或表达式
            ...
}

switch {
    case 0 <= Num && Num <= 3:
        fmt.Printf("3")
}

几种形式:
a := 1
switch a {
    case 0:
        ...
}

a := 1
switch {
    case a>=0:
        ....
    case a>1:
        ....
}

switch a:=1; {
    case a>=0:
        ...
    case a>1:
        ...
}

2.替代if…else if…else…
不指定switch 条件表达式(没有条件表达式，在case语句中有)，或者直接为true
  a := 5
  switch {     //两句可合并位 switch a:=5; {
      case a > 1:
          println("a")
      case a > 2:
          println("b")
      default:
          println("c")
  }

goto break continue
均可配合标签使用(标签区分大小写，若声明了没有使用会导致编译错误)
break/continue可配合标签用于多重循环跳出
goto是调整执行位置，与其他两个执行结果并不相同

1.goto
支持函数内部goto跳转

请善用

必须跳转到当前函数内定义的标签,标签名大小写敏感

func myFunc() {
    i := 0
Here:
    println(i)
    i++
    goto Here
}

2.continue
进入下一次循环

3.break
终止循环

for index := 10; index > 0; index -- {
    if index == 5 {
        break //continue
    }
}

示例
package main
func main(){
    a := 1
    LABEL1:
        println("inc a=", a)
        a += 1

    LABEL2:
        //println("here")

    for ; a < 6; {
        println(a)
        if a == 3 {
            a += 1
            continue LABEL2
        }
        if a == 5 {
            break
        }
        goto LABEL1
    }
}

结果:
inc a= 1
2
inc a= 2
3
4
inc a= 4
5




Golang笔记-02-类型、变量、常量
Sun, 02 Mar 2014 02:00:00 +0800
基本类型
1.基本类型列表
类型        长度     说明
bool         1      true/false,默认false, 不能把非0值当做true(不用数字代表true/false)
byte         1      uint8 别名
rune         4      int32别名。 代表一个unicode code point
int/unit            一来所运行的平台，32bit/64bit
int8/uint8   1     -128 ~ 127; 0 ~ 255
int16/uint16 2     -32768 ~ 32767; 0 ~ 65535
int32/uint32 4     -21亿 ~ 21亿， 0 ~ 42亿
int64/uint64 8

float32      4     精确到7位小数,相当于c的float
float64      8     精确到15位小数,相当于c的double

complex64    8
complex128   16

uintptr            足够保存指针的32位、64位整数,指针(可以存指针的整数型)
array              值类型,数组
struct             值类型,结构体
string             值类型,字符串类型，常用
slice              引用类型,切片
map                引用类型,字典
channel            引用类型,通道
interface          接口类型,接口
function           函数类型,函数

2.类型转换
不支持隐式类型转换，必须进行显式类型转换
转换只发生在两种互相兼容的类型之间: 各类int不允许相互赋值或操作，不然会在编译时报错
(expression)

示例
package main
import "fmt"

func main(){
    a := 0x1234
    b := 1234.56
    c := 256

    fmt.Printf("%x\n", uint8(a))
    fmt.Printf("%d\n", int(b))
    fmt.Printf("%f\n", float64(c))
}

结果
34
1234
256.000000

3.类型别名
type t_str string
var b t_str = "a str"

4.类型默认值
声明不赋值，类型零值，非空值,而是声明后的默认值
bool: false
integers: 0
floats: 0.0
string: ""
pointers,functions,interfaces,slices,channels,maps: nil

保留字
break      case   chan     const        continue
default    defer  else     fallthrough  for
func       go     goto     if           import
interface  map    package  range        return
select     struct switch   type         var

变量
1.变量声明
//第一种，指定变量类型，声明后若不赋值，使用默认值
var v_name v_type
v_name = value

//第二种，根据值自行判定变量类型
var v_name = value

//第三种，省略var, 注意 :=左侧的变量不应该是已经声明过的，否则会导致编译错误.
v_name := value

e.g.
var a int = 10
var b = 10
c : = 10

示例：
package main
var a = 1234
var b string = "hello"
var c bool

func main(){
    println(a, b, c)
}

结果：
1234 hello false

2.多变量声明：
//类型相同多个变量, 非全局变量
var vname1, vname2, vname3 type
vname1, vname2, vname3 = v1, v2, v3

var vname1, vname2, vname3 = v1, v2, v3 //和python很像,不需要显示声明类型，自动推断

vname1, vname2, vname3 := v1, v2, v3 //出现在:=左侧的变量不应该是已经被声明过的，否则会导致编译错误


//类型不同多个变量, 全局变量, 局部变量不能使用这种方式
var (
    vname1 v_type1
    vname2 v_type2
)

示例：
package main

var x, y int
var (  //这种只能出现在全局变量中，函数体内不支持
    a int
    b bool
)

var c, d int = 1, 2
var e, f = 123, "hello"

//这种不带声明格式的只能在函数体中出现
//g, h := 123, "hello"

func main(){
    g, h := 123, "hello"
    println(x, y, a, b, c, d, e, f, g, h)
}

结果：
0 0 0 false 1 2 123 hello 123 hello

注意：
A.多变量赋值时，将先行计算所有左侧变量的值，再进行赋值

    i := 0
    i, l[i] = 1, 2
    //get i = 1， l[0] = 2


    sc[0], sc[0] = 1, 2
    //get sc[0] = 2

B.垃圾桶_

    func test()(int, string) {
        return 123, "abc"
    }

    a, _ := test()

C.已声明但是没有使用的变量会在编译阶段报错，较Python 更为严格

常量
常量可以是字符，字符串，布尔或数字
常量赋值是编译期的行为
1.常量声明
在编译阶段就能确定下来的值,在运行时无法改变该值
常量可以定义为数值、布尔值或字符串等类型

const constantName = value
const Pi float32 = 3.1415926

const c_name [type] = value
const c_name1, c_name2 = value1, value2
const (
    c_name1 = vluae1
    c_name2 = value2
)

=右侧，必须为常量或常量表达式，如果使用到了函数，必须为内置函数（编译期行为）

const i = 10000

说明：
A.常量必须是编译期能确定的Number(char/integer/float/complex)、String和bool

B.在定义常量数组时，如果不提供初始化值，则表示与上行常量类型，值，完全相同

    const (
        a = "abc"
        b
    )
    //则 b = "abc"

C.常量可以用len(), cap(), unsafe.Sizeof()常量计算表达式的值.  常量表达式中，函数必须是内置函数，否则编译不过

    package main

    import "unsafe"
    const (
        a = "abc"
        b = len(a)
        c = unsafe.Sizeof(a)
    )

    func main(){
        println(a, b, c)
    }


结果：    abc 3 16

###枚举
iota，特殊常量，可以认为是一个可以被编译器修改的常量
在每一个const关键字出现时，被重置为0，然后再下一个const出现之前，每出现一次iota，其所代表的数字会自动增加1
不提供初始值，则表示使用上一行的表达式
1.声明：
iota生成从0开始的自动增长枚举值，意味着，多一个枚举值，iota+=1，无论是否使用
基本语法
const (
    a = 1
    b = 2
)

const (
    a = iota //0
    b  //1
    c  //2
)

const (
    _ = iota
    a    //1
    b    //2
)

iota用法
func main() {
    const (
            a = iota  //0
            b   //1
            c   //2
            d = "ha"  //独立值，iota += 1
            e    //"ha"   iota += 1
            f = 100    //iota +=1
            g     //100  iota +=1
            h = iota  //7,恢复计数
            i      //8
    )

}

const (
    x = iota // 0
    y = iota // 1
    z = iota // 2
    w //省略，默认和前面一样字面值   w = iota, 即3
)
const v = iota //遇到const关键字，iota重置

注意: 每行的变量数必须一致
const (
A, B = iota, iota
C, D
E, F
)
func main() {
    println(A,B,C,D,E,F)
}

//结果： 0 0 1 1 2 2   【各自增长】

运算符
Go运算符全部是从左到右结合的
不支持运算符重载
优先级    运算符                        说明
  高   * / % << >> & &^(AND NOT)
       + - ! ^
       == != < <= > >=
       <-                             channel运算符
       &&
  低   ||

在go中，++ –为语句，而非表达式
package main

func main(){
    i := 1
    i ++
    println(i)

    b := i
    println(b)

    //syntax error: unexpected ++, expecting semicolon or newline or }
    //c := i++
    //意味着, ++/--不能出现在等号右侧
}

指针
Go保留了指针， *T表示T对应的指针类型
如果包含包名， 则应该是 *.T
代表指针类型的符号 ‘*’ 总是和类型放在一起，而不是紧挨着变量名
同样支持指针的指针**T
1.声明
var a, b *int

2.说明
操作符&取变量地址，用*透过指针变量间接访问目标对象
默认值是nil,没有NULL常量
不支持指针运算，不支持‘->'预算福，直接'.'选择符操作指针目标对象成员
可以在unsafe.Pointer和任意类型指针间进行转换
可以将unsafe.Pointer转换为uintptr,然后变相做指针运算，uintptr可以转换为整数

3.示例
package main
import "fmt"

type User struct {
    Id int
    Name string
}
func main(){
    i := 100
    var p *int = &i  //取地址

    println(*p)   //取值


    up := &User{1, "Jack"}
    up.Id = 100  //直接取只针对想成员
    fmt.Println(up)

    u2 := *up  //拷贝对象
    u2.Name = "Tom"
    fmt.Println(up, u2)
}

4.结果：
100
&{100 Jack}
&{100 Jack} {100 Tom}

分组声明
import (
    "fmt"
    "os"
)

const (
    i = 100  //首行必须有常量表达式
    pi = 3.1415
)

var (  //全局变量可用，函数体内不支持
    i int
    pi float32
)




Golang笔记-01-简介
Sun, 02 Mar 2014 01:00:00 +0800
Go语言最主要的特性
自动垃圾回收
更丰富的内置类型
函数多返回值
错误处理
匿名函数和闭包
类型和接口
并发编程
反射
语言交互性

高性能/高效开发

安装
安装说明 地址
包下载 地址
确认是否安装成功
go version //查看版本

环境变量设置
整体目录结构
通过package组织，只有package名称为main的可以包含main函数
一个程序有且仅有一个main包
通过import 关键字导入其他非main包
bin/
    |- mathapp
pkg/
    |- 平台名
        |- xxx.a
src/
    |- mathapp
        |- main.go

Helloworld
package main //声明文件的package

import {
    "fmt" //import 包，不能包含没有用到的包，否则而编译错误
}
func main() { //入口函数, 无参数无返回值
    fmt.Println("hello world")
}

//运行
$go run hello.go

$go build hello.go
$./hello

go命令
用命令行查看
go help

go build 编译
go clean 移除当前源码包里面的编译生成文件
go fmt 格式化代码
go get 动态获取远程代码包
go install 生成结果文件，并将编译好的结果一到$GOPATH/pkg或者$GOPATH/bin
go test 运行测试用的可执行文件
go doc   godoc -http=:8080 查看文档

go fix 修复以前老版本代码到新版本
go version查看当前版本
go env 查看当前go的环境变量
go list 列出当前所有安装package
go run 编译并运行go语言程序

调试
使用gdb进行调试, go语言内部已经内置了
list
break
delete
backtrace
info
print
whatis
next
continue
set variable

编辑器设置
vim
其他补充
注释
//单行
/* ----- */ 多行

import 多个包
import (
    "fmt"
    "os"
)

调用包里地函数
.




Golang笔记-00-说明及资源
Sun, 23 Feb 2014 08:00:00 +0800

这份笔记是在学习golang过程中，汇集几本书以及网络视频、博客等资料汇总而成的，记录，方便查询
已经基本完成，逐步发上来
涉及内容
说明-资源 done
基础知识 done
类型 - 常量 - 变量 - 运算符 done
控制流 done
数据结构：数组，切片，map done
函数 done
结构struct
接口
字符串
文件
异常处理
数学计算
并发
反射
正则
数据库
时间日期
配置文件
日志logging
json/xml文件处理
测试
项目及项目结构

资源
书籍：
Go web编程|
Go 入门指南(The Way to Go)
Go 实战开发
视频:
Go编程基础|
Go Web基础|
Go名库讲解
网站：
论坛Golang中国|
博客Golang中国|
Go by Example
工具网站:
API速查 gowalker|
在线编译 gobuild
web框架:
beego|
web.go-类web.py|
Martini-类flask|
revel|
web
To be continue…..



读书笔记——追随你的心，用思想改变世界
Sun, 19 Jan 2014 08:00:00 +0800
乔布斯的十大演讲

很喜欢封面的设计，这本书的纸质也很赞，摸起来蛮有质感的，书买了应该有两年了，一直带着，但是没怎么看
今天又重新翻出来，书的边缘，已经有了岁月的痕迹，微微泛黄
封面是乔帮主，还有那句经典的"Follow your heart"
曾几何时，对帮主不是很了解，即使是帮主走的那年，12年十月，看了乔布斯传，对apple有了基本的认识
12年后，逐渐的，变成了果粉，没有刻意去追求什么，只是，apple的产品，逐一进入的我的生活
我曾经说过，买macbook是2013年最正确的决定之一，然后，运气爆表年会中了一个ipad air，变成了今年最幸运的事情之一。用了一天，下了多看,kindle,知乎，网易公开课，还有google浏览器，微博，pocket,evernote。以后不用抱着电脑累了，相信会为我的生活带来些什么

整本书，看看第一章第二章即可
第一章，语录，可以反复读，即使读不懂，随着时间，阅历丰富，有些东西会逐渐懂得。
第二章，斯坦福的演讲，看看不错, 入口
后面的，大部分是发布会，以及采访，可以直接看视频，看文字没啥特别的感觉，感觉编辑纯粹是凑字数
另外，还有一个遗失的访谈，蛮长的，一个多小时，但是不得不说，值得一看，入口

以下，是一些感受

我活着，就是为了改变世界

我只能说，帮主做到了。
很多时候，我都在思考，为什么活着，这个是个哲学问题，又不是，很难想明白的
每个工程师，都有改变世界的梦想
这么多年，有些端倪了，活着，对我而言，更像是：“创造价值”，让我，以及我所能影响到的人，生活更加美好些

领袖和跟风者的区别就在于创新

有所感受，不敢妄加评论，起码我所接触到的中国互联网环境还太狭窄

人要么是天才，要么是笨蛋

有些偏激，但是蛮有道理的

热忱是胜利的秘诀

对所做的事情，需要有热情

佛教中有一句话：初学者心态。拥有初学者心态是件了不起的事情

每隔一段时间，都需要倒掉，空杯心态，去接触新的东西，去重新认识已有的东西

求知若渴，虚怀若谷

前者是现在必须努力达到的目标，后者，是一生需要学习和感悟的

每个人的时间有限，所以你不要为别人活着。不要让自己的内心被别人的意见左右，不要活在他人的观念里，更不要被平庸的教条限制。最重要的是，坚定地寻找和倾听自己心灵发出的声音，那才是你的真实想法。要相信你的直觉和心灵。除此之外，其他的一切都是次要的。

我觉得，每个人都有必要自己读一读这段话，从小到大，我们的思想受到了太多束缚和限制，所以导致很多人，终其一生，都为了别人而活，活在别人的观念里

互联网创业不在于有多少人开始创办公司，而在于有多少人能坚持到底

坚持很重要

没有经验，你就永远不可能知道经验的价值，或者永远不可能知道如何正确地保有经验所创造的财富

经验很重要，见过多年只有一年经验的人，也见过一年有多年经验的人。刚毕业那会，对所谓的“经验”很不屑，两年多过来，有了蛮多认识的。经验，很重要，而且通过书本什么的很那学来的，实践出真知。经验，应该可以作为“聪明”和“智慧”的分界线吧。and，经验是需要积累的，不断持续的积累，有意识地积累。帮主也提到，过去的一切，点滴，即使再小，在未来的某个时刻，也会起到作用，所有的事情和经历，都是关联的。all connected!

成为海盗吧，成为海盗比加入海军更有意思

海军的优势，或许是“纪律”，但是劣势，或许也是“纪律”，向往自由的人，成为“海盗”更为合适。我的征途是星辰大海

你若想将未来的点联系在一起，那你就只能先将过去的点联系起来。你得相信你的未来和你的过去是联系着的。你必须要相信直觉、命运、生活等这些东西。这个方法从来没有让我失望过，它反而让我的生活发生了奇妙的变化

很多事情，并非一蹴而就，或许在外人看来是，但是背后，都以一段很长的过去。我们的现在，就是未来的过去，未来想要变成什么得到什么，和现在是相关的。
另外，我开始相信直觉。

你的工作将会占据你的大部分时间，做你自己认为最了不起的工作时唯一让你真正满意的方法。而做好你最满意的工作的唯一方法就是热爱你所做的事情。因此，继续找你满意的工作，直到找到它，不要气馁

非常赞同，在懵懂中度过了大学四年，花了接近两年，看是有点懂了。做自己喜欢的事情。决定并不难，难的是，如何真正知道自己喜欢什么。

记住一点，就是每个人都会死去。这是我遇到的最重要的决策工具，很多重大的人生选择都是在它的帮助下完成的。外部所有的骄傲、期望、对失败或尴尬的恐惧，在死亡面前，都会消失殆尽，只留下真正重要的东西

有点感觉，但是还做不到，可能，还是自己太年轻了

热爱你所做的事是做伟大工作的最佳方法。如果你还没有找到你想要的工作，继续找。不要停下来。只要你全力以赴，你知道你一定会找到它。

坚持

人生苦短，你总有一天会离开人世。一个人没有机会去做那么多事，所以每个人都应该极其优秀才行。因为这就是我们的生活。

做选择的时候，多想想这个问题

2014-01-19
wklken



如何书写shell脚本
Sun, 12 Jan 2014 08:00:00 +0800
关于Linux基础命令，可以查看另一篇博文 Linux Shell脚本攻略笔记
以下内容，主要是，了解书写shell脚本所需要的大部分知识,主要内容来自于书籍和网络
目的是，能快速书写出需要的shell脚本
开始
version 0.1 2014-01-12 基本内容, 完成度30%

资源
google shell style guide
Linux Shell脚本攻略笔记
Linux Shell编程实战技巧
Bash编程易犯的错误 1234
关于shell脚本编程的10个最佳实践
Bash Pitfalls

第一部分 一些概念
标准IO
文件描述符
0 标准输入 默认键盘
1 标准输出 默认终端
2 标准错误 默认终端

重定向
> 输出重定向
>> 追加到输出重定向
< 输入重定向
<< 追加到输入重定向

ls -l > /tmp/a

cmd >/dev/null 2>&1 #输出到垃圾桶

管道
前后连接两个命令

ls -l | grep test

引号
双引号：可以除了字符$`\外地任何字符或字符串
单引号：忽略任何引用值，将引号里的所有字符作为一个字符串 $var 不能被解析
反引号：设置系统命令输出到变量

shell脚本识别三种基本命令：内建命令，shell函数和外部命令
基本的命令查找:shell会沿着查找路径$PATH来寻找命令
echo $PATH

可以在.profile文件中修改
export PATH=$PATH:$HOME/bin

and/or
expression1 && expression2 && expression3
只有前面一条命令执行成功，才执行下一条
expression1执行成功，才执行expression2
串联的

expression1 || expression2 || expression3
执行命令，直到有一条成功为止


第二部分 shell脚本
首行声明使用bash(声明脚本执行解释器)
#!/bin/bash

# do something

exit 0/n

运行
sh xx.sh
bash xx.sh #大部分情况下两个一样，某些命令只有bash有，只能用这个

or

chmod u+x xx.sh
./xx.sh

调试
#查看运行时，每个命令回显，执行之后回显
sh -x xx.sh

#执行之前回显
sh -v xx.sh

#检查语法错误，不执行
sh -n xx.sh

#如果使用了未定义的变量，给出错误信息
sh -u xx.sh

#调试部分脚本
echo "Hello $USER,"
set -x
echo "Today is $(date %Y-%m-%d)"
set +x

判断执行结果
N=$?  #0 <= N <= 255

0 无错误，正常执行结束
非0 异常
    1-125命令不成功退出
    126命令成功，但文件无法执行
    127命令找不到
    >128命令因收到信号而死亡

获取目录名和文件名
# To find base directory
APP_ROOT=`dirname "$0"`

# To find the file name
filename=`basename "$filepath"`

# To find the file name without extension
filename=`basename "$filepath" .html`

e.g.
BASEDIR=$(dirname $0)
cd $BASEDIR
CURRENT_DIR=`pwd`

日期
TODAY=`date +%Y%m%d`
DAY_1_AGO=`date -d "$TODAY 1 days ago" +%Y%m%d`

常用接受日期/使用默认日期处理

if [ -n "$1" ]
then
    TODAY="$1"
else
    TODAY=`date +%Y%m%d`
fi

crontab调度
查看
crontab -l
编辑
crontab -e

格式
* * * * * command_path

字段      含义     范围
1        分钟         0-59
2        小时         0-23
3        日期         1-31
4        月份         1-12
5        星期几，0=周日   0-6
6        具体命令,可以是调用脚本

*任意时刻
n1,n2  分割，n1和n2
*/n  每隔n单位
n1-n2   时段，一个时段内

0 */2 * * * sh run.sh     每隔两小时
20 7 * * * sh run.sh 每天7:20
0 1,5 * * * sh run.sh 每天1点和5点
* * * * * sh run.sh 每分钟执行一次


第三部分 变量
1.变量赋值
varname="value"
varname=`expression`

注意，等号两边必须不能包含空格

2.分类
四种变量：环境变量、本地变量、位置变量、特定变量参数

环境变量可作用于所有子进程
本地变量在用户现在的shell 生命期的脚本中使用，仅存在于当前进程
位置变量：作为程序参数
特定变量：特殊作用

3.环境变量
设置
MYVAR="test"
expirt MYVAR
or
export MYVAR="test"

只读
MYVAR="test"
readonly MYVAR
or
readonly MYVAR="test"

显示
export -p
env #查看所有环境变量
$MYVAR #获取

消除
unset MYVAR

4.本地变量
设置
LOCAL_VAR="test"
or
LOCAL_VAR="test"
readonly LOCAL_VAR #设置只读

还可以使用declare命令定义

5.位置变量
$0 脚本名称
$# 传递到脚本参数个数
$$ shell脚本运行当前进程ID
$? 退出状态
$N N>=1，第n个参数

6.字符串处理
长度
${#VARIABLE_NAME} 可以给出字符串的长度。

if [ ${#authy_api_key} != 32 ]
then
    return $FAIL
fi

拼接字符串
echo "$x$y"

字符串切片
${变量名:起始:长度}得到子字符串

$ test='I love china'
$ echo ${test:5}
e china
$ echo ${test:5:10}
e china

str="hello world"
echo ${str:6}  # ${var:offset:length}

字符串替换
${变量/查找/替换值} 一个“/”表示替换第一个，”//”表示替换所有,当查找中出现了：”/”请加转义符”\/”表示
echo ${str/foo/bar} #首个
echo ${str//foo/bar} #所有

正则匹配
if [[ $str =~ [0-9]+\.[0-9]+ ]]

7.数值处理
自增
a=1
a=`expr a + 1`

or

a=1
let a++
let a+=2

let
no1=4
no2=5
let result=no1+no2

expr
result=`expr 3 + 4`
result=$(expr $no1 + 5)

其他
result=$[ no1 + no2 ]
result=$[ $no + 5 ]

result=$(( no1 + 5 ))

浮点数
echo "4 * 0.56" | bc
设定精度
echo "scale=2;3/8" | bc
进制转换
echo "obase=2;100" | bc
平方
echo "sqrt(100)" | bc

数组和map

第四部分 控制流
1.条件测试
语法
test condition
[ condition ] #注意两边加空格

$? #获取判断结果，0表示condition=true

条件测试中的逻辑
-a 与
-o 或
!  非
&&
||

if [ -n "$str" -a -f "$file" ]
if [ -n "$str" ] && [ -f "$file" ]

字符串测试
=   两字符串相等
!=  两字符串不等
-z  空串 [zero]
-n  非空串 [nozero]

[ -z "$EDITOR" ]
[ "$EDITOR" = "vi" ]

数值测试
-eq  数值相等（equal）
-ne  不等（not equal）
-gt  A>B（greater than）
-lt  A=B（greater、equal）

N=130
[ "$N" -eq 130 ]

文件测试
-d目录
-f 普通文件（Regular file）

-e 文件存在
-z 文件长度=0
-s 文件长度大于0，非空

-b 块专用文件
-c 字符专用文件
-L 符号链接

-r Readable（文件、目录可读）
-w Writable（文件、目录可写）
-x Executable（文件可执行、目录可浏览）

-g 如果文件的set-group-id位被设置则结果为真
-u 文件有suid位设置

2.分支if-else/case
if-else语法
if condition1
then
	//do thing a
elif condition2
then
	//do thing b
else
	//do thing c
fi

or

if condition; then
# do something
fi

case语法
case $VAR in
	1)
		echo "abc"
		;;
	2|3|4)
		echo "def"
		;;
	*)
		echo "last"
		;;
esac

3.循环for/while/until
for语法
for VARIABLE in 1 2 3 4 5 .. N
do
    //commands
done

for OUTPUT in $(Linux-Or-Unix-Command-Here)
do
    //commands on $OUTPUT
done

#bash
for (( EXP1; EXP2; EXP3 ))
do
    //commands
done

例子

for i in 1 2 3 4 5; do
	echo $i
done

for i in `seq 1 5`; do
	echo $i
done

#!/bin/bash
echo "Bash version"
for i in $(seq 1 2 20)
do
   echo "Welcome $i times"
done

for i in {1..5}; do
	echo $i
done

#!/bin/bash
echo "Bash version"
for i in {0..10..2}
do
    echo "Welcome $i times"
done

for ((i=1; i<=10; i++)); do
	echo $i
done

#无限循环
#!/bin/bash
for (( ; ; ))
do
   echo "infinite loops [ hit CTRL+C to stop]"
done

while
while condition
do
	//do something
done

COUNTER=0
while [ $COUNTER -lt 5 ]
do
	COUNTER=`expr $COUNTER + 1`
	echo $COUNTER
done


无限循环
while [ 1 ]
do
	//
done

until
#执行命令，直到条件为真，至少执行一次，可以用来做监控，condition每次都回去检查
until condition
do
	//do something
done

break/continue
break
允许跳出循环，通常在进行一些列处理后退出循环或case语句
若多重循环，可指定跳出的循环个数，如跳出两重循环  break 2

continue
不会跳出循环，只是跳过此循环步
命令是程序在本循体内忽略下面的语句,从循环头开始执行


第五部分 函数
1.函数定义
function func_name() {

}

func_name() {
	//do some thing
}

注意
函数名，在脚本中必须唯一
函数必须，先定义，后使用

return
function equal() {
    return 1
}

equal
echo $? #got 1

2.参数传递
#位置参数
function copyfile() {
	cp $1 $2
	return $?
}

调用

copyfile /tmp/a /tmp/b
or获取返回值
result=`copyfile /tmp/a /tmp/b`

位置参数
$1 - $9，当参数超过10个时，需要使用${10}
$# 参数个数
$* 将所有参数视为一个字符串="$1 $2 ..."
$@ 将所有参数视为个体="$1" "$2" "$3"

3.返回值和退出状态
#返回值
function func_a() {
	return 1
}

result=`func_a`
if [ result != 0 ]
then
	echo "Error"
fi

#退出状态
function func_b() {
	//do something
}

func_b
if [ $? -eq 0 ]
then
	echo "Success"
else
    echo "Error"
fi

#更简洁
if func_b; then
    echo "Success"
else
    echo "Error"
fi

func_b && echo "Success" || echo "Error"

第四部分 高级
bash中参数展开-展开运算符
${varname:-word} 如果变量未定义，返回默认值.  ${noexist:-0}返回0
${varname:=word} 如果变量未定义，设置变量为默认值  ${noexists:=0}; echo ${noexists}; 得到0

${varname:?message} 若未定义，显示varname:message并退出当前的命令或脚本
${varname:+word} 若存在且非null，返回word，否则返回null

模式匹配
${variable##pattern}
${variable%pattern}

第五部分 其他
读文件
while read -r line; do
    echo $line
done < file

保留首尾字符
while IFS= reaad -r line; do
    echo $line
done

一些内置命令
:
空命令，类似python的pass

.
相当于source

\
用于跨行命令

echo
输出，类似println

exec

exit n
脚本以n作为退出码退出

export
设置或显示环境变量

expr
简单计算
x=`expr $x + 1`
x=$(expr $x + 1)

let
d=111
let d=$d+1; echo $d
112

printf
格式化输出

return
函数返回

set

shift
所有参数变量左移一个位置

unset
从环境变量中删除变量或函数

BP:
使用$() 代替反引号``
$(()) 代替expr运算符

bash
GNU Bash 主页
http://www.gnu.org/software/bash/
GNU Bash 手册
http://www.gnu.org/software/bash/manual/

更多的特性
$((3 + 4))          而不需要 expr 3 + 4, 算术展开
/usr/{bin,local/bin}  而不需要 /usr/bin /usr/local/bin
${str/src/dst}       而不需要 echo $str | sed ”s/$src/$dst/”

更方便的语法
for (( expr1; expr2; expr3 )); do
        commands
done
for (( i = 0; i < 100; i++ )); do … done
echo a{b,c,d}e  ==> abe ace ade

表达式求值
$[]    []$中间可以加表达式  eg: echo $[$a+$b]
$(())   (())中间可以加表达式。Eg： total=$(($a*$b))

正则
bash的正则表达式
str='hello, world'
if [[ $str =~ '\s+world$' ]]; then
    echo match!
fi
if echo "$str" | grep -E '[ ]+world$'; then
    echo match!
fi

获取软连接指向的真实文件名
#注:有些系统没有这个命令
readlink /usr/bin/python

增加debug
function debug() {
    if [[ $DEBUG ]]
    then
        echo ">>> $*"
    fi
}

# For any debug message
debug "Trying to find config file"

还有来自于一些很酷的Geeks的单行debug函数：

function debug() { ((DEBUG)) && echo ">>> $*"; }
function debug() { [ "$DEBUG" ] && echo ">>> $*"; }

将执行日志全部写到某个文件
exec >>"$LOGPATH"/xx.log.$TODAY 2>&1
#begin of code

Posts on WKLKEN THINKING

AI 重构的那些 bad case

TLDR

过度防御

无意义到包装或转发

不会删掉没有调用的dead code

只要能解决问题，什么方法都行

丢失掉所有有用的注释

超级复杂的实现 vs 看似取巧的变通

相对保守不改变函数的协议带来的复杂度

半吊子的封装

小心 noqa

ai 编程实践

1. 深度使用一个 agent

2. 创建一个自己的 .agents 仓库

3. 创建自己的 AGENTS.md

4. 选一个基础工作流

5. 挑选一批适合自己的skill

6. 创建自己的skill

7. 安装 cli + skill

8. 持续迭代它

9. 啰嗦两句：保证交付质量

apisix 中的 lrucache

机制

接口

其他同类库

apisix 中的服务发现机制

机制

0. 入口

1. discovery.init_worker

2. apisix.discovery.dns

3. 调用点在哪里？

数据面服务发现的问题

基于控制面的服务发现

相关文档

apisix 中的负载均衡

机制

0. 入口

1. 初始化

2. 执行入口

3. api_ctx.picked_server

4. load_balancer.pick_server

apisix etcd机制

机制

0. 入口

1. http_init_worker

2. 具体某个router.lua

3. user_routes

问题

etcd compacted

实时更新的问题

特性追踪

etcd http

etcd grpc

增量更新

依赖库

readdir:

watchdir

apisix 中的 DNS 解析

入口

主入口： handle_upstream

1. parse_domain_for_nodes

2. parse_domain(host)

3. dns_parse(domain, selector)

4. resolve(domain)

依赖库

如何减少打断提升效率

让每个人深切感受到打断

记录，记录，记录

统计和分类

处理

1. 文档体系

2. 操作的合理性、必要性

3. 自动化及分派

4. 其他系统带来的成本

5. FAQ

6. 热点问题置顶

控糖革命

第一部分 为什么要控糖

第二部分 出现葡萄糖峰值有哪些危害

相对保守不改变函数的`协议`带来的复杂度

让每个人深切感受到`打断`

第一部分为什么要控糖

第二部分出现葡萄糖峰值有哪些危害

窍门 2：在每餐前增加一到绿色开胃菜

5. 配置 `preStop`