Linux    2020-03-04 10:03:28    18    0    0

# uname -a # 查看内核/操作系统/CPU信息 
# head -n 1 /etc/issue # 查看操作系统版本 
# cat /proc/cpuinfo # 查看CPU信息 
# hostname # 查看计算机名 
# lspci -tv # 列出所有PCI设备 
# lsusb -tv # 列出所有USB设备 
# lsmod # 列出加载的内核模块 
# env # 查看环境变量资源 
# free -m # 查看内存使用量和交换区使用量 
# df -h # 查看各分区使用情况 
# du -sh <目录名> # 查看指定目录的大小 
# grep MemTotal /proc/meminfo # 查看内存总量 
# grep MemFree /proc/meminfo # 查看空闲内存量 
# uptime # 查看系统运行时间、用户数、负载 
# cat /proc/loadavg # 查看系统负载磁盘和分区 
# mount | column -t # 查看挂接的分区状态 
# fdisk -l # 查看所有分区 
# swapon -s # 查看所有交换分区 
# hdparm -i /dev/hda # 查看磁盘参数(仅适用于IDE设备) 
# dmesg | grep IDE # 查看启动时IDE设备检测状况网络 
# ifconfig # 查看所有网络接口的属性 
# iptables -L # 查看防火墙设置 
# route -n # 查看路由表 
# netstat -lntp # 查看所有监听端口 
# netstat -antp # 查看所有已经建立的连接 
# netstat -s # 查看网络统计信息进程 
# ps -ef # 查看所有进程 
# top # 实时显示进程状态用户 
# w # 查看活动用户 
# id <用户名> # 查看指定用户信息 
# last # 查看用户登录日志 
# cut -d: -f1 /etc/passwd # 查看系统所有用户 
# cut -d: -f1 /etc/group # 查看系统所有组 
# crontab -l # 查看当前用户的计划任务服务 
# chkconfig –list # 列出所有系统服务 
# chkconfig –list | grep on # 列出所有启动的系统服务程序 
# rpm -qa # 查看所有安装的软

Go教程    2020-03-02 12:30:07    69    0    0

1. 背景

上周四小伙伴发了Go社区一个帖子下hej8875的回复,如下:

package main
import "fmt"
func main() {
s := []byte("")
s1 := append(s, 'a')
s2 := append(s, 'b')
//fmt.Println(s1, "==========", s2)
fmt.Println(string(s1), "==========", string(s2))
}
// 出现个让我理解不了的现象, 注释时候输出是 b ========== b
// 取消注释输出是 [97] ========== [98] a ========== b

这个回复比原贴有意思,也很有迷惑性。作者测试了下,确实如此,于是和小伙伴们讨论深究下。开始以为应该挺简单的,理解后,发现涉及挺多知识点,值得跟大家分享下过程。

2. slice

2.1 内部结构

先抛去注释的这行代码//fmt.Println(s1, "==========", s2),后面在讲。 当输出 b ========== b时,已经不符合预期结果a和b了。我们知道slice内部并不会存储真实的值,而是对数组片段的引用,其内部结构是:

type slice struct {
    data uintptr
    len int
    cap int
}

其中data是指向数组元素的指针,len是指slice要引用数组中的元素数量。cap是指要引用数组中(从data指向开始计算)剩余的元素数量,这个数量减去len,就是还能向这个slice(数组)添加多少元素,如果超出就会发生数据的复制。slice的示意图:

s := make([]byte, 5)// 下图

img

s = s[2:4]  //会重新生成新的slice,并赋值给s。与底层数组的引用也发生了改变

img

2.2 覆盖前值

回到问题上,由此可以推断出:s := []byte("") 这行代码中的s实际引用了一个 byte 的数组。

其capacity 是32,length是 0:

