Web3.0的势头因为元宇宙似乎更猛了，掏出收藏已久的web3.0科普资料，记录一下笔记查漏补缺

NFT

简介

NFT（Non Fungible Token）是唯一资产所有权的记录。

由于 NFT 存在于区块链上（参见什么是区块链），它们是：

1. Decentralized：存储在计算机网络上。
2. Immutable：一旦提交就无法更改。
3. Open：任何人都可以看到交易历史。

NFT的类型

以CryptoPunks为例，官网上说：

寻找有趣的NFT项目

感觉拥有一个具有唯一标识的数字头像真的是一件很geek很酷的事情，CryptoPunks因为是艺术品所以价值被哄抬得很高，到2022/5/22日为止，官网显示最低价格的cryptopunk为50eth，过于昂贵了，不过Odyssey也有给出寻找其他有趣NFT项目的建议：

1. 寻找热门项目。可以在OpenSea，CryptoSlam和nonfungible上找到热门项目。 还可以使用付费的NFT工具，如icy tools和moby.gg来查找一分钟内的实时数据。
2. 关注NFT收藏家。顶级NFT收藏家交易大量NFT，并且通常是第一个找到热门项目的人。像 Moby.gg 这样的工具可以用来查看 recent transactions from collectors。还可以在Twitter上关注有趣的收藏家（从关注NFT主题开始）。
3. 加入NFT社区。可以加入NFT爱好者的社区，以获取有关项目的最新情报。Odyssey社区是一个很好的（和免费的）起点。最理想的NFT社区通常有一个paywall（例如，Metaverse，FWB和CPG俱乐部）。

铸造、Buy/Sell

指南

参考

Web3.0的势头因为元宇宙似乎更猛了，掏出收藏已久的web3.0科普资料，记录一下笔记查漏补缺

Web3.0

POI: 区块链的"OSI"体系

个人对web3.0比较感兴趣是因为在区块链的发展过程中，逐渐形成了可以类比计算机网络OSI的体系。
目前一共有三个Layer。

• Layer0：大概包括物理层、数据链路层、网络层和传输层；
• Laye1包括数据层、共识层和激励层；
• Layer2包括合约层和应用层。比特币网络、以太坊主网等主流公链都属于Layer 1的范畴。

目前在众多的公链项目中，以太坊是运行智能合约、DAPP最多的公链，也是锁仓资产价值和日均交易量最大的公链，所以在有关以太坊网络Layer1和Layer2不同扩容方案的讨论也是最多的。科普中提到的Layer1和Layer2也主要以以太坊为主。

Layer1和Layer2的一个类比: 他们的关系像中央银行与商业银行

• Layer1承担着中央银行的角色
• layer2是各大商业银行。

在现行主流的金融系统中，所有的资产都必须在中央银行结算，而具体的流通过程可以同时发生在中央银行和商业银行。

因为如果所有人都去央行结算的话，势必会发生业务拥堵的情况，更好的解决办法当然是由商业银行来先处理大量交易业务，然后由各个商业银行和中央银行结算一次整体业务，这样才能使得整个金融系统更加高效有序的运转起来。

所以从中我们能够得到的启示就是，对于在以太坊网络中存在的交易拥堵、手续费居高不下的问题，一个可行的解决方案就出炉了——将以太坊的资产存入Layer2，之后的资产流动交易环节都在Layer2上进行，只把最终结算过程放到Layer1上就可以了。

web1, web2, web3

看一下Odyssey对他们的定义：

区块链&BTC

这一块之前书和资料看得比较多了

科普参考

以太坊

以太坊的目标是成为世界上的去中心化计算机（称为 EVM 或以太坊虚拟机）。相当于区块链的基础建设系统，使用智能合约可以在虚拟机上搭建各种各样的dapp，目前比较多的dapp类型的有NFT(如opensea)、交换代币(如Uniswap)、借贷代币(如Compound)、通过玩游戏赚取收入 （如Axie Infinity）等等

一些定义：

注：可以用ens-domain将难记住的公钥转变成yourname.eth的形式，参考如何获得一个 ens 域名？

区块链交易费用

在区块链上进行交易，需要支付交易费用 (通常称为 gas)。

瓦斯费（gas）是支付给区块链上的节点以处理交易的加密货币数量。

对于以太坊，gas以 针织 （1 gwei = 0.000000001 ether）为单位。

支付多少gas取决于：

1. 网络拥塞：如果很多人都试图进行交易，那么 Gas 会更高。
2. 交易类型：如果您的交易很复杂（例如，铸造NFT与将加密货币发送到另一个钱包），则gas会更高。

