AlexiaChen.github.io

AlexiaChen.github.io copied to clipboard

--- title: 软件的未来 date: 2016-08-05 13:55:27 tags: - 软件工程 --- # 开源 开源社区，开源软件的发展大大减少的程序员的劳动力，降低了生产门槛。随着这几年开源运动的发展，GitHub,StackOverflow的出现，以及各大厂商拥抱开源以后，软件开发变成了软件的组装，开源组件（系统）降低了软件的研发成本，让超小的研发团队就能控制超大的系统软件。也正是因为这样，才像雨后春笋一般催生了各种互联网的创业中小型公司。 # 软件开发模型 软件的开发变得无比敏捷，从以前的瀑布模型到现在的增量式迭代开发，持续集成，持续交付，容器微服务等这些工程实践，让软件的发布速率提高了几个数量级。 # 数据 数据的地位慢慢超过了算法，因果关系变得不再重要，智能硬件机器的大规模普及产生了很多数据，从大数据中挖掘出相关性就可以分析出无法估量的潜在价值。10年前Google的GFS,MapReduce,BigTable这三篇论文打开了大数据的大门，而现在Hadoop，Apache Spark是互联网数据分析的标配，大量的数据也催生了刚开始快速发展的机器学习和深度学习。 # 云计算 云计算的普及，资源的虚拟化让无数创业公司形成了可能，进一步降低了运营成本。软件的架构变化从单机逐渐转向到了多机的分布式集群。 # Web 随着V8引擎的出现，javascript性能的大幅度提升，软件不再是Native App，而是Web App或是Hybird。Web应用越来越移动化。Html5 CSS3的发展使得Web页面更加细腻丰富，带来了响应式网页的概念,同时更好的适配多种设备。 #...

AlexiaChen

--- title: 一次结对编程的亲身体验 date: 2017-10-14 10:30:46 tags: - 敏捷开发 - 职业生涯 --- > *思绪来得也快去得也快。* -- *云风* ## 前言 [结对编程](https://en.wikipedia.org/wiki/Pair_programming)是敏捷软件开发中提出的一种实践和概念，意思就是两个程序员坐在一台电脑前一起编写代码，其中一个主要编写代码，另一个主要负责代码的review，提出自己的疑问和自己的见解。 ## 一次亲身体验 在故事开始之前需要说点必要的题外话，项目组增加了人手，除了我以外增加了2个同事。客户端的GUI框架选择了Qt，新来的两个同事虽然已工作多年，比较有经验，但是他们两个目前暂时都对这个Qt框架没我熟悉和有经验。 昨天是周五，面临着项目又一次功能的迭代，一周的目标的收尾结束。所以我自己也比较忙，花了一早上把分配给自己的任务给搞定了。 由于我们项目的客户端新的选择的是[Qt](https://en.wikipedia.org/wiki/Qt_(software))来开发的GUI界面，Qt带来一定的复杂性在对此不熟悉的同事直接上手介入项目的开发带来了一定困难，这个功能模块的任务原本是分配给一个刚学习Qt几天的同事来做的，但是由于项目进度的推进关系，必须又要在这周五有个收尾和结果，所以为了不影响进度又因为任务最开始是分配给他的，所以我提出了让那个同事一起过来跟我坐一个工位上一起实践结对编程。 就这样，主要由我来编写GUI界面和功能逻辑的代码，而他坐在旁边根据自己的思路提出疑问和见解，任务的目标功能很快就完成了，期间只用了2个多小时，比我预想得要快，而且代码的质量也比预想的要高，如果这个功能我自己一个人做的话，虽然也花不了多少时间，顶多3小时，但是这次的经历使我对结对编程产生了新的看法，两个人一起工作的效率竟然不低，反而可能经过多次这样的实践工作效率大大提高，代码质量也提高了。以前我对于结对编程的了解也仅仅限于各类软件开发的书本，比如[《代码大全》](https://book.douban.com/subject/1477390/)。但这次却是让我真正感受到了效率。以下我就详细说说带来了哪方面的效率。 - 有利于知识经验的分享和传递，特别适合于帮助主要负责Review的同事快速熟悉自己所不熟悉的领域(框架，库，业务逻辑等)。 - 有效控制代码质量和风险，经过互相讨论的代码实现往往比自己独自决定的考虑更加全面。在一个人的注视下，反而不好意思写烂代码了，因为要边写代码边讲解自己的实现思路，同时负责Review的同事也会积极反馈你的代码逻辑，在这样的情况下，更容易编写可读性高的代码。 -...

AlexiaChen