s := []byte("
2020-02-27 14:57:08    518    0    0

Starting Shadowbox .......................... FAILED
docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.
See 'docker run --help'.
Sorry! Something went wrong. If you can't figure this out, please copy and paste all this output into the Outline Manager screen, and send it to us, to see if we can help you.


解决Starting Shadowbox FAILED的方案,请按顺序安装,亲测可用!

yum update -y   



sudo yum install -y yum-utils device-mapper-persistent-data lvm2



sudo yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo



sudo dnf install https://download.docker.com/linux/centos/7/x86_64/stable/Packages/containerd.io-1.2.6-3.3.el7.x86_64.rpm



dnf --disablerepo=AppStream install docker-ce   (sudo yum install docker-ce)



systemctl enable docker.service



sudo systemctl start docker​
Go教程    2020-02-25 17:39:24    2693    0    0

最新版本的Google资深工程师深度讲解Go语言视频已经更新了,看到网上很多人在找,本人整理了一下最详细的Go语言深度讲解视频百度云分享给大家,内容比较多最好是直接保存,然后用手机在线观看。

Google资深工程师深度讲解Go语言视频

课程目录

第1章课程介绍

第2章基础语法

第3章内建容器

第4章面向“对象”

第5章面向接口

Google资深工程师深度讲解Go语言视频

第6章函数式编程

第7章错误处理和资源管理

第8章测试与性能调优

第9章Goroutine

第10章Channel

第11章http及其他标准库

第12章迷宫的广度优先搜索

第13章开始实战项目

Google资深工程师深度讲解Go语言视频

第14章单任务版爬虫

第15章并发版爬虫

第16章数据存储和展示

第17章分布式爬虫

第18章课程总结

Google资深工程师深度讲解Go语言视频

go语言的优点

原因 1:性能

Go 极其地快。其性能与 Java 或 C++相似。在我们的使用中,Go 一般比 Python 要快 30 倍。

原因 2:语言性能很重要

对很多应用来说,编程语言只是简单充当了其与数据集之间的胶水。语言本身的性能常常无关轻重。

但是 Stream 是一个 API 提供商,服务于世界 500 强以及超过 2 亿的终端用户。数年来我们已经优化了 Cassandra、PostgreSQL、Redis 等等,然而最终抵达了所使用语言的极限。

原因 3:开发者效率&不要过于创新

如果你是一个新手,看到这段代码你并不会感到吃惊。它展示了多种赋值、数据结构、指针、格式化以及内置的 HTTP 库。

当我第一次编程时,我很喜欢使用 Python 的高阶功能。Python 允许你创造性地使用正在编写的代码,比如,你可以:

在代码初始化时,使用 MetaClasses 自行注册类别

置换真假

添加函数到内置函数列表中

通过奇妙的方法重载运算符

毋庸置疑这些代码很有趣,但也使得在读取其他人的工作时,代码变得难以理解。

Go 强迫你坚持打牢基础,这也就为读取任意代码带来了便利,并能很快搞明白当下发生的事情。

原因 4:并发性&通道

Go 作为一门语言致力于使事情简单化。它并未引入很多新概念,而是聚焦于打造一门简单的语言,它使用起来异常快速并且简单。其唯一的创新之处是 goroutines 和通道。Goroutines 是 Go 面向线程的轻量级方法,而通道是 goroutines 之间通信的优先方式。

创建 Goroutines 的成本很低,只需几千个字节的额外内存,正由于此,才使得同时运行数百个甚至数千个 goroutines 成为可能。你可以借助通道实

监控    2020-02-25 15:58:22    47    0    0

监控是分布式系统的必备组件,能够起到提前预警、问题排查、评估决策等功效,乃行走江湖、居家必备之良品。

监控系统概要

功能划分

一个宿主机cpu的报警叫做监控;一个业务日志的报错叫做监控;一个APM条件的触发,也叫做监控。分布式系统错综复杂,随便做个统计指标的集合,也属于监控的范畴。怎样做到通用化,理清其中的关系,是需要花点功夫的,否则揉成一团,就不好拆了。

我习惯性从以下两种类型对其进行划分,真正实施起来,系统还是按照数据象限分比较合理: 数据象限 从数据类型划分,大体可分为:日志(logs)、监控(metrics)、调用链(tracing)。 功能象限 从业务角度划分,可分为:基础监控、中间件监控、业务监控

不管什么样的监控系统,又涉及以下几个模块过程:

数据收集。如何在广度和效率上进行数据归并。 ❏ 数据加工。数据的整理、传输和存储。 ❏ 特称提取。大数据计算,中间结果生成存储。 ❏ 数据展示。高颜值、多功能显示。

其中,特征提取只有数据量达到一定程度才会开启,因为它的开发和运维成本一般小公司是不会玩的。

典型实现

不同的监控模块,侧重于不同领域,有着不同的职责。我个人是倾向于 独立设计 的,但需要做一定程度的集成,主要还是使用方式上的集成和优化。

我将从几个典型解决方案说起,来说一下为什么要分开设计,而不是揉成一团。

系统监控

系统监控用来收集宿主机的监控状况(网络、内存、CPU、磁盘、内核等),包括大部分数据库和中间件的敏感指标。这些metric的典型特点是结构固定、有限指标项,使用时序数据库进行存储是最合适的。

指标收集方面,支持多样化的组件将被优先下使用。比如telegraf,支持所有的系统指标收集和大部分中间件和DB的指标收集。

在这里特别推荐一下其中的jolokia2组件,可以很容易的实现JVM监控等功能。

指标收集以后,强烈建议使用kafka进行一次缓冲。除了其逆天的堆积能力,也可以方便的进行数据共享(比如将nginx日志推送给安全组)。 参考本公众号:【360度测试:KAFKA会丢数据么?其高可用是否满足需求?】

指标进入消息队列后,一份拷贝将会通过logstash的过滤和整理入库ESNoSQL;另外一份拷贝,会经过流计算,统计一些指标(如QPS、平均相应时间、TP值等)。

可以有多种途径计算触发报警的聚合计算。回查、叠加统计都是常用的手段。在数据量特别大的情况下,先对指标

人人都是产品经理    2020-02-25 11:43:53    26    0    0

无论是对产品、运营还是设计来说,理解用户需求是关键的一步也是最重要的一步。而关于如何理解用户需求的文章不少,读过后你是否能真正理解呢?还是似懂非懂,但到了落地环节又不知道如何入手?如果你又这样的遭遇与疑惑,那么本文会告诉你一些实操性更强的理解方法。

一、为什么要理解“用户需求”

对产品经理、设计师、互联网从业人员来说,用户需求的重要性毋庸置疑。

但在我过往的经历中,遇到过一些营销、运营以及其他职能人员,他们做事情的出发点更多是靠自己的经验或者看竞品在做什么,而不是先考虑目标用户是什么样的人,有什么样的功能和情感需求,应该如何打动他们。

很多时候他们只是在复制自己或别人过往的套路,这样虽然思考成本低而且快,但是做跟风者,上限总是有限的。

用户需求其实是个挺玄的词。很多专业人士即使态度上重视用户需求,但是也会被一些因素误导或者自己在挖掘用户需求时犯错,最终搞砸产品或者项目。

80年代,可口可乐听用户说我们要尝点新口味,费了半天劲推出了New coke,结果一上市差点被愤怒的消费者把店砸了…..

每个人都会把这句话挂在嘴边“我们要满足顾客/用户/客户需求”,但是究竟什么是用户需求?其实很多时候,需求不是用户讲出来的,而埋藏在用户的话语和行为背后,需要一些方法或者模型工具,才能洞察真相。

我们今天就来一起探讨如何真正理解用户需求。

二、克里斯坦森:用户目标理论

克莱顿·克里斯坦森(Clayton M. Christensen)在提出颠覆性创新理论之后,遇到了一些麻烦:理论很好很受欢迎,但是这个理论只是指出了问题,而没有告诉你该去哪里找到新机会。

所以在很长一段时间里,他边实践边提炼方法论,最终在自己的理论基础上演化出了“用户目标达成理论”——以用户目标(Jobs to be done)这个概念代替了传统的“用户需求”,来更深入的分析挖掘用户究竟想要什么。

克里斯坦森认为传统定义的“用户需求”太空泛了,像“我要吃饱”或者“我想走路时省点力”之类的需求其实说了和没说一样。

很多企业又是有了一个笼统的需求方向,老板就开始拍板做产品/方案,而各级人员为了已经投入的成本和给老板汇报时许下的承诺,找来各种看起来是证据的数据和材料来支持这个方向必须是对的,等到产品/方案真上市了,被友商锤得满地找牙,又回来开始互相指责……

嗯,跑题了。

克老师举的例子是赛格威(Segway),产品看起来很酷,刚上市时也是受到媒体热捧,

人人都是产品经理    2020-02-25 09:46:50    12    0    0

由于产品对象与场景的不同,所以C端产品需求与B端产品需求是截然不同的,如果以C端产品思维去做B端产品,那结果可能是相当“难以言喻”的。那细化到B端产品,怎么去规划B端产品的需求,怎么去判定产品需求的优先级呢?本文将告诉你答案。

世上本没有优先级,资源紧了,计划多了,自然就有了。

前篇文章,《需求太多?1个思考流程,轻松规划C端产品需求优先级》对C端需求优先级规划做了一个系统的梳理和决策思路。

根据规划层级的逻辑去思考,将需求关联到具体频道、模块下,结合整个核心模块流程来思考需求的价值,这种方法是相对完整和客观的,既避免了因需求评估维度单一导致错过真实需求,又可以通过层层思考,抽丝剥茧筛选出真正符合产品当下规划的需求,还可以锻炼产品经理的抽象能力和系统思考能力。

一、C端需求和B端需求的管理差异

因为笔者目前所在公司的两款核心产品,正好一个是面向个体用户的用户端产品,一个是面向组织、团体的协同OA产品,因此在工作中经常接触C端和B端的产品需求,最近在做需求规划的时候,也总结了两者的相同点和不同之处。

1. 相同点

1)需求管理的目的相同