以太坊不是唯一有gas费的区块链，它只是最贵的。

L1链、L2链、侧链

以太坊 L2 链以及其他 L1 链提供比以太坊主网更快、更便宜的交易。提供比以太坊 L1 更快、更便宜的交易。

1. L1链 是主要的以太坊区块链。其他非ETH L1链包括 Solana， Avax和 Terra。
2. L2链 在捆绑并提交到以太坊L1之前处理链下交易。例子包括 Arbitrum， Optimism和 Loopring。
3. 侧链 是带有自己的gas token的独立区块链。 Polygon 是最受欢迎的侧链。

DeFi

简介

DeFi（去中心化金融）是指基于智能合约而不是依赖银行或交易所等中间商的金融服务。

Defi与传统金融的对比

DeFi 与传统金融相比既有优势也有劣势：

• 优势包括更高的透明度、更多的访问和更高的潜在回报。
• 缺点包括与新兴的、不受监管的行业相关的更高风险。

DeFi的应用

使用DeFi可以做几乎所有在TradFi（传统金融）中可以做的事情。如汇款、质押(staking)、持有稳定币、使用CeFi平台、交换代币、借贷加密货币、提供流动性(Liquidity)、Yield Farm

Staking

锁定加密货币以帮助验证交易以证明权益区块链以换取奖励（通常是更多相同类型的加密货币）

交换代币

可以使用去中心化交易所（DEX）交换任意两个代币。
一个类比：

• A和B把10个苹果和橙子放在一个篮子里；
• A要取出一个橙子，需要把一个苹果放入篮子作为交换；
• 过了一会，篮子里只有5个橙子和15个苹果，因为橙子比较少，A同意取一个橙子就放两个苹果。

去中心化交易所（DEX）与篮子一样，用流动性池的自动化做市商（AMM ）。为了让用户在 像Uniswap这样的分散式交易所（DEX）上交换两个代币，其他用户必须将这些代币贡献给流动性池。几个术语：

DEX 需要一个大型流动资金池来减少价格波动。考虑这两个例子：

1. 一个ETH-DAI池各有10个代币。如果将1 ETH换成DAI，则池的供应量将下降10%，并且将ETH换成DAI将变得更加昂贵。
2. 一个ETH-DAI池各有100，000个代币。如果将1 ETH换成DAI，则池的供应量不会真正受到影响，价格将保持稳定。

这里的ETH就好像橙子，DAI就好像苹果，他们的数量越多，流动性越低，交换的所需的交易费用就越少。

借贷加密货币

类比：假设你正在度假，并且几个月内不会使用您的汽车。通常，你的车会坐在你的车库里收集灰尘。相反，您决定将其出租给朋友。你（贷款人）可以赚钱，你的朋友（借款人）可以用你的车把事情做好。

Yield Farm

Yield Farm不是指一个特定的过程，而是指通过抵押，贷款和借贷的某种组合来寻求回报的总体想法。这些策略给“农民”带来了额外的回报。获得高回报的机会伴随着风险。

一种常见的Yield Farm类型是当LP被激励为平台增加Liquidity时。

避免风险

作为金融小白，DeFi了解，浅浅体验就好，花大资本去尝试风险太大。

DAO

DAO(Decentralized Autonomous Organization)是由其成员拥有和管理的社区。

与公司相比，DAO 既有优点也有缺点：

• 优势包括让更多人做出贡献、参与决策并拥有优势。
• 缺点包括必须以分散的方式协调兼职劳动力。

以下是一些值得探索的学习DAO：

1. Odyssey在这个网站上写了学习路径。我们的使命是帮助100万人访问web3，并欢迎所有初学者。
2. Crypto， Culture， and Society是一个专注于探索文科和加密交叉点的DAO。
3. 前沿专注于社交代币社区的教育。
4. 开发人员DAO可帮助开发人员加入 web3。

参考

这篇文章将使用 Chrome开发者工具在“实验室”环境查看天刀直购系列活动页面的性能指标，结合入职以来做过的几个需求，总结一下学习到的页面性能优化的方式以及未来还可以采取的优化措施。

性能指标测试环境和工具

性能指标一般通过在实验室中或在实际情况中两种情况来测量:

1. 实验室中：使用工具在稳定、受控的环境中模拟页面加载
   实测工具(field tools)例子：

   • Chrome 用户体验报告
   • PageSpeed Insights 网页速度测量工具
   • 搜索控制台（核心 Web 指标报告）
   • web-vitals JavaScript 库

