永辉云创的 CPO 问了一个问题，为什么菜市场有卖水果，水果店不卖蔬菜？
其实这个问题我思考了两天，但是一直没有一个信服的答案，以至于我都觉得蔬菜店卖水果可行。
首先，回忆一下菜市场有卖水果，水果店不卖蔬菜是不是事实。
总的来说水果店不太会卖蔬菜，蔬菜店会卖水果是一个事实。
在使用 Axure 的过程中，会加入一些 Library。除了基本的自带的库以外，以下是我常用的一些额外的库。
此次推出的 FontAwesome 图标元件库不再是由小楼制作，而是 Axure 官方制作并提供的。
简单地说就是让干系人提前了解产品。
在这之中需要向他人传达产品的设计背景，自己的设计理念，产品的业务逻辑等
需求评审不是一轮就可以结束的事情，可能有产品内部需求评审，技术需求评审，相关业务线评审。
面对不同的评审环节，可能有不同的评审重点，但是评审的准备工作和评审的重点都是一致的。
对于出国的方案，之前用的一直都是 ClashX，在正常的使用情况下完全够用。但是现在遇到了一个问题，想修改系统的网络请求。
由于最近人人影视更新了，之前的去广告方案已经失效 去除人人影视广告。经过一轮分析，发现人人影视的广告信息和影片的信息在一个接口里面，很难通过屏蔽一个接口的方式来屏蔽广告。于是我想要修改一个接口里面的数据，来劫持广告。
具体过程就不描述了，这次的重点是 Surge 3。
我一直是 Surge 3 的粉丝，但是他的定价已经吓退了我好几次。其实这篇文章就是为 Surge 准备的。Libfaketime 改变软件的运行时间。但是这个方法只适用于 Surge-2.5.1-528.zip 之前的版本，而现在 Surge 已经到 3 了。
这次修改的原理其实是一样的。
现在微信的月活大概为 11.1 亿，QQ 的月活大概为 7 亿。
在 2010 年，同时期比较有竞争力的产品有 微信，米聊，QQ，飞信；但是在 2012 年之后，最终留下来的只有微信。如果就事后诸葛亮，可以找出一万个理由来说微信的成功的理由。但是如果回到 2010，2011 年，思考一下以下问题会觉得十分有趣：
简单罗列一下产品经理入门数据仓库需要了解的名词，方便与 开发 或者 数据分析师 沟通交流。
数据仓库是决策支持系统（dss）和联机分析应用数据源的结构化数据环境。数据仓库研究和解决从数据库中获取信息的问题。数据仓库的特征在于面向主题、集成性、稳定性和时变性。
数据仓库一般是从用户实际需求出发，将不同平台的数据源按设定主题进行划分整合，与传统的面向事务的操作型数据库不同，具有较高的抽象性。面向主题的数据组织方式，就是在较高层次对分析对象数据的一个完整、统一并一致的描述，能完整及统一地刻画各个分析对象所涉及的有关企业的各项数据，以及数据之间的联系。
数据仓库中存储的数据大部分来源于传统的数据库，但并不是将原有数据简单的直接导入，而是需要进行预处理。这是因为事务型数据中的数据一般都是有噪声的、不完整的和数据形式不统一的。这些「脏数据」的直接导入将对在数据仓库基础上进行的数据挖掘造成混乱。「脏数据」在进入数据仓库之前必须经过抽取、清洗、转换才能生成从面向事务转而面向主题的数据集合。数据集成是数据仓库建设中最重要，也是最为复杂的一步。
数据仓库中的数据主要为决策者分析提供数据依据。决策依据的数据是不允许进行修改的。即数据保存到数据仓库后，用户仅能通过分析工具进行查询和分析，而不能修改。数据的更新升级主要都在数据集成环节完成，过期的数据将在数据仓库中直接筛除。
今天不知道写点什么，就来聊聊「数据中台」吧。
现在到处都在说中台，企业中台，技术中台，移动中台，研发中台，这个已经被用烂了的词，但是没有人告诉我到底什么是中台。
所谓「中台」，从字面意思上理解就是居于前台和后台之间的工作，引述一段美军作战阵型的演变来帮助大家理解中台：
美军在二战时，以军为单位作战；到了越战时，以营为单位作战；到了中东战斗的时候，以 7 人或者 11 人的极小班排去作战，这是今天最灵活的军事组织，也是核心竞争力和打击能力最强的一个组织。而美军之所以能灵活作战，敢放这么小的团队到前方，是因为有非常强的中台能力，这些能力包括战斗直升机、舰炮远程支援、战术导弹系统、战斗机支援体系等，这些能力能支持小团队快速做判断，并且引领整个炮火覆盖和定点清除。
中台不是具体系统，是一个技术架构，可以从以下几个方面理解：
数据指标作为业务和数据的结合，也是数据统计的基础，也是量化业务效果的依据。数据指标是数据仓库的根基，也是数据报表呈现的依赖。
数据仓库一般采用的建设方法是应用驱动，业务逻辑知识散落在各个 ETL 开发与 PD 的头脑中，缺乏整体上对源系统的一个全面了解。全面的数据调研工作对后续数据仓库模型中的设计具有非常重大的指导作用，在数据的取舍、数据整合策略、指标计算方法等方面都非常重要。
范式建模法其实是在构建数据模型常用的一个方法，该方法的主要由 Inmon 所提倡，主要解决关系型数据库得数据存储，利用的一种技术层面上的方法。目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。
一个符合第三范式的关系必须具有以下三个条件:
在自己写博客的时候有一些文章会同步到微信公众号，但是又不想重新编辑样式，所以我会直接用 markdown 的内容复制到微信里面。
目前，我在使用的是 MacDown，所以我自己定义了一套 MacDown 的样式来美化自己的博客。这个样式也是目前博客的样式。
3F3F3Fmargin: 20px 0 10px粗体ps. 在手机上字体的大小会降低 2px
当我还是初学者的时候，上司让我做一个新项目的需求调研。其实，我心里已经有了一个假设，我需求的调研的目的当然是在为我的产品找支持的依据。自然，最后的产品是我想要的，而不是用户想要的东西。
这是一个很奇怪的悖论，为什么不要关注用户想要的东西？产品的需求调研不就是为了满足用户的需求的吗？
因为在很多时候，用户根本不知道自己想要什么，不知道什么对自己是好的，自己应该做什么。
比如，一个小孩午饭的时候想吃糖，但是他的父母会去准备更健康的食物。
比如，一个准备减肥的人信誓旦旦的说自己明天不吃饭了，但是第二天说不定还会去吃两个汉堡包。
你需要理清楚真正的需求，比如健康的食物（虽然小孩子不喜欢），比如说明天不吃饭背后的逻辑。