都是为了集中当下优势资源为服务对象提供有客户价值的需求,对内提高资源利用率,保证产品开发团队良性运营;对外通过提供切实的服务,满足市场和用户需求,从而为公司创收,因此任何形式的产品,需求管理的本质是相通的。

2)需求规划的方法类似

在实际工作中,很多从C端转行到B端的产品经理,经常会用C端的工作思路去做B端的需求规划,虽然产品类型不同,但需求规划、分析的方法确实有相同之处;

在做需求规划时,通常都会优先思考与公司战略和规划相匹配的需求,其次是可以直接或间接为公司带来业务发展和收入增长的相关需求。

而且下图所示的一些思考层级和工具,在B端也同样可以使用,比如可以使用SWOT分析优劣势、KANO模型进行需求分类等等。

C端产品需求规划

2. 不同点

1)因为产品面向的服务对象和场景的性质不同,因此需求本质也就不同。

按照C端产品围绕核心路径打造极致体验的思路,作为产品经理们,可以按照自己的需求认知,将不利于核心场景的需求拒之门外,也可以义正言辞的说:此类需求严重影响产品核心体验,不予采纳;而B端产品需求规划的思路,是围绕核心业务场景完善业务闭环。B端需求基本来自真实的业务场景,1个需求可能来自10个业务方的反馈,10个需求可能满足100个业务场景,因此B端的需求基本都有

