你想做偏技术的项目呢?还是偏业务的项目?

最近和某人聊天,谈论一些工作上的环境等等。谈话中让我想起来以前的主管问过我的一个问题:你想做偏技术的项目呢?还是偏业务的项目?这种问题估计在程序员的面谈中并不少见,而且有变体,比如问你之后想做什么类型的项目等等。对于很多偏技术的程序员,比如喜欢看技术类杂志,参与技术类活动,甚至无时不刻不在学习最新技术的人来说,选择偏技术向的项目更多一些。按照自己的兴趣正面回答这个问题固然很好,但是有些时候需要审视一下这个问题的背后主管的意图。

猜测主管的想法并不是说主管对你有猜忌,只是像做题时理解出题者的出发点一样分析一下主管为什么会这么问,期望得到什么样的答案。从主管角度来说,他除了要完成自己的任务之外,理论上还需要引导自己的下属。具体可能是帮你解决一些问题,辅导你工作上的成长,甚至推荐你升职等等。而从公司层面来说,一个能解决问题的员工比一个不能解决问题,或者花了更长时间解决问题的员工更好。更现实一点,一个代码平平或者还相对差的人比一个代码比他好甚至高一个等级却花了几个星期解决一个中小问题的人更受欢迎。这是一个比较残酷的公司潜规则。比较常见的是,你在某个需求中为了让某个功能更通用自己造了某个小的框架,但是开发时间比其他人要长。代码质量上你确实比其他人高,甚至bug也相对其他人少,只是很少有人会在有代码问题时问你问题,组外的人也不理解你的代码能力,主管面谈时甚至被”虽然你写的代码在组内相对不错“等评价,过了一段时间之后你就会觉得苦恼,对这样一种不被认可的环境所困扰。

对于本应在程序方面最拿手的程序员来说,参与各种项目,解决掉负责的需求,通过自己的技术给公司带来价值,公司给予相应的薪酬,还有阶段性的升职。但是现实情况是,你所看到的公司代码很多都是一种被同化的平淡无奇的有时候违背最佳实践的代码,偶尔会有一些可能会造成性能,安全问题的代码会被CR出来改掉,而你所做的优化,改进,框架等并没有受到主管或者其他人进一步的期待,特别是他们自己对于代码要求不高的时候。负责任的主管可能会适当的时候与你交流下代码的关注度问题,引导你关注一下其他方面。比如系统发展,业务前景等等。如果你在让项目顺利进行上还有所欠缺的话,可能还会要求加强那些方面。此时的主管如果问你这个问题,主管会综合你的回答和你的现状来进一步阐述他的一些想法,换句话说,面谈时候的这个问题,你的答案并不重要,特别是在半年评价的时候。

大部分项目,都是有具体的业务需求,配合代码上的修改来实现的,少部分升级安全,性能等自发的技术型项目。后者在基础开发组比较多,但是偏基础的组肯定不会问让你在业务和技术中选择的问题。所以大部分时候,你要明白,公司层面期望的是越快越好地完成项目,并不关注你的代码。理解这一点,之后很多事情就可以轻松一些了。

网络编程中的半包粘包问题

本文主要是讨论一下网络编程的基础,组包解包,以及常见的半包粘包。

在开发网络应用程序的话,特别是偏底层涉及具体的应用协议的时候,你可能会碰到服务端得到的数据不完全的问题。比如说客户端发送了1024个字符,但是你先得到了其中512字节,剩下的数据之后才送到。而已这通常发生在TCP协议下。理论上来说,TCP相对于另一种协议UDP,保证不会丢包,丢了也会重传,而且包的顺序是可预测的,但是对于传输的包大小没有约定。

一方面有类似nagle算法会把客户端的一些长度很短的包组合起来一次发送,另一方面因为以太网MTU等数据长度限制的存在,发到服务器的包有可能被分割成几个连续发送。前者可能会造成把逻辑上分离的包合在了一起,这通常称为粘包问题。后者可能会导致服务端处理包需要多次接收才能开始处理,这通常称为半包问题。

对于这两类问题,首先你要把TCP理解为面向流的协议,而不是包。其次你可以考虑怎么用处理文件的输入流的方式来处理网络的输入流。具体的,常见的解决方案:

  • 逻辑上定长,你可以不关心底层传输的包长度,一个逻辑上的完整包的长度
  • 使用特定分隔符分割,比如按行
  • 对于内容长度不定的数据,你可以采用先传包长度,然后传包内容
  • 应用层处理