2. 在实际情况中：基于真实用户的实际页面加载与页面交互
   实验室工具(lab tools)例子:

   • Chrome 开发者工具
   • 灯塔
   • WebPageTest 网页性能测试工具
   • 在实测 Web 指标的最佳实践中，推荐使用web-vitals js库,为了不影响测量官方建议延迟加载分析代码

使用 Chrome开发者工具分析如何进行页面性能优化

用于分析和测试优化策略的页面：

天刀华为直购活动页面一、天刀华为直购活动页面二

这里分为两个阶段：加载阶段和交互阶段，这里主要关注网络进程和渲染进程。

加载阶段

通过 chrome 的 performance 中的 timing 可以观察到比较重要的几个时间节点:

• First Paint ：Google定义的web指标(web vitals)之一，首次绘制像素的时间（白屏时间）。
• First Contentful Paint ：Google定义的web指标(web vitals)之一，测量页面从开始加载到页面内容的任何部分在屏幕上完成渲染的时间，如文本、图像、非空 svg/canvas 等（首屏时间）。
• Largest Contentful Paint : Google定义的核心web指标(core web vitals)之一，测量页面从开始加载到最大文本块或图像元素在屏幕上完成渲染的时间，测量加载性能。从 Screenshots 中看到这个节点是可以看到比较完整的页面的时候，因此从用户体验来说这个时间点会比较重要。
• DomContentLoaded 事件： dom 树构建完毕，但是还没有进入渲染树的构建。体验上页面可以正常交互了，但是图片、字体等资源可能还没完全加载好。(在 main 上，DCL之后就没有 Parse HTML 了)
• Load 事件：页面上所有资源都被加载完毕。( js 、 css 、图片，以及 js 异步加载的 js 、 css 、图片)
  

如果不想使用web-vitals想自己做埋点，也可以使用performance Windows API来做简易的埋点。看一下performance.timing都有什么:

根据它们可以计算出FP/DCL/Load等关键事件的时间点

// 页面首次渲染时间(firstPaint)
let FP = domLoading - navigationStart
// DOM加载完成(DOMContentEventLoad)
let DCL = domContentLoadedEventEnd - navigationStart
// 图片、样式等外链资源加载完成 (Load)
let L = loadEventEnd - navigationStart

不过这里因为Google Web Vitals更多考虑了用户体验，所以也使用了Web Vitals的时间点来作为阶段的分割线。

beforeunload、发起请求准备阶段

在发起 get index.html 请求前，有一小段时间是在执行 beforeunload ，其实应该还包括了发起 get index.html 请求前的准备工作，如果未来需求里需要引入跨域文件，也许可以使用 dns-prefetch 来进行预解析。即预解析之后可能会用到的域名，并将结果缓存到系统缓存中，缩短 DNS 的查询时间，以此来提高访问速度。这里有个误解，之前以为 dns-prefetch 会影响首屏加载，但其实如果使用的是 chrome ， V8 是会利用空闲的时间去做预解析，并且它的预解析是在异步线程上执行的，可以避免影响首屏加载。不过 dns-prefetch 也不是设置得越多越好，虽然是异步线程，也还是占用设备的带宽，可能会造成资源竞争。

发起请求到FCP阶段

在 First Contentful Paint 之前，可以看到优先级高的关键资源会被首先请求，如 index.html 、 index.css 、 index.js 等。

而关键资源阻塞渲染的时长取决于最大的那个资源，因此猜测这个阶段可以采取利用 webpack 压缩文件、移除非必要的代码等优化方式。

于是实践了一下，使用optimize-css-assets-webpack-plugin压缩css、HtmlWebpackPlugin压缩html，以及webpack生产环境自动开启的js压缩工具测试了一下，结果发现虽然压缩后大小是有所减小（共计缩小了14.9k,为原体积的30%左右），线上network请求时长没什么改善，FCP和LCP也没有有效提前，查看network发现其实这里的速度主要还是取决于TTFB,以get index.js请求为例，大部分时间在Waiting,对于这个项目而言，因为本身文件大小不算大，webpack压缩后并没有起到有效的优化效果。

另外，浏览器为了更好的用户体验会先解析一部分 html ，所以才有了 firstpaint 在 DomContentLoaded 之前，也因此需要把 js 放到 html 的最下面，因为 js 会阻塞 dom 的解析， css 可以放到前面避免页面因为没有样式过于丑陋。于是觉得理论上也许可以尝试将一些不需要在解析 html 阶段使用的 js 标记上 async 或者 defer 。关于aync和defer的区别:

这里也自己实践了一下，给不依赖其他脚本的js script，如上报js加上了aync, 然后把不需要在解析阶段使用的js script加上了defer，但是结果发现并没有想象中地被优化。因为还是存在无法使用defer和aync的js文件，这些文件依然会阻塞渲染时间。而那些加了defer和async的文件其实本身也得益于http/2的server push，所以在这个需求里、在这个实验环境下加defer/async优化方式也不适用。