人人都是产品经理    2020-02-25 09:33:31    24    0    0

近些年来,生鲜电商概念一直很火,入局者也不在少数,但是在发展过程中,那些一味依赖“烧钱模式”的入局者纷纷倒下,而活着的也还在曲折前行,尚未看见黎明的曙光。很多人都会疑惑生鲜电商的春天到底在何处?而此次疫情,似乎向我们透露了答案,并引发我们进行更多的思考。

生鲜电商起步于2009年,在2016年面临大败退。而在随后的几年里,生鲜电商打碎、重组、涅槃,诞生了一些更有生命力的新模式,如:前置仓模式、线上线下一体化模式、社区团购模式等。本文希望回答以下几个问题:

生鲜电商为什么难做,为什么绝大部分的生鲜电商企业都在亏损;生鲜电商发展脉络的内在逻辑是什么;疫情之后,生鲜电商是不是迎来了真正的爆发机遇,往若当年非典之于淘宝。

一、生鲜电商难在哪

生鲜电商并未脱离零售的基本面,而零售的内核是将商品高效率的从一个地方(上游如产地等)转移至另一个地方(消费者手中),在这里谁能做到更好的货源、更低的转移成本、更高的获客能力以及更强的消费者洞察力就能获胜。

所以我们看到零售的比拼将是全链条效率的比拼。

