Skip to content

Latest commit

 

History

History
140 lines (99 loc) · 5.55 KB

2018-10-12.md

File metadata and controls

140 lines (99 loc) · 5.55 KB

一. Alogrithm

本周做了 206.Reverse Linked List 反转单链表的题目。

实现如下:

class ListNode {
    int val;
    ListNode next;

    ListNode(int x) {
        val = x;
    }
}

class Solution {
    public ListNode reverseList(ListNode head) {
    	 if (head == null || head.next == null) {
            return head;
        }

        ListNode result = head;
        // 移动 header
        head = head.next;
        result.next = null;

        while (head != null) {
            // 预先记录下一个 node
            ListNode next = head.next;
            // 将当前 header 的节点指向其 pre 节点
            head.next = result;
            // 将当前 header 节点设置为 pre 节点供下个循环使用
            result = head;
            // 移动 header 到下一个节点
            head = next;
        }
        return result;
    
    }
}

基本思路是拿到每个 Node，然后将 Node 的 next 设置为其前一个 Node 从而达到反转。时间复杂度为 O(n)，空间 复杂度为 O(n)。题目本身难度不大，想清楚节点的变换过程就行了。

二. Review

本周读了 Elastic 官网上的一篇博客文章: How We Handle Pull Requests at Elastic

文章简单介绍了 Elastic 公司在开发 ELK 技术栈的过程中是如何处理开发者提交的 Pull Request 的。 文章主要内容基本概括为以下两点:

  • 如何向 Elastic 提 Pull Request
  • Elastic 对 Pull Request 的处理过程

1. 如何提 PR

对于某个开源项目，需要先从 Elastic 的 官方仓库 中 fork 下对应的 project，修改代码后创建 PR 即可。下面是原文中的一张图片实例:

Elastic 在创建 PR 中预置了一些模板提示，根据这些提示可以避免一些不必要的坑。简单来说主要有下面三点需要格外注意:

  • 防止重复提交。当你要提交一个 PR 时，确认要改进的功能或者修复的 bug 是否已经有其他的开发者提交过了
  • 一定要包含测试。新的 PR 必须包含测试以明确说明其修改的具体行为。理想情况下的测试时当你提交的代码不生效时，测试不通过；代码生效后则测试通过
  • 只针对 master 分支进行提交。所有的修改提交都是基于 master 进行的

2. Elastic 处理 PR 流程

【1】分类、标签、分配

当 PR 满足了模板提示中的要求后，Elastic 首先会对 PR 进行分类，然后打上不同的标签，比如 >bug, >featur5 等。打完标签后 PR 就会被分配给合适的子团队进行处理

【2】回访确认

当 Elastic 的开发者接收到某个 PR 后，他会试图联系 PR 的提交者去确认相关的信息。这个可能是全天随时并且需要一定的时间的。因此需要提交者有足够的耐心 = =

【3】 文档提交

相对于代码，文档的提交比较简单，不需要有测试和 fork 项目。只需要在对应的地方 edit 后提交即可，Elastic 会对其打上 >doc 的标签然后尽快处理。

【4】 讨论调整

在 PR 被真正合入 master 之前，还会进行一系列的调整，此时 PR 可以视作一个讨论的地方。开发者在这里进行讨论修正，并且 Elastic 会进行完整的测试，如果不通过(我本地明明可以的情况 = = )，Elastic 的工程师还会协助开发者去完善代码最终通过测试。

另外还会进行代码风格的校验，虽说代码没有完美的时候，但还是要尽可能的提高质量。

以上就是 Elastic 处理 PR 的主要步骤了，作者最后提到 PR 的处理时长不等，如果处理时间过长你可以去咨询 Elastic 团队。最后如果 PR 通过的话可能会被打上一个 >Looks Good To Me 的标签，然后后续会准备合入 master 然后发布。

三. Tip

最近服务迁移过程中，需要将某个配置文件发送到 20 多台服务器上，因为没有用到容器，所以还是使用传统的 scp 上传，搜索同时上传的方法，大部分文章还是写 bash 脚本来完成的，这里分享下用 ansible 完成的示例吧。

#!/usr/bin/env ansible-playbook
---
- name: sync nginx config
  # 指明 ansible 服务器组
  hosts: my-server
  gather_facts: False
  # 列出要执行的任务
  tasks:
    # 使用 rsync 执行命令文件同步命令
    - name: rsync config
      synchronize:
        src: /home/myname/file/cloud_nginx_config
        dest: /etc/nginx/sites-available/
        rsync_path: 'sudo rsync'
   # 重启 nginx
   - name: reload nginx service
      shell: "sudo nginx -s reload"

下面是 ansible 的 hosts 配置。

[my-server]
server01
server02
server03
server04
server05
server06
server06

这里的各个 server 名是在 .ssh/config 下配置好的服务器名。

配置完成上面文件后就可以通过 ansible 命令来执行脚本，然后完成同时上传文件到多台服务器上的任务了。

ansible-playbook cloud_config.yml

如果没有使用容器的话通过 ansible 来执行运维相关的任务还是很不错的。

四. Share

分享一篇本周整理的关于 ES Mapping 使用的博客吧 ElasticSearch Mapping 与数据建模简记