那么究竟要怎么提前FCP时间呢，这里介绍一下，FCP 是从开始加载到页面内容的任何部分在屏幕上完成渲染的时间，是 Google 的 web vitals 之一，目前灯塔、PageSpeed Insights、Chrome 开发者工具、搜索控制台、web.dev 测量工具和Web 指标 Chrome 扩展程序等工具都提供对他的支持。可以使用这些工具获取FCP和优化建议。对于缩短FCP, Google也给出了一些建议。还是要根据实际情况分析适用于自己项目的方式来进行优化。

查看一下 web-vitals js 库中getFCP源码

FCP到LCP阶段

在这个阶段，占用时间比较多有请求图片、字体资源、优先级低的 js 文件。这里用的是 http/2 ，允许同时通过单一的 http/2 连接发起多重的请求-响应消息，减缓了 tcp 竞争以及队头阻塞。之前有个需求用到了雪碧图，经过指点才了解到因为 http/2 的普及现在其实拆成多个小图反而会更快一些，就是因为 http/2 有多路复用的特性，不再需要通过拼接来减少队头阻塞，多个小图可以同时被请求会比较快。除此之外，也了解到有些针对 http1.1 的性能优化也不再适用了，如域名分片(因为不需要新开连接来解决头阻塞问题)和拼接 js/css (理由同雪碧图)
在实际开发过程中，蜘蛛会自动上传 ossweb-img 中的资源到 CDN , 因此在这一步起到了减少 RTT 时间，优化图片等资源的传输速度的效果。在过去的几个静态页面开发过程中，主要是也是针对这一阶段进行了优化，如压缩图片、压缩字体等。这里想聊一下 font-spider 。他的原理是将页面引用到字体从字体包中拿出来，合成一个新的字体包，这样就不用引入全部字体包中的字体了，实现了按需引入。这里没了解原理之前踩坑了，把一个项目中压缩过的字体包拿到另一个项目用，结果页面中有的字体没有转化过来。因为页面上的字是不一样的，需要按需重新生成新的压缩字体包才可以。

LCP 是测量页面从开始加载到最大文本块或图像元素在屏幕上完成渲染的时间。被 Google 列为了 core web vitals 之一，支持它的工具与 FCP 的一致，对于缩短 LCP ，Google官方也给出了优化建议，还是需要针对自己的情况采取相应的优化措施。

查看一下 web-vitals js 库中getLCP 源码

LCP到Load阶段

在这个阶段，通过查看 main 发现主要是执行了 milo 的 alert("活动已经结束") ，所以可以暂且忽略。但是也验证了异步加载的 js 会影响 load 事件的触发。

交互阶段

华为这个活动页面交互比较少，主要是点击按钮，触发购买等请求 ，由此可见组件化时尽量排除无用的依赖可以加快响应。例子：

未来如果接触到较为复杂的交互功能，理论上应该尽量减少对dom的重排重绘，尽量利用好css合成动画。因为渲染流程包括构建dom树、计算样式、布局、分层、分层、绘制、栅格化、合成和显示等阶段。重排会触发整个渲染流程；重绘会触发绘制后面的一系列渲染流程；而合成就不会再重新触发整个流程或者绘制流程，效率会高很多。对chrome来说，合成是在合成线程上完成的，他不会影响到主线程。因此合理利用合成可以带来较好的用户体验并且提高效率（至少对chrome是这样）

开发体验优化

• 未来可以就css开发做一些优化，比如使用less/sass等；取名方面可以更加规范一些，比如使用 BEM ；要注意去除多余样式、优化结构。
• 可以多关注组件库并且参与开发，以此减少对于milo等库的依赖。
• 也许可以试着引入webpack对代码进行压缩。
• 另外，在开发过程中需要多注意兼容的问题，避免使用覆盖率低的css或html特性。

以上为至今自己在需求中遇到过的性能优化的一些心得体会，未来也希望可以继续学习挖掘更多前端页面性能和开发体验的优化方式。如果有写得不准确的也希望可以多多指正。

参考

• 前端性能监控-基础指标定义&计算
• HTTP/2特性及其在实际应用中的表现
• 分层和合成机制
• 如何系统地优化页面
• DNS prefetch原理
• web vitals
• 埋点sdk设计
• defer vs async

远程Git Repo的安全回退方式

常用回退指令: git revert, git reset

git工作区