生鲜电商如果想获得消费者的青睐,本质上是需要相比过往的生鲜销售模式创造了新的价值,比如更低的价格、更好的品质、更丰富的商品。

因此生鲜电商要做好同样也离不开几个核心问题:供应链、仓储物流配送、损耗管控以及消费者需求管理,这里为了便于分析,将问题简化为供应链端及零售端,我们从这两端来看生鲜电商所面临的问题。

1. 供应链

受40年前包产到户政策影响,目前生鲜行业尤其是蔬菜品类在生产环节极度分散,且供应链链条非常长,目前典型的供应链链条是:农户(合作社)-农产品代办-产地批发商(可能存在多级)-销地批发商(可能存在多级)-农贸市场。

从最上游的生产环节,到消费者的手中,最少要经历4-5个环节。

最上游的生产环节,当前仍是以果农、菜农等个体户种植为主,虽然各级政府可能把当地农民组织在一起进行统一的种植生产,但是在经营环节,仍没有出现一个强大的主体将分散的果农、菜农进行整合。

现存的合作社,大部分规模较小,缺少现代市场化经营的能力,因此在与下游的采购人员对接时,仍是以分散化的个体或者小规模的合作社为主体。

同时,当前生鲜流通环节的关键节点,如农产品代办、批发商也是以个体为主,普遍缺少规模化运作的能力,造成批发商亦分散且链条长。

而生鲜电商也是在这一基本面下开展业务,如果缺乏强大的供应链整合能力,其在供应链端无任何优势存在,也

人人都是产品经理    2020-02-25 09:32:31    54    0    0

本文就从上瘾模型来分析,这几款APP都是怎样让用户逐渐“上瘾”的,而作为产品的我们,在设计产品的时候,又应该怎样设计,把拉新-留存-促活-转化的过程做好。

每天晚上抱着手机从朋友圈到抖音,从微博到今日头条,刷到凌晨还不舍得睡觉,很多人称之为“报复性熬夜”。但是如果细心分析会发现睡觉前刷的都是这些APP,这似乎已经成为了一种习惯。

那为什么会是这几款APP呢?其实这就是走进了产品设计的上瘾模型了。

本文就从上瘾模型来分析,这几款APP都是怎样让用户逐渐“上瘾”的,而作为产品的我们,在设计产品的时候,又应该怎样设计,把拉新-留存-促活-转化的过程做好。

很多人都听说过上瘾模型的四个阶段,但是在实际设计产品的时候却利用不上,使用一个理论为指导的前提是你足够清楚明白该理论。本文会以具体产品作为案例,一起看看在上瘾模型的四个阶段中一些产品的场景及设计。

一、上瘾模型介绍

笔者是在《上瘾:让用户养成使用习惯的四大产品逻辑》的书中了解到上瘾模型,上瘾模型是培养用户使用习惯的一套标准化模型方法,它由四个阶段构成,分别是:触发、行动、多变的筹赏、投入。

上瘾模型看似相对单一的阶段,但又是相互辅助影响的综合效果。从前期的用户触发开始,下载了我们的APP,到用户基于某种动机,开始第一次使用我们的APP,再到我们通过多种的酬赏,让用户成为了我们的活跃用户,最终投入了时间及精力去使用,让产品从非必需品成为了必需品,养成使用习惯。