--- title: 不要看不起手工拖控件画UI date: 2013-07-18 19:56:00 tags: - 软件工程 --- 相比手动代码+脑内模想完成ui的方式，拖控件没什么不好 - 拖控件的过程实质是在约束环境中填补某框架数据。同一水平的生产者（新增bug的概率一致），基于成熟框架之上二次开发（拖控件），相比“手工垒代码方式”，其新增bug的概率只会减不会增。从而： - 可间接提升模块质量 - 模块质量要求不变时，可降低从业者门槛，以至于招人方便点，且可恰如其分的使用雇员能力 - 拖控件只涉及UI，不会导致所谓的“应用技术层次下降”，换句话说： - 一个能靠拖控件弄出完全一致界面的应用，其界面部分的技术层次本就不能算高 - 界面如何完成，与应用内部其他部分的实现难度无关。即便界面使用拖控件方式完成，高难度的应用仍具有高难度 - 约束的开发环境，容易成为高开发效率的整体开发模型的一部分，从而在整体实施这套模型后，提升开发效率 - 拖控件方式便于完成原型，不需要花不必要的功夫在代码上 PS：上述内容暗示，拖控件的方式是有利于软件开发工业化的，不针对自己捣鼓的东西，那些东西爱怎么弄怎么弄。

AlexiaChen

--- title: 逻辑判断 date: 2014-06-27 11:34:36 tags: - 逻辑 --- >*本人非原始作者，原作者是一个网名为mingda1986的清华物理系毕业生，现在在MIT读PhD，想必已经PhD毕业了* 在对一件事下定论时，我们离不开推理论证，这需要真实客观的信息，合理的逻辑推理，有时外加人性的考量。然而，目前的教育方式以及社会环境，在这方面比较欠缺，甚至有意误导，常让人获得错误的结论。信息了解不全面，影响判断；因果推理不正确，对无关事物强加因果，或者只是敷衍地给出站不住脚的理由；再或者把谎话重复一千遍，听多了就像是真理。不知不觉的，就在方方面面的损害了人的判断力。 本文旨在提供一点线索，减少垃圾信息的侵害，用理性和良知武装自己的大脑。本文仅能管中窥豹，望读者举一反三。 常见破坏逻辑的方式如上所提，即信息不客观，逻辑不合理，或者不考虑人性。 一、**不客观的信息**： 对于无法辩驳的事实，选择性隐瞒 一个更好的做法是，你有权利了解发生过的事实，并且可以看到不同的评价，然后自己去做判断。 二、**错误推理**： 强行绑定事物，使之发生因果关系 这种破坏逻辑的方式比第一种更加隐蔽；因为第一种方式里，只要知道足够客观的事实，偏颇的观点自然攻破。然而，有很多事物之间存在关联，但并非因果关系。因此，稍有疏忽，就会相信了这些本来没有因果关系。如果教育过程中，强行让本来不属于直接推出关系的两件事， 对大脑的逻辑能力非常有害。 因果关系是说，假设A是前因，B是后果，那么它们之间至少有如下特征： - 它们协变。即A的变化引起B朝着某个方向的变化，具有相关性。 - A发生早于B。即符合相对论，信号传递速度有限。 - A与B不是伪关系。所谓伪关系，即A与B表观上有相关性，其实它们都由与其他因素左右才显得相关，而不是因果性。 前两者比较容易理解，常见的逻辑混乱出在第3点上，即把仅有相关性事物（如，时间/空间相关）说成是因果性。 三、**不考量人性**：...

AlexiaChen

--- title: 数据压缩的基本常识 date: 2014-03-05 11:41:52 tags: - 数据压缩 --- 首先解释一个原理：就无损压缩来说，如果一个算法能压缩一个文件，就必然存在另一个文件是压缩之后比原文件还要大的，这个原理还想不通的话可以参考抽屉原理。 于是，设计一个压缩算法，首先就要考虑什么文件是能压缩的，什么文件是不能压缩的。对通用压缩算法来说，我们通常只会做一个基本的假设：在文件中如果出现了一个串Sx，那么其它地方出现Sx的概率相对会比别的串概率要高。 就目前来说，ZIP/RAR这一类算法都是基于这个原理，所以它们也无一例外不能压缩完全随机生成的文件。 于是给出两个命题： - 如果你设计的一个压缩算法不是出于对重复串的建模，那么它基本不可能成为通用的压缩算法。 - 如果你设计的算法〔能压缩任何文件〕，那么一定不存在有效的解压算法。

AlexiaChen