Workspace： 工作区，就是你平时存放项目代码的地方。
Index / Stage： 暂存区，用于临时存放你的改动，事实上它只是一个文件，保存即将提交到文件列表信息。git add <file>以后，文件就会被存储于这个区域。
Repository： 仓库区（或版本库），就是安全存放数据的位置，这里面有你提交到所有版本的数据。其中HEAD指向最新放入仓库的版本。git commit <file>以后，文件就会被存储于仓库区。
Remote： 远程仓库，托管代码的服务器，可以简单的认为是你项目组中的一台电脑用于远程数据交换。git push <file>以后，文件就会被上传到远程仓库。

git reset

用于回退版本，可以遗弃不再使用的提交，根据参数的区别，可以指定回退的额范围(scope)，即是否回退暂存区(Index / Stage)和工作区(Workspace)的内容
--hard 参数: 把head移动回指定commit(默认为最新的一个commit)，并且工作区和暂存区内容都将回退
--soft参数：把head移动回指定commit(默认为最新的一个commit)，工作区和暂存区都不会发生变化。即运行git log发现head变化了，其余的都不变。
--mixed参数: 默认的参数，把head移动回指定commit(默认为最新的一个commit)，只有暂存区变化。

git revert

在当前提交后面，新增一次提交，抵消掉上一次提交导致的所有变化，不会改变过去的历史，主要是用于安全地取消过去发布的提交。
注意：git revert <commid>是撤销commid，即撤销到该commid上一个commit,不是撤销到该commid

git reset和git revert的区别

• git revert是用一次新的commit来回滚之前的commit，git reset是直接删除指定的commit；
• git reset是把HEAD向后移动了一下，而git revert是HEAD继续前进，只是新的commit的内容和要revert的内容正好相反，能够抵消要被revert的内容；
• 在操作上，git reset以后如果没有pull就要push的话必须要加-f,这也是reset不安全的理由；
• git revert被设计为撤销公开的提交(已经push了的commit)的安全方式，git reset被设计为重设本地更改。

如何安全地回滚远程分支

1. 使用git revert
2. 使用merge -s产生一个代码状态与历史版本完全一致，但基于 master(要回退到的head) 的一个commit。具体方式

• 两者都是新提交一个commit来撤销操作（忌对远程分支使用reset或rebase， git官方也推荐使用revert）

其他撤销操作小贴士

1. 替换上一次的提交信息

   # 产生一个新的提交对象，替换掉上一次提交产生的提交对象。 # 这时如果暂存区有发生变化的文件，会一起提交到仓库。所以，--amend不仅可以修改提交信息，还可以整个把上一次提交替换掉。 git commit --amend -m "Fixes bug #42"

2. 撤销工作区的文件修改

   # 如果工作区的某个文件被改乱了，但还没有提交，可以用git checkout命令找回本次修改之前的文件。 git checkout -- [filename]

3. 从暂存区撤销文件

   git rm --cached [filename]

参考

• 文章一

• 文章二

• 文章三

• 文章四

• 文章五

Reference from 腾讯云
可用于迭代目前的个人主页

操作场景

该任务指导您通过 Serverless Website 组件，快速构建一个 Serverless Hexo 站点。

前提条件

• 已安装 Node.js（Node.js 版本需不低于8.6，建议使用 Node.js10.0 及以上版本）
• 已安装 Git

如您未安装上述应用程序，可以参考 Hexo 安装说明。

操作步骤

1. 安装

通过 npm 安装 Serverless Framework：

$ npm install -g serverless

通过 npm 安装 Hexo：

$ npm install -g hexo-cli

安装 Hexo 完成后，请执行下列命令，Hexo 将会在指定文件夹中新建所需要的文件。

$ hexo init hexo   # 生成 Hexo 目录
$ cd hexo
$ npm install

新建完成后，指定文件夹的目录如下：

.
├── _config.yml
├── package.json
├── scaffolds
├── source
|   ├── _drafts
|   └── _posts
└── themes

安装完成后，可以通过hexo g命令生成静态页面：

$ hexo g   # generate

?如果希望在本地查看效果，也可以运行下列命令，通过浏览器访问 localhost:4000 查看页面效果。

$ hexo s   # server

2. 配置

在hexo目录下，创建serverless.yml文件：

$ touch serverless.yml

在serverless.yml文件中进行如下配置：

# serverless.yml

component: website # (必填) 引用 component 的名称，当前用到的是 tencent-website 组件
name: hexodemo # (必填) 该 website 组件创建的实例名称
org: test # (可选) 用于记录组织信息，默认值为您的腾讯云账号 APPID
app: websiteApp # (可选) 该 website 应用名称
stage: dev # (可选) 用于区分环境信息，默认值是 dev

