Algorithm(leetcode 算法题)

Shortest Subarray with Sum at Least K

乍看很简单,躺在床上很快有了思路,第二天美滋滋的写出来发现思路上存在的错漏不足实在是太多了……

中间多次修正思路,修正后编码出来又发现不对,思路还是有问题,继续修正,最后修着修着……终于走向了死胡同

一贯以来我在做题的时候,一旦隐约感觉到不知不觉开始过度细化针对处理某些边界问题,那多半是半只脚踏入死胡同了……最后果然不出所料😢哎……

勉强有点安慰的是基本的思路实现出来的结果 case 通过率在 88/93 这样,还是很接近的(安慰下自己这要是考试还算拿个高分么23333😂)……

只好评论区参考思路走起了…… 评论区大佬 10 行代码搞定……猝不及防留下了弱者的泪水

def shortestSubarray(self, A, K):
        N = len(A)
        B = [0] * (N + 1)
        for i in range(N): B[i + 1] = B[i] + A[i]
        d = collections.deque()
        res = N + 1
        for i in xrange(N + 1):
            while d and B[i] - B[d[0]] >= K: res = min(res, i - d.popleft())
            while d and B[i] <= B[d[-1]]: d.pop()
            d.append(i)
        return res if res <= N else -1

Review(阅读并点评至少一篇技术文章)

An introduction to distributed systems

这篇是耗子叔分布式专栏里推荐的一篇分布式系统入门,大纲向,基本上分布式系统涉及的所有要点都有提及,并给出了简单的概念介绍

长,非常长,特别长,十分长……打开 mac 以 pdf 的形式创建,居然整整有 49 页……一周下来拼死拼活也就看了 20 几页,还好多概念没看懂……当然可能也跟我边看边手写做笔记速度较慢有关:

GoodNotes 笔记

内容就不详提了,本身也是个大纲,不需要进一步概括了,耗子叔推荐必属精品,绝对值得一看

看之前没想到这么长,下周绝对要找篇短一点的来看


Technique(技术技巧)

git 有用命令

最近新入职适应新的技术栈工具渣栈,感觉都没什么好分享的技术技巧 Orz,刚好这两天见到两个有用的 git 命令推荐一下(熟练 git 的老司机们不要打我

  1. 图形化显示 git 修改历史
git log --graph --decorate --oneline

显示出来的效果大概是这样的:

decorate

感觉除了没有交互性,这个基本的显示不比那些 git 的图形化客户端的显示要差

  1. 查看文件的修改历史
git blame /path/to/file

可以具体显示到每一行分别是哪个用户修改的创建的,非常清晰:

history


Share(分享有观点和思考的技术文章)

最近一直在愁找不到好的"有观点、思考的技术文章",将这个宗旨拆开一下要点应该是这样:

  • 观点/思考
  • 技术相关
  • (最好应该是)文章

Medium 上我订阅的文章中有观点和思考的不少,但基于技术相关的不是很多,几期 ARTS 以来私以为最符合宗旨的就是之前在 changelog 找到的那篇超长的访谈,其他几篇说是有观点有思考都很勉强……

想很久最后思路才绕回 changelog这个站点,里面有不少专栏都有与技术界大佬的访谈,访谈里自然会有大佬们的观点和思考

初步决定以后暂时就在 changelog 搜罗 Share 模块的文章啦

You Are Not Google/Amazon/LinkedIn

初步看标题可以判断出文章内容必然与技术的恰当使用有关——适合巨头们的技术栈很大可能不适合你,这个问题在之前 ARTS 的 SHARE 中也提到过,不过本文更多是指出了热点技术背后不单纯的本质:投资、宣传、营销等等,投资助长宣传与营销,一项早就存在的普通技术也会被包装后以"崭新"的面目出现,摇身一变成为所谓的"热点技术"

然而由于对技术的发展保持敏感也是技术人员的职责,我们还是有必要的关注新的技术消息。然而有时也许你只是转发了一条推特、一条微博——你以为你只是表示你对技术的关注,实际上却不知不觉助长了无意义的狂热,给人以该技术发展的热火朝天的错觉(毕竟一眼看过去那么多转发)。关于这一点受访的 OZAN ONAY 认为如果在转发的时候适当的带上该技术相关的历史背景等信息,就不那么容易造成"我支持并为这一技术站台"的错觉,一句原话如下:

Give something some history, give something some context

OZAN ONAY 还提到了一些在开发过程中显得"反直觉"但具有深刻意义的现象,比如有时开发者时常会渴望快速的迭代:快速 hack,快速得到反馈,却忘了有时应该冷静下来认真思考该做什么,在做什么

常识告诉我们沉浸在做一件事中的愉快的生理体验值得被延续,因为保持专注和热情很重要,但我们却容易忽视了实际上在那之外有更多的思考要做。实际上,思考才是真正重要的部分,动手是思考结果的呈现,在动手前想不清楚仅仅是无用的空耗时间

OZAN ONAY 自创了一个非常不酷(本人语)的简写 UNPHAT 推荐给大家在重构代码前先想想清楚,这一简写来源于以下几点的大些字母部分

  • Understand the problem
  • eNumerate multiple candidate solutions
  • read the Paper
  • determine the Historical context
  • weigh Advantages against disadvantages
  • Think

本文我觉得最好的部分是对一种技术的思考引导:

  • 想想这项技术是为什么被创造出来的
  • 它解决了什么问题
  • 需要具备什么硬条件
  • 我们要为这一技术支付什么
  • 这一技术会存在什么问题,我们又要为这些问题支付多少成本?

想清楚这些问题才能真的想清楚某一技术是否真的适合你的问题场景,单纯的谷歌搜索像"Mapduce 是否适合xxx使用"是不会解决你的问题的

访谈还是一贯的长,不过这篇感觉干货不是很多,感兴趣的可以读一读


Comment(来自别人的评价与相关讨论)