精选技术长文、实践记录与系统化阅读
低噪声、高可扫读；标题、摘要、来源、标签一目了然。
采集自各技术站点的近期文章。
问题1 对于创业公司，尤其是需要外包前端的互联网公司，根据产品的迭代更新过程，产品经理如何提需求是会对前端设计的依赖是最少的。问题2 对于我这样的一个角色，(真心话是今天突然不知道自己算是干什么的，把自己搞糊涂了)，您觉得我在这样的一个位置上我的核心竞争力以及给产品能够创造的最大的价值/不可替代的价值在哪里。我不是计算机或者设计系的纯科班出身，目前在一个3个全职人员，10个非全职销售的互联网创业公司里面负责网站。 产品的流程和大方向是团队里一个co-founder负责，我算是向他不定期汇报，负责流程以及大方向被口头敲定之后的跟产品相关的一切。我们的整个开发团队都是contractors，创业团队重销售与推广胜过产品，这个是我们的business性质决定的。
客户有个需求，一张150多个字段的表，客户要求只将部分字段给扫描公司的人看，这个需求用视图就可以很容易实现，客户又要求，这些字段，扫描公司只可以修改其中的个别字段，我之前还真没遇到这样在列级别做权限控制的需求，做了个实验，感觉很有意思，记录下测试过程。
NAT是在传输层及以上做的，传输层最主要的2个协议是TCP和UDP。对于TCP和UDP而言，每个包都有很基本的4个要素：src ip、src port、dst ip、dst port。 根据在做NAT的时候是否保留src ip和src port，可以把NAT分为这么三种： Cone: 将src ip映射到一个固定的IP，并且将src port映射到一个固定的Port，无论dst ip和dst port是什么。 Single IP address, symmetric：将src ip映射到一个固定的IP，将src port映射到一个随机的port，但是保证对于相同的(dst ip,dst port), src port始终相同。（否则双方没法通话啊，回来的包回给哪个端口呢？） Multiple IP address, symmetric:与上面类似，但是src ip可能会有多个。
在oracle RAC中，每个实例均存在一个数据缓存池，每个block的改变都将实例间进行资源协调以获取最大化性能，从而保证数据的完整性。在RAC集群中，每个被缓存的数据copy，也叫做缓存资源，均存在一个叫做master节点的实例。在10.1.0.2中，一旦一个cache resource被master一个实例节点，对缓存资源的重新remaster或者说master节点的自动改变仅仅会发生在RAC实例节点的正常启停或者集群管理资源间的非正常问题发生。也就是说，如果NODE B是一个缓存资源的master节点，这个资源将被一直master到NODE B直到发生RAC节点的重新配置操作。
以下的文章发生在2008年，当时我还未到杭州，也未入职阿里巴巴，UCDChina开始传播，交互设计这个名词还未大面积传播，我当时不是交互设计师，也不是产品经理，也不是在大公司，而是在一家百人规模的软件公司，在一支做在线汉语教学的项目组里。彼时，刚刚从设计岗位转到承担产品策划一职(当时的称呼，或许相当于现在的产品经理？)，某个午后，新有所得，遂总结成文。当时我还未依赖于搜狐博客，而是发布在“忙吧”这个产品上，结果如今，“忙吧”已经不复存在，回顾多年，似乎当时很多创新性的产品都已经湮灭，幸而酷勤网当时不经允许转载本文，也没有被湮灭掉，所以无意中遇到，才又想起当年这篇长文。本人不经常转载文章，但是转载自己老文一篇，也算存档留念吧。
摘要：在国内外，云计算正在大步的走向商业化的道路，也得到了越来越多公司的重视。其中平台即服务（Platform-as-a-Service PaaS）已经称为业界探讨云计算的热点方式之一，采用PaaS模式来构建应用运行平台App Engine是一种重要的实现方式。本文主要是对App Engine的背景、特点、需求等进行分析整理，并据此对业界主要的App Engine进行了调研分析。最后对一个完善的App Engine进行了需求的细化分解、架构设计，并针对App Engine的部分核心技术问题提出了解决方案。关键字：App Engine、PaaS、SAE、Nginx、scribe、Hadoop、Storm、Ptail、Scribe 1综述 1.1背景在国内外，云计算正在大步的走向商业化的道路，也得到了越来越多公司的重视。
为了满足移动终端：节省流量、减少请求、提高客户端性能的需求，我们设计了webapp安装更新程序，把js、css、html和图片这些资源，序列化为字符串存入客户端本地存储，并带上版本号来实现资源细粒度更新。 TAG webapp 安装启动 性能优化 1、概述我们认为webapp是一站式的应用，在一个页面里能完成整站的功能。所以，以前通过页面全刷的跳转，现在变成了通过底层框架来支持的局刷和切换动画。为了支持这些功能，会多出不少的代码，再加上app里的功能代码，我们统称为资源，包括底层库js（zepto、iscroll、baiduTemplate等），通用ui组件和app功能性的js、css、html和图片。如何处理一个页面里的这么多资源，才能降低对性能的影响呢？为此，我们设计了webapp安装更新程序，可以做到减少资源请求，节省流量，提升客户端性能。
文档简介：贴吧在进行HTML5技术应用的过程中，进行了一系列的技术调研；本文对HTML5的技术调研进行总结，尽可能客观的分析解答对HTML5技术的一些疑问，给出产品、技术上的一些决策建议。对于文中的内容以及表述，也热切希望能得到大家进一步的指正和交流。 1. HTML5的发展现状及趋势 1.1 HTML5简介 HTML5是一套技术标准、规范，它定义了一系列的API编程接口和HTML规范（本文中将CSS3也默认涵盖到HTML5的技术范畴）；HTML5的运用和推广，需要依赖于各个浏览器厂商对HTML5的支持力度。
背景介绍 站点新功能或者是站内新策略开发完毕之后，在全流量上线之前要评估新功能或者新策略的优劣，常用的评估方法是A-B测试，做法是在全量中抽样出两份小流量，分别走新策略分支和旧策略分支，通过对比这两份流量下的各指标的差异，我们可以评估出新策略的优劣，进而决定新策略是否全流量。 上文中提到的抽样是指按照某种确定的随机化方法，对线上流量进行划分。抽样可以指这种划分的方法，也可以指划分得到的一个流量子集。抽样是一种特殊的小流量，要求对流量的划分必须保证均匀性和随机性，并且可以根据需求过滤掉不符合规范的部分，我们把抽样的过程分为流量切分和流量筛选两个步骤，流量切分是指把全流量进行均匀的打散，提取出其中固定的流量比例，流量筛选是对流量切分的辅助，筛选过程就是从切分好的流量中过滤掉不符合规范的部分，本文主要涉及的是流量切分的实现。
在电影《社交网络》的开始有这么一段，扎克博格由于被女友甩了，所以需要做一个网站，用来推选哈佛最漂亮的女生。网站的逻辑非常的简单，就是系统从照片库中随机挑出两幅女生照片，选择两者较“美”者。就是这么一个网站在上线两小时（周末凌晨两点到四点）内点击量达到了2万2千次，从而导致了哈佛网络的瘫痪。（备注：最近华中科技大学女生的照片也被类似的放到了网上评比，并且使用山寨的域名） 信息的关注应该注意到，上述功能中涉及到一个排名规则，是由扎克博格那位同学提供的，他把公式写在了窗户上，如下截图： 上面的公式主要作用作用是用来对进行女生的分数进行评比，从而确定哪些是最优质女生。不过让人遗憾的是电影中给出的这个公式是错误的公式，真正的公式应该如下： 即分数线下方是1+10的幂次，而非10的倍数。
StackOverflow的排序共分为两类，1个是问题排序，1个是答案排序。这里主要介绍的是关于热门问题的排序。 在分析问题前可以先考虑下，如果是你来做这个排名算法需要考虑哪些因素？ 1、问题的投票人数，StackOverflow允许用户投反对票，所以这里可以使用绝对投票数，即正面票-负面票数量。绝对数越高问题越热门。 2、问题浏览量，或是有效浏览量，有效浏览量可以建立一个停留时间的阀值去衡量。浏览的越多则越热门。 3、问题的答案数，理论上说答案越多则问题的越热门，但这也并不绝对，有些好的问答可能只有一个好的答案。 4、问题答案的认可数，即是否存在一个被大量认可的答案。这里存在两种情况，被提问者认可或被其他访问者投票。
策略开发人员在完成策略之后，在全流量上线之前要评估新的策略的优劣，常用的评估方法是A-B测试，做法是在全流量中抽样出两份小流量，分别走新策略分支和旧策略分支，通过对比这两份流量下的各指标的差异，我们可以评估出新策略的优劣，进而决定新策略是否全流量。我们把抽样的过程分为流量切分和流量筛选两个步骤。流量切分的逻辑较为复杂，包含多种切分类型和多层嵌套，另外为了保证灵活性，层的组合应该是任意的。
诸多事物都要受到其周边事物的影响，进而改变自身的形态，甚至确立自己的存在——云动，方知风的存在。反映在人的眼中，则是云赋予了风的含义：若无云，岂有风？ 0. 动机武林高手经常从山川之间顿悟，并由山川之形变化出上乘武艺。风云之间的飘渺互动，实则也为实打实的科学、工程实践提供了指引。风是客观存在的，而只有籍由云，我们才能观察到它。在技术领域的日常工作中，诸如此类的例子数不胜数。而在自然语言语义的研究中，先驱者们把这个道理总结成了一条假设——上下文假设[i]： “实体的含义，以及实体之间语法关系的含义和这些实体与其他实体之间组合方式的限制有关。”
检索结果聚类，可以有效地反映出特定Query下，检索结果内容的分布，可以清晰地描述出结果中的各个类别，对Query结果的展示方式亦不再是传统1页若干条结果的流式输送，而是采用展现核心词或代表词的方式，简明扼要地从不同维度提示核心信息，免去用户重新构造Query再搜索或在大量检索结果中寻找、定位所需内容的过程。
本文探讨了百度账号系统国际化过程中遇到的问题，并就资源分配和冲突解决、数据互通中间件提出了解决方案，在可用性和数据一致性方面采取有效折中。该方案已经上线并长时间稳定运行。
id分配是社区类产品的提交环节中必不可少的一步。任何UGC类内容产生时往往需要分配一个对应的id。 id分配的几种方式 方式一：单点自增分配。全局由一个模块来负责生成id，可保证id从0开始连续递增，数据一般放在本地文件。简洁，但致命的问题是单点故障会导致服务整体不可用。方式一改进：为该模块提供主从复制的能力，或者干脆将数据放在mysql里，利用mysql的主从复制，都一定程度上增强了可用性，减轻了单点故障的影响。方式二：随机/散列分配。通过一些hash算法，比如以时间+随机串为key的md5生成一个唯一的id，关键点在于算法和key的选择要避免冲突。最典型的就是UUID，UUID的标准型式包含32个16进位数字，以连字号分为五段，形式为8-4-4-4-12的32个字符，如550e8400-e29b-41d4-a716-446655440000。
随着SMP(Symmetrical Multi-Processing)架构的流行和epoll类系统调用对非阻塞fd监视的支持，高性能服务器端的开发已经能够实现CPU计算和IO的分离。为了充分发挥CPU的计算能力，服务器端的设计必须要尽量减少线程切换。引起线程切换最重要的原因之一就是对mutex和semaphor等锁的使用。本文从计算机体系架构、操作系统的支持和mutex的实现彻底分析Linux用户空间mutex的实现，分析的源码版本是glib-2.3.4和kernel-2.6.8。
关于Transfer MySQL-Transefer(下称Transfer)是一个基于MySQL+patch后得到的主从同步工具。 其主要目的是为了解决原生版本的主从同步里，从库是单线程apply主库的binlog，导致的延迟。
在最近使用新浪微博android sdk开发微博登录的时候，从日志中发现一个问题，就是自定义的WeiboDialogListener里面的方法，比如onComplete或者onCancel等，经常会被两次调用，这样其实会导致一些隐性问题，比如增加额外的客户端和服务端的开销，因为我们通常会在onComplete()里面完成更多后续逻辑的处理，而发生这样的情况时，会被处理两次，一开始我犯懒，就在方法外面加入了一个变量 isCompleted 来进行判断，算是暂时解决了问题，后来在好几个地方要开发类似功能的时候，总感觉心里有点儿不爽，于是决定找找到底啥原因
web站点服务中，我们除了存在面向用户的服务功能外，往往也存在大量的后台离线的相关计算任务，如对前端的异步操作数据队列进行定期处理，对数据库中的数据进行汇总挖掘，监控，转储，对中间数据的进一步运算处理等等……一个web服务站点的背后，往往存在大量对应的后端处理任务的功能模块，用于支撑正常的业务功能系统。 在一个web站点的初始阶段，我们可能只需要有一台服务器，容纳部署所有的业务功能，包括了面向用户的前端web服务功能，数据存储，后端离线处理业务功能。随着站点的业务功能越来越多，用户访问数的增加以及数据量的增长，单台服务器的处理能力往往就面临瓶颈。这个时候简单的处理就是将前端web服务功能，数据库和后端业务模块分开部署在不同的机器上，但是可能过随着站点规模的逐渐庞大，单个服务器也无法支撑前端web服务，数据库服务或者后端离线业务功能。