inputs:
  src:
    src: ./public # Upload static files generated by HEXO
    index: index.html
    # dist: ./dist
    # hook: npm run build
    # websitePath: ./
  region: ap-guangzhou
  bucketName: my-bucket
  protocol: https
  

配置完成后，文件目录如下：

.
├── .serverless
└── hexo
    ├── public
    ├── ...
    ├── serverless.yml 
    ├── ...
    └── source

3. 部署

通过sls deploy命令进行部署，并可以添加--debug参数查看部署过程中的信息。
如您的账号未 登录 或 注册 腾讯云，您可以直接通过微信扫描命令行中的二维码进行授权登录和注册。

$ sls deploy

serverless ⚡ framework
Action: "deploy" - Stage: "dev" - App: "websiteApp" - Instance: "hexodemo"

region:  ap-guangzhou
website: https://my-bucket-1258834142.cos-website.ap-guangzhou.myqcloud.com


25s › hexodemo › Success

访问命令行输出的 Website URL，即可查看您的 Serverless Hexo 站点。

!如果希望更新 Hexo 站点中的文章，需要在本地重新运行hexo g进行生成静态页面，再运行serverless更新到页面。

4. 移除

通过以下命令移除 Hexo 网站：

$ sls remove --debug

  DEBUG ─ Flushing template state and removing all components.
  DEBUG ─ Starting Website Removal.
  DEBUG ─ Removing Website bucket.
  DEBUG ─ Removing files from the "my-bucket-1250000000" bucket.
  DEBUG ─ Removing "my-bucket-1250000000" bucket from the "ap-guangzhou" region.
  DEBUG ─ "my-bucket-1250000000" bucket was successfully removed from the "ap-guangzhou" region.
  DEBUG ─ Finished Website Removal.

  6s » myWebsite » done

账号配置（可选）

当前默认支持 CLI 扫描二维码登录，如您希望配置持久的环境变量/密钥信息，也可以本地创建 .env 文件：

$ touch .env # 腾讯云的配置信息

在 .env 文件中配置腾讯云的 SecretId 和 SecretKey 信息并保存：

# .env
TENCENT_SECRET_ID=123
TENCENT_SECRET_KEY=123

?

• 如果没有腾讯云账号，请先 注册新账号。
• 如果已有腾讯云账号，可以在 API 密钥管理 中获取 SecretId 和 SecretKey。

LC 28 Implement strStr()

Implement strStr
Return the index of the first occurrence of needle in haystack, or -1 if needle is not part of haystack.

Example 1:

Input: haystack = "hello", needle = "ll"
Output: 2

Example 2:

Input: haystack = "aaaaa", needle = "bba"
Output: -1

Clarification:

What should we return when needle is an empty string? This is a great question to ask during an interview.

For the purpose of this problem, we will return 0 when needle is an empty string. This is consistent to C's strstr() and Java's indexOf().

A

使用哈希值

def strStr(self, haystack: str, needle: str) -> int:
    L, n = len(needle), len(haystack)
    if L > n:
        return - 1
# base value for the rolling hash function
a = 26
# modulus value for the rolling hash function to avoid overflow
modulus = 2**31

# lambda-function to convert character to integer
h_to_int = lambda i : ord(haystack[i]) - ord('a')
needle_to_int = lambda i : ord(needle[i]) - ord('a')

# compute the hash of strings haystack[:L], needle[:L]
h = ref_h = 0
for i in range(L):
    h = (h * a + h_to_int(i)) % modulus
    ref_h = (ref_h * a + needle_to_int(i)) % modulus
if h == ref_h:
    return 0
      
# const value to be used often : a**L % modulus
aL = pow(a, L, modulus) 
for start in range(1, n - L + 1):
    # compute rolling hash in O(1) time
    h = (h * a - h_to_int(start - 1) * aL + h_to_int(start + L - 1)) % modulus
    if h == ref_h:
        return start

return -1

Master

1 etcd is a persistent, lightweight, distributed, key-value data store developed by CoreOS that reliably stores the configuration data of the cluster, representing the overall state of the cluster at any given point of time. Other components watch for changes to this store to bring themselves into the desired state

Hold all metadata?

2 API server is a key component and serves the Kubernetes API using JSON over HTTP, which provides both the internal and external interface to Kubernetes.[25][34] The API server processes and validates REST requests and updates state of the API objects in etcd, thereby allowing clients to configure workloads and containers across Worker nodes.

Commands?

