精选技术长文、实践记录与系统化阅读
低噪声、高可扫读；标题、摘要、来源、标签一目了然。
采集自各技术站点的近期文章。
目前infobright应用越来越多了，有些场景下需要和台管理系统共用，因此需要同时存在brighthouse和myisam两种引擎。这时候，如果需要brighthouse引擎支持utf8字符集，需要： 1. 数据库对象创建时务必使用utf8字符集，这点尤为关键，否则不可支持utf8； 2. 数据表对象创建时也使用utf8字符集； 3. 导入文件提前转换成utf8字符集； 4. 连接infobright时，执行set names utf8； 5. 导入文件，查看字符集是否正确；另一种场景下，可能myisam表也需要支持utf8，这个相对比较麻烦： 1. 数据库对象创建时无所谓，不强制必须是utf8； 2. 数据表对象创建时务必使用utf8字符集； 3. 将导入文件全部转换成utf8字符集的INSERT语法，直接写入数据，infobrig
最近集中面试人，也有了一些心得。首先是明确面试的目的，面试是希望招聘到合格的工程师，而不是难为别人或者炫耀技能，因此犄角旮旯的知识，高难度的数据结构就不必要拿出来炫耀了。其次确定问什么，大家都不是搞基本计算机理论研究的，而公司中特有的东西也没有办法拿出来问。其实可以深入问的有两个方面： 1.领域基本概念 虽然是最基本的概念，但事实证明，少有应聘者可以给出深入和正确的回答。所谓深入，达到百度百科的标准就OK了。对于领域基本概念有清晰了解可以体现出面试者的敬业，也可以反映出面试者对于技术的渴望和好奇心。这类员工往往可以有潜力培养成为骨干。 2.面试者的工作领域 如果一个面试者在一个项目工作了2，3年，则期望他对于相关知识有深入的了解是合理的，否则不要混了。
晚上花了两个小时给丰兄和花花展示一次如何写代码，从第一个字符开始，用199行代码完成付费的如下功能： 权责发生制的记帐 置顶的产生和显示逻辑 类目置顶，筛选置顶，全省置顶，全国置顶，区县置顶 部分订单取消 置顶竞价，端口竞价 送天数逻辑，买100送20块这样真钱假钱逻辑 很累。 结论和大家分享： 1. 会代码不等于会逻辑 代码只是一种语言，一种更加精确的语言。会写代码仅仅是会写代码。一个汉语讲不明白话的人用英语也不见得讲明白。一个海明威要是学会了意大利语，估计小说也写得不错。代码仅仅是表达。一个代码写不明白的人，事情一定想不明白。事情想明白的人，就差一点点培训，就能写好的代码。 2. 边界 我们已经在停止学习了。停止学习是创业公司的死亡之日，也几乎是一个人的死亡之日。业务人员为什么不能看代码？我拉丰兄和花花（你没看错）来看代码，而且是看我一个字一个字敲出来，就是用一种残酷的方式打破大家对代
老婆单位有时候有一些很大的 Excel 统计报表需要处理，其中最恶心的是跨表的 JOIN 查询。他们通常采取的做法是，把多个 Excel 工作簿合成一个工作簿的多个表格，然后再跑函数(VLOOKUP之类)去查。因为用的函数效率很低，在 CPU 打满的情况下还要跑几个小时。 然后我就看不过去了，我也不懂 Excel，不知道如何优化，但我想用 Python+SQLite 总归是能够实现的。于是就尝试了一把，效果还不错，一分钟以内完成统计很轻松，其中大部分时间主要花在读 Excel 内容上。
用JavaScript写程序，通常要经历两个阶段：第一个阶段是采用一些模块来擦除JavaScript语言(跨平台)自身的问题；第二个阶段是自己写一些方法来擦除引入的模块的问题。第三个阶段才会真正进入业务开发中，前两个阶段俗称“擦屁股”。时常在第三个阶段时，我会陷回到第二个阶段，和各种模块碰撞，往往会引起一些心情上的不舒爽。而在接触到moment时，这些烦恼瞬间消散，我在心底知道为何会如此释怀，如碰到心仪的女神。这也让我回头反思过去在使用和写模块过程中遇到的挫折和收获，这落差让我产生了如此的冲动，此文算是一个总结，期望能在汲取优秀模块的经验中，国内开源社区能够成长起来。
最近看到一则颇为有趣的新闻，说北大一名大一新生，以素数为标准选手机号，受到广大网友膜拜。其实素数的检测算法是很有趣的，并且会涉及到数论、概率算法等诸多内容，一直觉得素数探测算法是了解概率算法很好的入口。本文和大家简单聊聊如何确定一个数是素数。
MySQL MongoDB SQL 对应
Innodb Plugin引擎开始引入多种格式的行存储机制，目前支持：Antelope、Barracuda两种。其中Barracuda兼容Antelope格式。另外，Innodb plugin还支持行数据压缩特性，不过前提是采用Barracuda行存储格式。表空间启用压缩的前提是innodb表空间文件存储格式修改成：Barracuda，需要修改2个选项： innodb_file_format = "Barracuda" innodb_file_format_max = "Barracuda"
响应性开发的概念不做细述，一年前曾做过一次分享”聊聊响应性设计和开发“。 仅仅利用media query适配样式是远远不够的，并没有考虑触屏下的行为和特有的内容组织方式的不同。简单在桌面版基础上叠加mobile版的代码，会带来请求增多、流量、性能、代码冗余等诸多方面问题。 这次从以下几个方面着手，充分发挥“响应”的灵活性，目标是得到一个更“好用”的体验。
在命令式编程中，我们解决一些问题往往可以使用循环来代替递归，这样便不会因为数据规模造成堆栈溢出。但是在函数式编程中，要实现“循环”的唯一方法便是“递归”，因此尾递归和CPS对于函数式编程的意义非常重大。了解尾递归，对于编程思维也有很大帮助，因此大家不妨多加思考和练习，让这样的方式为自己所用。
以前我也在博客上简单谈过“尾递归”及其优化方式方面的话题。前几天有同学在写邮件向我提问，说是否所有的递归算法都能改写为尾递归，改写成尾递归之后，是否在时间和空间复杂度方面都能有所提高？他以斐波那契数列为例，似乎的确是这样的情况。我当时的回答有些简单，后来细想之后似乎感觉有点问题，而在仔细操作之后发现事情并没有理论上那么简单，因此还是计划写篇文章来讨论下这方面的问题。 斐波那契数列 大家对于斐波那契数列(Fibonacci)的认识一定十分统一，唯一的区别可能仅在于n是从0开始还是从1开始算起。
Service 调用注册服务和接口时只通过Broker Master节点， Master将注册的服务和接口信息同步给所有的Slave节点，而所有的Service 接口和Client 节点和Slave 都是有连接的，所以不同的Service 就实现了通过不同的Slave 完成消息转发，实现了负载均衡。而且消息转发的开销和原来单个Broker的开销完全相同。
Visit这个度量是网站分析的基石。但即使是这样基本的一个度量，Google Analytics对它的定义其实都不是完全一成不变的。为了适应新的浏览器变化和人们访问网站习惯的变化，Google Analytics在基本度量上甚至都在不断进化。哦，这或许也是Google Analytics的可怕之处，她已经达到了这样的高度，还比别人爬的快。在本文中，你将学到什么： GA定义visit的重大改变；特殊情况下GA如何处理visit的定义； Visit关联属性的变化（过去和现在）；为什么大部分页面的visit会远小于这些页面的访问者（visitor）数量。
最忌在做ORACLE到MYSQL得迁移，以下我写了三个简单的MYSQL里面米有的函数。 供大家参考。
在普林斯顿大学和伯克利的加州大学，两位研究人员试图在为什么有些编程语言能走进它们的黄金时代而众多余下的却不能的原因上贡献出自己的智慧。在一个他们自称为“业余研究”里，Leo Meyerovich 和 Ari Rabkin 调查了数万个程序员，梳理了流行的代码库SourceForge上超过30万个项目——所有的这些努力都是为了能清楚为什么老的编程语言仍然处于霸权地位。
用户体验研究过程中，我们经常需要使用前端脚本采集用户访问行为相关的数据，例如监听鼠标的点击事件，记下点击的位置及被点击的元素等。一个不可避免问题是，何时将采集到的数据发送到服务器呢？最直接的方案是每次收集到数据后立即发送，但这可能会带来较多的HTTP请求，一方面降低页面的性能，另一方面也增加了打点服务器的压力。另一个方案是先将收集的数据缓存一下，然后按一定规则发送（比如每收集满10条数据发一次，或者每隔5秒钟发一次），其中最终极的方案是所有的数据都缓存起来直到离开页面之前（beforeunload事件触发时）再发送。不过这个终极方案也有自己的问题，比如beforeunload这个事件可靠吗？在这个事件中发送打点的丢失率有多少？近期我们就这些问题做了一个研究，对这个丢失率也有了一个更具体的认识。
今天我在网上发现一张图片，标题是“当程序出问题时程序员最喜欢说的20句话”，也是非常的有趣，程序员的一些坏毛病都快成了经典漫画形象了。
最近一直在想，我能够做什么，怎样才能发挥自己最大的价值。 最近也一直在对比，开发的价值，产品的价值，团队的价值，我的价值。 一直以来的开发经验，一直让自己看不起产品这份工作。 今天看着一片一片死在自己塔防下面的小妖，突然顿悟了。 如果把开发比做小妖 ， 3个开发，就是这样一个冲刺的小团队： 如果我作为一个开发，加入其中，那就是4个小妖。
rman backup 对于truncate和drop等相关操作的extent到底是怎么处理的,这里通过rman backup 结合odu证明出来,在较新版本的rman中,rman backup 并未完全的备份这些被认为不需要的extent. 创建模拟环境 rman备份no truncate table 数据文件 truncate table 操作 rman备份truncate table 数据文件 odu挖rman备份前数据文件 使用rman 备份后数据文件 odu挖rman还原后数据文件 通过odu挖rman备份前和备份后的数据文件,得知rman backup备份的过程,对绝大多数truncate的表的原始数据未正常备份(为什么是绝大多数,我无法给出解释),这里也可以看出rman backup并非是真正意义上的完全物理上复制(和rman copy还是有区别,copy不能完全被取代)
时下可能用户最多的贡献内容区域就是微博了，这是用户的言论维度。最多的内容获取区域，不太好说，几个大门户都有着自己的地盘，姑且认为用户的阅读维度在门后吧。最明显的兴趣维度，其实是在搜索引擎，缺少兴趣你就不太可能在那个框里输入什么关键词。最后一个：消费维度，基本掌握在几个大型电子商务手里。从言论到阅读到兴趣到消费，这四大维度散落在不同的公司里，事实上我们的确可以承认将这些数据拼起来，可以得到相对最完整的人的维度，但很难想像他们会在数据层面进行合作。人的阅读和消费有没有关系？当然有，中间的关系是什么？那就不是那么容易获得了。算法建模倒是其次，数据采集就是个大难题。
