1、努力提高技术,争取早日实现跳槽自由
2、
3、
弧度的概念是怎么来的:
度的概念才是人为直观区分的,它和一年有365天相关
而弧度才是圆本身的一种度量,它是由圆周率这个概念引申出来的
弧度能带来什么方便呢,最主要的是它是一个数字,可以进入数系计算
4、
编写漂亮的代码。丑陋的代码会隐藏问题,让想要帮助你的人无从下手。
当我们想通过阅读代码的方式来了解一个新的项目时,一般都是采取广度优先的策略,自上而下的阅读代码,先了解整体结构,然后再深入感兴趣的细节。
如果没有对实现细节进行良好的抽象(并凝练出一个名副其实的函数),那么阅读者就容易迷失在细节的汪洋里
有表达力的代码是无需注释的:注释的适当作用在于弥补我们用代码表达意图时遇到的失败,这听起来让人沮丧,但事实确实如此。
我们常说,好的代码需要有可读性、可维护性、可扩展性,好的代码、架构需要不停的重构、迭代,但自动化测试是保证这一切的基础,没有高覆盖率的、自动化的单元测试、回归测试,谁都不敢去修改代码,只能任其腐烂。
5、
6、
IaaS是基础设施即服务,只给客户提供服务器资源,其他的工作客户自己完成,可以理解成一台没有安装操作系统的电脑。通过虚拟化技术,可以让客户想要多少电脑就有多少电脑。
PaaS是平台即服务,给客户提供服务器的基础上把平台搭建好,让客户有个编程环境,可以可以把自己的程序部署上去,可以理解成一台安装了操作系统和数据库的电脑。
SaaS是软件即服务,给客户提供现成的在线软件。相当于一台已经安装了客户要使用的软件的电脑。
能够真正提供稳定IaaS的企业非常少,而且未来会越来越少,马太效应明显。提供IaaS的企业往往也提供PaaS。
从市场规模上看, SaaS﹥IaaS﹥PaaS
云游戏实现的原理是什么呢?
一句话:用宽带(网络)代实体线缆。
平时大家的游戏是存在电脑主机里,主机用线缆和屏幕相连,你才能看到游戏界面。
现在,你的主机变成了某个遥远的数据中心虚拟出的主机里,这台虚拟主机性能极其强劲,而且想要多强就有多强,然后通过宽带(网络)代替线缆把这台云主机和你的屏幕相连接。
只要网速够快,延迟够低,你就愉快地玩耍吧。
5G刚好就能够让网速够快、延迟够低。
7、
你要判断你领导的核心需求是什么(如果判断不出来,就找你的领导去沟通交流,但凡一个正常的领导都会告诉你的)。
你努力的事情能不能满足你的领导的核心需求,为领导创造价值。
如果都不能,就不要抱怨自己干活多,任务重而不受重视了。就多想想这些工作能不能给自己带来提升。
如果也不能,证明你的工作没有任何价值,可有可无,趁早离职才好
8、
链接:https://www.zhihu.com/question/23774081/answer/1191077182
为什么需要数据产品
If you can’t measure it, you can’t improve it(如果你无法衡量,你就无法增长). 数据驱动增长。
03 如何设计数据产品?
对于产品设计来讲,一些固定的步骤必不可少。厘清这些内容后,大到系统级的产品规划,小到功能级的产品设计,概念上都会清晰很多,我们将它抽象成了五个步骤:
面向什么用户和场景
不同用户有不同的价值。这个方法主要面向第一类即企业内部产品。这里并不主张职位歧视,只是从数据能产生的价值来看,高层的一个正确的决断可以节省下面无数的成本
不同层级用户关心的粒度不一样,永远要提供下一个颗粒度的分析以及可细化到最细粒度的入口。数据分析本质上就是不断细分和追查变化
要了解自己的用户,必须和他们保持长期有效的沟通。如 GrowingIO 的 PM,每周都会有和销售和客户沟通的习惯,而且每位 PM 入职后,必须兼职一段时间的客服
解决什么问题/带来什么价值
首先判断核心需求是什么,可用 Demand/Want/Need 方法分析。用户来找你要可乐 (Demand),如果你没有可乐就无法满足用户。但其实他只是要解渴 (Want),需要的只是一杯喝的东西就够了 (Need)。
其次判断需求的价值,可用 PST 方法分析。P:x 轴,用户的痛苦有多大;Y 轴,有多少用户有这种痛苦;z 轴:用户愿意为这付出多少多少成本。相乘得出的结果才是这个需求的价值。
问题的分析思路是什么
需要用到什么样的指标
数据的完备性提前明确所有需要的数据是否已经准备完全。数据就像水面上的冰山,展示出来的只是很小的一部分,它的采集,清洗和聚合才是水面下 98% 的部分。
所以如果需要的数据没有采集或没有经过清洗的话,会让整个工期增加了极大的不稳定因素。
这些指标该怎么组合展现
9、虽然下图不一定是真实的,但是却是符合人的直观认知的
网友评论