3 Scheduler is the pluggable component that selects which node an unscheduled pod (the basic entity managed by the scheduler) should run on based on resource availability. Scheduler tracks resource utilization on each node to ensure that workload is not scheduled in excess of the available resources. For this purpose, the scheduler must know the resource requirements, resource availability and a variety of other user-provided constraints and policy directives such as quality-of-service, affinity/anti-affinity requirements, data locality and so on. In essence, the scheduler’s role is to match resource "supply" to workload "demand".

Detection?

4 Controller manager is the process in which the core Kubernetes controllers like DaemonSet Controller and Replication Controller run. The controllers communicate with the API server to create, update and delete the resources they manage (pods, service endpoints, etc.)

The one who gives the commands?

Node/Worker/Minion

Kubelet is responsible for the running state of each node, ensuring that all containers on the node are healthy. It takes care of starting, stopping, and maintaining application containers organized into pods as directed by the control plane.[25][36]

Kubelet monitors the state of a pod and if not in the desired state, the pod will be redeployed to the same node. The node status is relayed every few seconds via heartbeat messages to the master. Once the master detects a node failure, the Replication Controller observes this state change and launches pods on other healthy nodes.

Container resides inside a Pod. The container is the lowest level of a micro-service which holds the running application, the libraries and their dependencies. Containers can be exposed to the world through an external IP address.

Kube-proxy is an implementation of a network proxy and a load balancer, and it supports the service abstraction along with other networking operation.[25] It is responsible for routing traffic to the appropriate container based on IP and port number of the incoming request

• A reverse proxy accepts a request from a client, forwards it to a server that can fulfill it, and returns the server’s response to the client.
• A load balancer distributes incoming client requests among a group of servers, in each case returning the response from the selected server to the appropriate client.

cAdvisor is an agent that monitors and gathers resource usage and performance metrics such as CPU, memory, file and network usage of containers on each node.

在分布式系统中，部署，调度，伸缩一直是最为重要的也最为基础的功能。Kubernets 就是希望解决这一序列问题的。

https://yeasy.gitbooks.io/docker_practice/content/kubernetes/quickstart.html

快速上手

目前，Kubenetes 支持在多种环境下的安装，包括本地主机（Fedora）、云服务（Google GAE、AWS 等）。然而最快速体验 Kubernetes 的方式显然是本地通过 Docker 的方式来启动相关进程。

下图展示了在单节点使用 Docker 快速部署一套 Kubernetes 的拓扑。

图 1.21.2.1 - 在 Docker 中启动 Kubernetes

Kubernetes依赖Etcd服务来维护所有主节点的状态。

启动Etcd服务。

docker run --net=host -d gcr.io/google_containers/etcd:2.0.9 /usr/local/bin/etcd --addr=127.0.0.1:4001 --bind-addr=0.0.0.0:4001 --data-dir=/var/etcd/data

启动主节点

启动kubelet。

docker run --net=host -d -v /var/run/docker.sock:/var/run/docker.sock gcr.io/google_containers/hyperkube:v0.17.0 /hyperkube kubelet --api_servers=http://localhost:8080 --v=2 --address=0.0.0.0 --enable_server --hostname_override=127.0.0.1 --config=/etc/kubernetes/manifests

启动服务代理

docker run -d --net=host --privileged gcr.io/google_containers/hyperkube:v0.17.0 /hyperkube proxy --master=http://127.0.0.1:8080 --v=2

测试状态

在本地访问 8080 端口，可以获取到如下的结果：

$ curl 127.0.0.1:8080
 {
  "paths": [
   "/api",
   "/api/v1beta1",
   "/api/v1beta2",
   "/api/v1beta3",
   "/healthz",
   "/healthz/ping",
   "/logs/",
   "/metrics",
   "/static/",
   "/swagger-ui/",
   "/swaggerapi/",
   "/validate",
   "/version"
  ]
 }

查看服务

所有服务启动后，查看本地实际运行的 Docker 容器，有如下几个。