下面本文将结合理论详细介绍在这些过程中,有哪些产品的设计是值得我们学习的,它在哪些地方做得好。

二、触发

神经系统科学家指出,人脑中存在一个负责无意识行为的底层神经节,那些无意识产生的条件反射会以习惯的形式存储在基地神经节中,从而使人可以腾出精力去做其他的事。这意味着,当面对类似问题和环境时,大脑会触发这种无意识的行为,这就是习惯。而每一个习惯形成的背后都是始于某个触发,触发分为两种:外部触发和内部触发。

外部触发的主要目标是获取新用户,常规操作有付费型、回馈型、人际型和自主型四种:

(1)付费型

做广告或是通过搜索引擎做推广,价格较高。

付费型触发是通过各种渠道各种渠道的广告、搜索引擎优化(SEO)、应用市场搜索优化(ASO)等付费的方式吸引用户下载该APP,瓜子二手车为赶集网内部孵化的项目之一。

早在PC时代,赶集网与58同城就在SEO领域获取了大量的流量,脱胎于赶集的瓜子。其广告风格和广告

人人都是产品经理    2020-02-24 18:27:21    24    0    0

聊了那么久的中台概念,本篇文章我们来看一个中台MVP的实战案例,以底层数据中心为例的实战案例。在前几篇文章《中台实战0、1、2》中我们已经详细描述了中台战略的建设目标与演化方式,抽象来看我们可以将其总结为这三个关键词:复用、提效、一次开发。

一、中台化前的产品现状

在项目早期我们公司提供的服务就是在线酒店预订,这种业务模式的整个流程也不复杂,主要分为这几个环节:

BD进行拓店->邀请酒店入驻平台->平台上架->用户下单->分佣

重点来看第一个环节,BD拓店实际就是将线下的酒店住宿服务当做商品“进货”至公司的后台中,从而为后面整个服务奠定基础,这里也是整个业务的核心与数据唯一进口。

在这个环节中公司由BD与商务团队维护并积累的大量底层“商品”数据,而初期这些底层数据在数据库中,就是简单的以“Key=Value”形式进行存储。

存储字段截取

当经过一段时间的积累后,这种数据存储方式由于维度简单导致的结果,就是整个数据库的数据量在很短时间内出现猛增。

但是虽然看着每天都有“商品”数据入库,慢慢的我们却发现这些数据很多都是没有办法进行二次使用的,只能供特定的业务方进行独立使用。

具体来说,在公司内部我们通常会有多个业务团队,每个业务团队往往都会根据自己的业务需求在数据库中建立一张属于自己的数据库表(这里为了行文方便我们视作一个表),这些表的业务数据字段与定义方式都是按照业务方定制化进行的。

例如在当时,我们的酒店预订就分为两个业务团队:

非标住宿预定,也就是民宿;标准酒店预定;所以此时在后台我们有了两套业务数据体系,这些数据都是这两个业务方进行自主定义的。

二、挑战:业务线

这样的数据看似很寻常,目前很多企业也是这样对内部团队管理的。但是对于这种我称之为依托于前端统一团队的业务来说(两个业务方由统一的一群BD去进行扫街),我们实际上去做的就是将已经标准化了的数据(酒店录入数据)再次人为进行了割裂,变成了两个独立的业务数据库,如下图所示。

我们要知道很多企业平时日常所做的工作大多数都是在进行数据的迁移与整合,如:将用户行为数据与用户唯一标识数据结合,从而唯一确定分析这个用户的喜好。

那么也就意味着我们每破坏一次数据之间的关联性就意味着,为后期增加了一次需要进行反向操作,也就是将数据进行合并的工作负担。特别是我们将酒店天然性以业务墙进行了阻拦,更是破坏了数据的强关联性(同类数据)。

同时这样的数据也使得对于既

14/155