(来自 http://www.cnblogs.com/sloong/p/5047743.html

其中,按行分割在普通文件读取中也有应用,库往往会开辟一个缓冲区,读入一定数据,找到行分隔符停止,这和网络编程中有点类似,不过网络编程的异常处理要更加小心,否则你会碰到帧(比如一行)过长等攻击。

Java NIO基础之ByteBuffer学习

Java NIO使用的数据结构不是普通的byte[],而是类似ByteBuffer的类。ByteBuffer使用起来与byte[]有很大不同,下面主要是自己学习到的一些使用方法。

ByteBuffer同时可以读写,一开始理解有点困难,建议按照推荐的操作步骤来使用ByteBuffer。即

  1. Channel#read(ByteBuffer)或者ByteBuffer#put方法,往ByteBuffer里面写入数据
  2. ByteBuffer#flip
  3. Channel#write(ByteBuffer)或者ByteBuffer#get方法,从ByteBuffer里面读取数据
  4. ByteBuffer#clear, ByteBuffer#compact

读写模式通过不同的API来切换,一般情况下,按照上面这个顺序使用ByteBuffer就可以。不过要正确理解和使用ByteBuffer,需要对ByteBuffer的内部有所了解。

ByteBuffer主要有三个位置指针(不是C/C++的pointer)

  • position,当前位置
  • limit,当前模式下的位置限制
  • capacity,分配时确定的空间大小

capacity因为一开始就被确定了,最容易理解。剩下两个位置指针需要配合ByteBuffer的“读写模式”来理解。

  1. ByteBuffer被分配之后,默认是“写模式”,因为刚分配的空间你读取是没有意义的。这时position为0,limit为capacity的值。假设代码中执行了一些写入操作,每次写入都会增加position。
  2. flip切换读写模式,position为0,即你写入的第一个byte的位置,limit变成你写入数据的最后一个byte后面的位置。
  3. 接下来你可以从ByteBuffer中读取数据了,每次读取增加position。
  4. 读取完毕之后,可以复用这个ByteBuffer,调用clear的话,position重置为0,limit设置为capacity,即回到写模式的初始状态。调用compact的话,你没有读取的数据会向前移动(System.arrayCopy),position设置为这些数据末尾之后的位置,limit设置为capacity。

用代码来测试一下

Read More

非阻塞IO与reactor模式

在写了非阻塞IO的基础知识之后,决定学习一下常规的非阻塞IO运行模式。

所谓运行模式,就是指以怎样的代码来实现非阻塞IO服务。为了比较和说明,先从阻塞IO的线程池化的服务器开始。

这是一个简单的Echo服务。ServerSocket在accept得到一个Socket之后,由线程池中的某个线程来处理这个Socket。

Read More

非阻塞IO与异步IO

本文是自己对最近学习到的IO相关知识的一点整理,之后会逐渐增加。

首先非阻塞IO(non-blocking IO)相信很多人都听说过,比如Nginx,Redis,NodeJS等等。得到的印象大多是非阻塞IO比传统IO(blocking IO)要好。这里多少有点误解。

非阻塞IO的目的是高并发,比如C10K这种目标。在连接数不高的时候性能并不会比传统IO好。为什么传统IO难以做到C10K,主要原因还是可以建立的进程/线程数量有限,以及高并发情况下IO等待时间太多,阻塞进程/线程运行等原因。

当然非阻塞IO并不是完全非阻塞的,IO通常分为数据等待和数据从内核空间拷贝到用户空间的两部分,传统IO(阻塞IO)在这两个步骤都会阻塞,但是非阻塞IO只在数据拷贝的时候阻塞,数据等待时系统通常会返回一个特定的异常码来提示数据未准备好。

非阻塞IO是一个行为特征,具体实现有select/poll,Linux 2.6之后的epoll等IO多路复用的系统调用。直观上来讲,非阻塞IO和IO多路复用没有关系,但是如果你一直在某个fd(文件描述符)上轮询的话,就会变得和传统IO没有区别,所以一般都是在多个fd上等待,当其中某个数据就绪了再取数据,这样就可以体现在非阻塞IO在数据等待这一步非阻塞的优势了。

从编程语言来说,非阻塞也可以选择用注册callback异步调用来实现。实际的IO类型中也有异步IO,但是大部分人都不怎么谈到异步IO,说非阻塞IO其实就是指epoll,其原因之一是Linux上AIO(异步IO)实现差强人意,Windows上IO多路复用只有select,剩下的就是异步IO,即IOCP,Windows貌似希望开发人员使用IOCP而不是开发类似epoll在Windows上的实现。服务器端开发,你懂的,Windows的用武之地很少。

IO多路复用为什么epoll脱颖而出,主要还是他的数据通知机制。select虽然大部分平台都支持,但是fd有数量限制,1024个。poll消除了这个限制,但是得到数据就绪的响应之后,你必须遍历庞大的fd列表来得到就绪的fd。epoll的优势在于返回的响应中包含数据就绪的fd,综合各方面来说是最优的。

当然epoll是Linux的系统调用,如果在Windows上你只能用select,在Solaris上你需要/dev/poll,OS X是kqueue,通常编程语言会帮你统一API,比如Java。但是关于非阻塞IO的基本知识建议还是要了解一下。

参考:

台場 2016-08-27

趁着台风来之前做点ingress任务,选择了台場。

查路线的时候鬼使神差地选了一个到现在为止我还读着拗口的「ゆりかもめ」电车,然后选择在「お台場海浜公園」下车。自然而然的我就开始做那个18个「お台場公園めぐり」连续任务了。

刚开始一两个我觉得还没什么,还觉得那两个不同颜色的缠在一起的管子挺好玩的。

任务一开始会往「お台場第三公園」方向走,那个公园人很少,从地图上看是一个正方向的公园,三面环海,中间有个盆地。

Read More

2016年8月25日

好久没有写博客了。但是VPS的钱还是要交,于是想着继续写点东西吧。

之前博客放置不写,有一个原因是没法升级到最新WP,今天查了下,感觉可能是服务器的防火墙的问题,增加了可以访问外部HTTPS网站之后就可以了。

小结就是iptables功力不够。

今天另外做的一件事情是换了主题,这样感觉就和以前不一样了。

暂时就这些。

8月24日随笔

时间一晃已经到了24日,距离辞职已经两周多了。这段时间除了处理事情之外就是休息了,现在记录一些这些天的小事。

口吃

在原公司头两年我是没口吃的,但是三四年的时候我发现自己在说话时会很高几率口吃。原因我大致知道,长时间工作没有和他人谈话。两点一线,在家也很少谈话。解决方法理论上很简单就是平时和别人多说话。不过造成这样情况不得不说原来小组的氛围太压抑,工作分配不合理等等。
现在几个星期后,感觉自己好多了,基本没有那种症状了,主要可以轻松休息,做自己喜欢的事情。这也算是这段时间的工作状态恢复吧。

twitter

月初对twitter很上心,因为好久没用了。不过最近发现时间线上的内容好没有营养,越是生活推越是有固定的圈子;而且年龄层次不同谈的内容感觉也不同,好多学生;在职的稍微好点,几个现实中就有接触的自然没什么问题,其他的感觉难谈拢。唉,还是当做信息窗口吧。

Read More

坐出租车和uber

昨天突发奇想去了一次西湖,路上高铁等按下不表,单就坐了两次uber写点对于杭州出租车的想法。

拒载,选择性载客是一种恶化打车环境的行为。从司机角度来说,碰到一个扬招的人,问了去处,太近不去,太远也不去,其中部分原因是觉得不实惠。比如堵车,堵车费也不高。还有原因是太远回来路上基本是空车。个人觉得从司机利益角度来说无可厚非,但是导致打车人等待时间变长,打车体验大幅降低。本来出租车作为公交的一种更加自由,但是现在看来司机也有自己的小算盘,不愿意完全为你做事。我觉得这个和出租车行业长期以来一种“垄断”性质,收入低,不明不白份子钱,运载力不足等等脱不了干系。期盼相关部门解决这个问题?不太可能,他们只向钱看齐。

解决行业痛点的一个是之前快的打车,滴滴打车之类的工具,问题的原因没法直接解决,但是通过提前告知去处,然后司机选择是否接单,这样就可以避免扬招时的尴尬。个人觉得是一个很好的通过协调打车人和司机之前的方案,间接提升了体验。但一个副作用就是扬招的人更难打到车了。另外在车比较少的地方仍旧很难打到车,去得比较远没有人不愿意接单也没办法,虽然比你连续扬招几辆被拒绝要好。其背后的一个问题还是出租车运能不足。个人觉得这其实还是行业的恶性循环造成的,包括准入机制,垄断性质,万恶的份子钱制度等等。

运能不足不能期待出租车行业整体反思,”人民拼车“其实是一个很好的切入点,通过大众的车辆来弥补这个不足,类似嘀嗒拼车,uber都是不错的工具。uber其实还更进了一步,不使用国内那种司机选单方式,而是自动调度,这里其实杜绝了选择性接单这种恶化体验的行为。从使用上来说,不管到哪里,让系统帮你选择接单一方面公平,另一方面也帮你选择了路线,降低了运营的难度,实在是对司机和搭车人都很不错的使用方法。

当然,这对于传统的出租车行业是一个很大的威胁,也看到过各种闹腾。对于搭车人来说,最重要的还是方便快捷。地铁站常看到出租车、黑车甚至还有摩托车,出租车拒载很常见,于是只能黑车,那些叫嚣打击非法营运车辆的人理由充分,然后呢维护的只是出租车的利益,难道半小时路程你让我走回去?现在太多这种只看表面不考虑真正解决的事情。

我其实也不会预计之后这个行业的发展,出租车现有的制度只会劣币驱逐良币,打车体验很一般甚至很差。专车虽然可能不专业,但是满足了很多人需求。撇开价格来说,两者可能会达到某种平衡,在不同层次各自覆盖。

最后说一句,我一直深信的出租车下午4点换班的说法,后来才知道只是大部分出租车司机不愿意做下午4点后堵车比较多的生意,于是昨天下午吃好晚饭后直接用uber,再也没考虑出租车。