CONTAINER ID    IMAGE                    COMMAND        CREATED       STATUS       PORTS        NAMES
 ee054db2516c    gcr.io/google_containers/hyperkube:v0.17.0  "/hyperkube schedule  2 days ago     Up 1 days                k8s_scheduler.509f29c9_k8s-master-127.0.0.1_default_9941e5170b4365bd4aa91f122ba0c061_e97037f5
 3b0f28de07a2    gcr.io/google_containers/hyperkube:v0.17.0  "/hyperkube apiserve  2 days ago     Up 1 days                k8s_apiserver.245e44fa_k8s-master-127.0.0.1_default_9941e5170b4365bd4aa91f122ba0c061_6ab5c23d
 2eaa44ecdd8e    gcr.io/google_containers/hyperkube:v0.17.0  "/hyperkube controll  2 days ago     Up 1 days                k8s_controller-manager.33f83d43_k8s-master-127.0.0.1_default_9941e5170b4365bd4aa91f122ba0c061_1a60106f
 30aa7163cbef    gcr.io/google_containers/hyperkube:v0.17.0  "/hyperkube proxy --  2 days ago     Up 1 days                jolly_davinci
 a2f282976d91    gcr.io/google_containers/pause:0.8.0     "/pause"        2 days ago     Up 2 days                k8s_POD.e4cc795_k8s-master-127.0.0.1_default_9941e5170b4365bd4aa91f122ba0c061_e8085b1f
 c060c52acc36    gcr.io/google_containers/hyperkube:v0.17.0  "/hyperkube kubelet  2 days ago     Up 1 days                serene_nobel
 cc3cd263c581    gcr.io/google_containers/etcd:2.0.9     "/usr/local/bin/etcd  2 days ago     Up 1 days                happy_turing

这些服务大概分为三类：主节点服务、工作节点服务和其它服务。

主节点服务

• apiserver 是整个系统的对外接口，提供 RESTful 方式供客户端和其它组件调用；
• scheduler 负责对资源进行调度，分配某个 pod 到某个节点上；
• controller-manager 负责管理控制器，包括 endpoint-controller（刷新服务和 pod 的关联信息）和 replication-controller（维护某个 pod 的复制为配置的数值）。

工作节点服务

• kubelet 是工作节点执行操作的 agent，负责具体的容器生命周期管理，根据从数据库中获取的信息来管理容器，并上报 pod 运行状态等；
• proxy 为 pod 上的服务提供访问的代理。

其它服务

• Etcd 是所有状态的存储数据库；
• gcr.io/google_containers/pause:0.8.0 是 Kubernetes 启动后自动 pull 下来的测试镜像。

Homebrew基础

Homebrew总结

1. 就像ubuntu的ppa一样，很多时候有些软件包并不在官方提供列表里面而是由第三方提供的这个时候，我们就需要使用下面的命令：

   brew [un]tap <github_userid/repo_name> #添加或者删除仓库

   注意repo_name只是实际仓库名的一部分，而实际仓库名的前缀必须是homebrew-。比如

   brew tap neovim/neovim # 这样实际仓库名就是homebrew-neovim

   官方文档中提出brew tap作用用于添加更多仓库，默认情况下tap假设这些仓库来源于github，但又不局限于它。

   不带参数的话，将会列出当前已经tapped的仓库，比如：

   brew tap ==> Auto-updated Homebrew! Updated 1 tap (homebrew/core). No changes to formulae. caskroom/cask homebrew/core homebrew/dupes neovim/neovim

   总共列出了四个仓库，其中前面三个是默认自带的。

   如果你要增加的仓库已经存在于homebrew/core中了(名字一样)，你必须显性的安装：

   brew install vim # installs from homebrew/core brew install username/repo/vim # installs from your custom repo

2. 由于各种原因，用homebrew跟新下载软件有时非常慢，这个时候你可以尝试更换源，这个概念和其它包管理器的概念是一致的，也就是换个软件服务器。

   有两个源:

   1. homebrew自身程序公式的服务器地址

      homebrew托管于github，如果你访问这个网站没有问题，那就不需要换了，要换也非常简单，相当于给你的git仓库换一个远程地址，而homebrew的仓库位置默认位于/usr/local/Homebrew下（这个位置是homebrew 1.0之后才变的）。

      cd /usr/local/Homebrew git remote set-url origin http://mirrors.ustc.edu.cn/homebrew.git cd ~ mkdir tmp cd tmp git clone http://mirrors.ustc.edu.cn/homebrew.git cp -R homebrew/.git /usr/local/Homebrew cp -R homebrew/Library /usr/local/Homebrew

   2. 二进制的服务器地址，做法很简单，就是：

      echo 'export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.ustc.edu.cn/homebrew-bottles' >> ~/.zshrc source ~/.zshrc

      shell 在启动时都会去找配置文件，然后运行它。你安装的一些脚本，如果想让它能够全局运行，就需要在配置文件中设置路径。有过设置路径后还是不管用的经历吗？多半是因为把配置写在了错误的配置文件里。**应该在配置shell（最常见的是配置默认命令）之前，使用 echo $SHELL，确认自己现在用的是什么shell后，再去编辑对应的配置文件 **

参考

Homebrew总结

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

Quick Start

Create a new post

$ hexo new "My New Post"

More info: Writing

Run server

$ hexo server

More info: Server

Generate static files

$ hexo generate

More info: Generating

Deploy to remote sites

$ hexo deploy

More info: Deployment