--- title: 有关于修BUG的一个思考 date: 2016-08-26 10:14:16 tags: - 软件调试 --- 主要是在知乎看到龚敏敏大神的一篇[文章](https://zhuanlan.zhihu.com/p/22182269)才引发的思考。文章的评论中有个回复比较有意思： > *[clang](http://clang.llvm.org/)里有个bug，在windows平台上编译出来的dll，类的导出函数都多了个下划线前缀，从2011年开始被喷了4年，无效。ms一push，3天就修好了。（然而那个补丁超级邪恶。检测到下划线就去掉，而不是找到为什么会多一个下划线）* 以上的回复我有一些删改。 对此我引发的一些思考是，对于大型的复杂精密的系统软件的BUG修复问题：修BUG是找到出现BUG的本质原因，还是可以在适当的情形下考虑从其他角度规避造成BUG这个现象就可以了？简单来说，就是只要让该现象不出现就可以了。 如果是正常情况下，在我们的工作中这样修复BUG是万万不行的，因为这只是隐藏问题，而不是解决问题，这是一种不负责任的做法。我相信只要是一个负责任的工程师都不会这样做。 但从以上微软修复BUG的例子来看，工程师们选择的是后者。因为编译器是一个很精密复杂的工程，在没经过严格的单元测试下不会发布，所以测试编译器的正确性也是含金量很高的活。对于这种精密复杂的系统修改它的BUG就不是那么容易的，而且又在极其有限的时间内修复，那么就难上加难了，因为很容易牵一发而动全身，一旦出现一些诡异难缠的BUG，即使是经验丰富的工程师短时间内很难找到问题症结所在。 最后，我对这种方式的修BUG行为做个总结，如果要以这种方式解决问题，那么你应该明确评估以下几点 - 衡量修复BUG的复杂度，真正修复它需要多长时间，技术难度大不大，是否紧急 - 评估出现该BUG的模块对于整个项目的重要程度，如果短期不修复，会对用户造成多大影响 - 是否存在朴素笨拙的办法规避BUG现象，如果存在，那么可以。（当然，对于我的工程经验来说，有些时候用笨办法解决问题非常符合实际） 最最后，真的是最后了 = =！ 分享一个我平时Debug的方式： - 程序业务逻辑采用日志系统输出打印，出现这类的BUG，往往可以通过log就能定位了...

AlexiaChen

--- title: 互联网显然颠覆不了传统行业 date: 2016-02-28 08:52:10 tags: - 互联网 --- >*知乎上由于程序员居多，互联网火热，被一些小白搞得乌烟瘴气，个别还高喊着互联网颠覆传统行业，把程序员这职业吹上了天，听起来像是那么一回事，不过估计都初入行业的菜鸟，跟国内小编吹牛一个样* 尽管现在编程越来越日常化，各行各业的技术人员都可能接触编程，但是这并不代表互联网介入并颠覆了它。在传统工业中，显然程序员是种被边缘化的职业，虽然很多重要技术职业需要编写代码，比如自动化控制出身的，需要编写各种控制算法，PID算法等，但是这些人可不自称程序员。计算机科学与自动控制是两码事，两种相差很大的领域，自动化毕业的优秀学生，能进宝马，轮船，电网负载等行业部门，也就是说自动化工程师比程序员分布在更广泛的领域，天上飞的，水里游的，马路上跑的，工厂里动的，你身处周围的绝大部分现代化设备里面都需要算法，包括特斯拉和火箭回收，一个简单的事实，用到这些算法都不是计算机专业学的，计算机专业也不开相关课程，专业都不在一个院，生产他们和写这些主要算法的人都叫xx工程师，但我们一般不叫他们程序员。例如，机械工程师会运用lisp语言作为cad的dsl辅助，但没人管他们叫程序员，他们都不是会像cs专业的程序员一样写代码，在任何国家行业分类上他们是100％的传统行业。如果以后不深入一个领域的知识技能，是不能立足的，互联网这种，都不叫啥领域，反而太泛泛了。一个程序员，会写几段代码，写了几段轮船，电网负载预测，航空遥感，车载系统的代码就敢说这个领域的？你难道没感觉出来你的代码实现和业务需求都是该领域的专家跟你描述指导的么？是不是互联网现在太火了，工资虚高，导致一些互联网程序员有些目中无人的样子，呵呵，去个电网公司写点代码，就敢说颠覆该领域，你开玩笑吧？请问你取代颠覆哪个部门了，你抢了那些领域人才的饭碗了？你真懂这些领域？电力专业的课程有这些，基础课不谈，电磁场与电磁波学三个学期，automatic control两个学期，power supply systems 1, optimization and operation of electricity and gas， components and devices of electicity supply， electrical...

AlexiaChen

--- title: 多核编程的相关理论及实践 date: 2018-04-13 12:01:23 tags: - 多线程编程 - 多核编程 --- > *这篇文章主要是看brpc的文档的心得体会吧，brpc算是国内高性能RPC框架中文档写得最好，最有诚意的作品了。就算不看它的源码，看它的文档也能收获很大，干货满满，在这过程中也解答了我以前的困惑。* ## 前言 在开篇之前，我想说点文体风格，由于阅读[brpc](https://github.com/brpc/brpc)的文档给了我巨大的收获，所以文体的风格会以问答的方式展开。顺便给出原理解释，还有感受下[戈君大神](https://www.linkedin.com/in/gejun)在文档中浸淫多年的软件基础设施工程实践心得体会。我文字理解驾驭不了的地方会选择性地摘抄文档内容。 ## 正文 ### 1. 如何针对写多读少的场景设计一个多线程计数器？ 大部分RPC框架，或者其他中间件或多或少都需要有这样的需求，因为这些中间件基本都是主打高性能的，高效利用多核多线程。既然是高性能，都需要为它设计计数器，目的是为了方 便统计各种服务的调用次数，还有其他性能参数（QPS,平均延时），以达到监控服务，调优服务的最终目的。 本着最直观的理解，写下了如下最简单的计数器代码: ``` cpp int global_count =...

AlexiaChen

防止数据被恢复的可能

1

--- title: 防止数据被恢复的可能 date: 2016-09-02 18:17:39 tags: - 信息安全 - 数据恢复 --- 平时大家有没有好奇过，为什么硬盘上被删除的数据有时候还能被还原恢复呢？其中的原理是什么呢？ 其实，如果操作系统学得不错的人应该知道，数据文件被删除只是操作系统把文件从文件系统中删除，也就是文件在文件系统中的索引（地址）被删除，意思就是，操作系统告诉文件系统：Hey，哥们儿，我不需要这个文件了，你把这文件从检索索引中删除吧，我不再需要了。其实真实的文件数据还会真实存在物理硬盘上，没有真正被消除，除非有新的文件数据被保存并恰好覆盖了之前的文件数据。数据恢复就是依赖这个原理工作的。 那么如何防止数据被恢复的可能呢？其实如果脑袋聪明的人一下子就能想到，我往原文件里面大量反复写入Dirty Data来覆盖之前的数据不就可以了么？答对，就是这个思路。其实现今无论多么先进的数据销毁软件都是基于这么个思路（甚至美国中央情报局销毁绝密数据也是这么干的）。只不过越要降低被恢复的可能性写入的次数随之增加，所以耗费的时间也越多。 垃圾数据只写入一次还不够，需要多次覆盖，这是因为，直观上理解，一次写入后，磁盘上的数据就变化了。其实在硬件层面，不是这样的，还是能够恢复的。恢复的技术有下面两种： - 第一种是：当硬盘读写头在硬盘上写入一位数据时，它使用的信号强度只是用来写入一位数据，并不会影响到相邻位的数据。由于这个写入信号并不是很强，因此你可以通过它写入的数据位的绝对信号强度来判断此前该数据位所保存的是何种数据。换句话说，如果二进制数据0被二进制数据1所覆盖，其信号强度会比二进制数据1被覆盖要弱一些。使用专门的硬件就可以检测出准确的信号强度。把被覆盖区域读出的信号减去所覆盖数据的标准信号强度，就能获得原先数据的一个副本。更令人吃惊的是，这一恢复过程可以被重复7次。因此如果想避免别人使用这种方法来窃取你的数据，至少要覆盖该数据区域7次，而且每次还应该使用不同的随机数据。 - 第二种数据恢复技术则是利用了硬盘读写头的另一个特点：读写头每次进行写操作的位置并不一定对得十分精确。这就能让专家们在磁道的边缘侦测到原有的数据（也被称为影子数据）。只有重复地覆写数据才能消除这些磁道边缘的影子数据。由于硬件的这种特性，在销毁文件的时候，才会需要多次覆盖。 所以根据以上的特性，才有了许多数据擦除算法的诞生，覆盖次数越多，随机垃圾数据越“随机”，被恢复的可能性也就越低，安全性也就越高。到了[Gutman method](https://en.wikipedia.org/wiki/Gutmann_method)这样的级别，理论上已经证明了，经过此算法处理过的数据，没可能恢复。 但是，弱点就是速度很慢，如果需要有大量机密数据要被销毁，这将是耗时的任务。 我写过一个[数据擦除的库](https://github.com/AlexiaChen/DataBlackHole)，等级最高也就是支持到Gutman这个级别。其中[DOD5220_22M](https://ia.signal.army.mil/docs/DOD5220_22M/522022m.htm)算法是之前美国中央情报局采用的，不过现在被抛弃了，我猜测原因就是速度和安全性的权衡。至于他们为什么没有采用Gutman算法，其实也是速度和安全性的权衡，因为太慢了:) 这告诉我们，评价衡量一个工具需要综合考量。

AlexiaChen

- 很多人都是对大脑运转原理理解不够，他们畏惧未知世界的力量，一直把眼光困在狭小而黑暗的世界里，等他们走出那个世界突然觉得也没什么。 - 在黑暗中焦虑地摸索的年月，满怀着强烈的渴望，有过信心，也有过动摇和疲惫，但最后终于看见了光明。

AlexiaChen