文：Charry

最近在Youku上看了几期《非你莫属》和《职来职往》，再加上也面试过一下新人，写写我的感受。

如何成功求职，是一个老生常谈的问题，Google一下，很多文章都在谈这个。希望下面这些内容可以作为一些初入职场的新人的参考：

简历

好的简历是通向面试的敲门砖，纵使你再有才，如果没有适当的表现出来，也将淹没于茫茫人海之中，所以第一步，你得好好准备一下最近的简历。简历的质量取决于内容，而非材质、包装，如果你不是艺术类专业的应聘者（也许艺术类的也不需要这样），无须将简历做得和个人专辑一样，反而会让人觉得你只重外表，不重内涵。好在现在很多招聘网站都提供简历模板，通常比你自己做的专业，企业HR部门也会直接将它们打印出来，各方都省事了。

除了姓名、联系方式等必要信息外，简历上要写明自己的过往职业记录，这里不要像流水帐一样记录每一个细节：要突出“重点”，所谓的重点是你在该阶段是什么角色，做了什么主要项目，以及你是如何贡献自己的力量的。注意这些黑体字，这些都是突出你自己的地方，你需要在这里让别人能看出你的特质，企业所需要的特质，技术上的或者软实力上的。所以要着重强调你的加分点，而不是罗列你的过去。而且，企业的管理层都比较忙，很多人，很可能都没有认真看你的简历，就匆匆的去面试你了，坐在你面前才开始翻看两下。这个是事实，只是很多面试官或者企业不愿意承认而已。你觉得在这种情况下，你洋洋洒洒几百字，几千字，让这些面试官肿么看啊，时间这么短？万一你的一个闪光点就这么被忽视了，怎么办？

内容得体，成熟稳重。不要为了突出自己的所谓的特点而过度的强调它，比如我前两天面试了一位，他的简历上用红色标注：“英语流利，标准的美国口音，有着西方式的思维方式”，而且中英文简历都是加强注明了这一点。英语流利算是你的强项吧，有着西方式的思维，这个不算好也不算坏，中西各有所长，我实在是不明白，他把‘标准的美国口音’放在简历上并着重强调，需要传达一个什么样的信息。美国口音并不比印度口音高尚多少，除了容易懂些。

要有所权衡，有人应聘软件开发职位，他简历上还写了精通Word、Excel、Window操作、HTML语言，有这个必要吗？对此我们可以这样解读：如果你真的很有技术能力，且也精通Word、Excel等，那么你不懂如何分辨优先级（prioritize），也不擅长决策（decision making）。另外一种可能是：你真的只是精通那些技术了。

形象

如果你只是面试一个技术职位，并且不是管理层，Senior及以下，可以跳过。如果目标公司是一个Geek型的公司，也可以跳过，他们可能不太注重形象。否则，你得稍微注意一下自己的着装、言行等形象。

为什么，因为企业招聘这类人，通常是期望你去带领一个团队，即使不是现在，也是想让你以后去带领一个团队，你需要有一定的‘范’。这里的‘范’包括：穿着稍微正式一些，西装革履太正式了，并非一定需要，但总不能穿着运动服就去了。言语上需要得体，不要满口口头禅，或者说些不适合在公开场合说的话语。举止要得体，不要看起来畏畏缩缩的样子，将来如何带人？

试想你每天的要面对的老板，头发如雀巢，穿着运动服，看起来畏畏缩缩，你心里恨不得上去揍他一顿，你会信服于他吗？

这里要说的不是让你只是在面试的时候注意，而成功后就我行我素。我的意思是：如果你有你的职业规划，得尝试着有所改变，上面说的几点就是。

准备

准备下一些基本的问题，比如你跳槽的原因、为什么有空档期、对目标公司的认识、你所理解的应聘职位是什么样的，等。别在面试的时候说的前言不搭后语，也许这些问题让那些面试官自己来回答也是回答的稀里糊涂（如果不准备的话），这也是事实，但是通常人们就是期望应聘者在面试的时候表现的比平时好些，总是有意无意的拉高标准，退一步想，面试是什么时候，你连这个时候都不重视，将来你还会对什么重视呢？

专业性问题，一定要先温习一下，现在是信息发达的时代，很多东西，你无须个个都记住，重要的思维方式等，而非好记性，Google就可以了，一个你平时可以稍微多花一丁点时间就可以做的很完美的问题，但是面试的时候，你如果回答不上来，从面试官的角度看来，你就是不懂。

非专业性问题，比如谈谈你对某些项目管理中遇到的问题的看法，通常这些都是开放性的问题，一定回答的有所重点，不要说了半天，让人无法理解你的意思是什么。是就是，不是就不是。

沟通

一定要有诚意，没有诚意，装总会吧？（有人说面试就是两个人面对面坐着，互相欺骗）但是不推荐。比如，有面试者被问到为什么想跳槽，有什么原因使其有离开当前公司的打算，他答道：也不是说一定要走，只是来看看，有好的就跳，没有好的就带着。拜托，大家都很忙，你是来参加《职来职往》的吧，有木有？面试官也伤不起的啊。

再者，大多公司有人员流失率（turnover rate）的KPI，你如此回答，会让人觉得你不够忠诚，将来难免会走。让你进来，万一走了，浪费时间、精力，影响项目进度、影响士气，KPI都被拖后腿了。这样的人通常会被忽视。

不要一味诋毁上一次公司，这里不好，那里也不好，没有感恩的心态，如何做人。有些人总是爱指责别人，自己总是对的，别人总是错的。这种人没有团队合作精神（teamwork），将来势必影响成员之间的合作，会把整个team搞的鸡飞狗跳，组织杀伤力很强。

职位

记得要问清楚你应聘职位的信息，是不是你所期望的，如果你误解了那个职位，然后进去了，那就杯具了，浪费大家时间。有些公司的职位描述（JD）没有专门人把关，HR也不了解具体部门细节，业务部门就随便找个人写了，他写的是他理解的，并非是完整的、合适的，HR也不清楚，就发布出去了。

所以企业发布的广告不一定是精准的，有些甚至是人为模糊之。你一定要问清楚了，充分核实。

薪资

一般人跳槽前，通常会把自己的当前薪水多写一些，然后再加一些就是期望薪水。如果水分太大，反而可能导致面试机会的丧失。要知道，HR们通常手里有一份本地区的同类型企业的，不同层次，不同职位人的平均薪资表。可能是互相交流得来的，也可能是从第三方专业机构买来的。如果你在原公司是个Engineer，你说你拿了个Section Manager的薪水，HR估计直接就把你过滤掉了：不诚实，期望太高，可能不稳定。

应聘者，尤其是新人，在我看来不必过分的看重薪资。学习，打好基础最重要，你踏踏实实的做好了，老板自然会给你加的，还怕你走了呢。

猎头

让猎头帮你找工作，可以说是一种不错的方法，这个只对于中高级人才有效，猎头公司一般不会接5年以下或者当前职位比较低的求职者的简历的，他们需要拿提成，那条线以下没甜头让他们赚。如果你符合条件，可以多找几家猎头公司，把简历提交给他们，让他们给你物色职位。

猎头公司也会告诉你一些目标公司的基本情况，公司看中的特质，这些只能作为参考，有的公司的招聘部门的JD都写的很泛，或者只有业内人士才能看的懂，猎头拿到的JD可能不准确的，或者被误读了。所以猎头的建议也只能作为参考，不可尽信。

广告

企业可以做广告，你也可以。微博让每个人成为了新闻中心，同样，你得善于运用一些求职类网站，比如，智联招聘、中华英才等，HR常光顾那里，或者一些职业SNS，比如LinkedIn，这是猎头常出没的地方。

其他

要准时。（我想到了再补），如有帮助，欢迎来信分享你的喜讯。

生命失去了，再知道可贵，时光错过了再知道后悔，近日，媒体中充斥着日本灾难的新闻，恐慌的气氛已经传播到中国，今天的抢盐就是例证。发帖一枚，希望各位，珍惜自己，珍惜自己和家人朋友或者佳人朋友的相处的时光。在灾难面前共携手，在困难之时不低头。

祝福每一个你、我和TA，Life is short, play more(人生苦短须尽欢)，该恋爱的恋爱，该结婚的结婚，God Bless JP, God Bless Everyone.

有些日子没更新了，随便发个凑个数。

我一直用的是PuTTY Connection Manager，它的自动登录的功能不错，好虽好，也有些不尽如人意的地方，还是直接用PuTTY方便，遂配置了基于Key的登录方式，具体方法请参考这篇文章：http://linux-sxs.org/networking/openssh.putty.html。

如何配置，链接中的文章说的很清楚了，有一点需要强调的是：配置文件的权限必须设置正确，否则会报：Server refused our key 这个错误。只需修改权限如下即可：

$chmod 600 authorized_keys
$chmod 700 .ssh

完。

[ad]

刚刚打开Google，发现有了个新的Logo，很像一个蛋糕，点进去是我的profile，原来是来自Google的生日祝福，很贴心。

[ad]

标题：如何优雅的退出Java程序
本文中信号拦截代码来自下面的博客：
http://twit88.com/blog/2007/09/27/do-a-graceful-shutdown-of-your-java-application-when-ctr-c-kill/

在UNIX下，通常我们结束一个进程，最常用的方式就是使用kill –9 <PID>，这个方法最简单，但是会带来一个问题，程序可能正在执行某些操作，而这些操作不能被突然中断，否则会造成一些资源的泄露，或者数据完整性的问题。

在UNIX下，信号可以被用来解决这个问题，我们应该比较熟悉kill这个命令，通常使用的命令kill –9 中的kill其实不是‘杀死’的意思，而是‘发送’。kill –9 就是把 SIGKILL（数字代码为9）的信号发送到目标进程。在Java中，可以捕获这些信号：

Runtime.getRuntime().addShutdownHook(…);

当我们执行Ctrl+C或者kill命令的时候，信号Handler会被通知到，这个Handler在一个新的线程中（并非主线程），我们可以在这个Handler里面处理资源释放等问题，注意这里的kill没有带参数，其实等同于kill -15，如果使用kill -9就会直接干掉目标进程，资源得不到回收。具体做法可参考上面的链接。

当Java捕捉到SIGTERM信号的时候，它会执行子线程中的shutdown(); 代码，理论上我们可以把资源清理工作放在这里，我们知道，这个信号监听的线程和主线程，分别在处在两个线程中，这里的代码执行完毕后，它并不管主线程里面的代码是否执行完毕，直接就把整个进程结束了。假设我们有一个长循环在主线程中，它可能会在循环没有执行完毕就殒命了。这个不是我们想要的，解决也很简单：在两个线程中增加同步机制就可以了。

尝试一：
设置一个标志位(notifiedMainThreadToExit = false)，当收到SIGTERM信号后，在子线程中设置notifiedMainThreadToExit为true，然后sleep(Long.MAX_VALUE)，主线程轮询这个标识位，一旦发现该变量为true，就退出循环，并且释放资源。

问题出现了：主线程的确退出了，可是子线程一直长眠，这个会导致整个进程都不会退出。后来我在主线程退出前，执行System.exit，问题依旧。理论上：System.exit执行后，它会结束该虚拟机中的所有线程，不知道为什么在这里行不通。

尝试二：
设置两个标识位(notifiedMainThreadToExit = false, notifiedSignalHandlerToExit = false)，当子线程收到信号后，它通知主线程(set notifiedMainThreadToExit = true)：“我收到SIGTERM信号了，你可以准备收工了”，然后，子线程并不马上退出，也不永久休眠，而是轮训等待主线程通知自己。当主线程接受到子线程的通知后，退出循环，然后通知子线程(set notifiedSignalHandlerToExit = true)：“我已经准备好了，你也可以收工了”，这样两个线程都可以正常的退出。

结论：
尝试二是可行的，且两个线程间不会产生Race Condition，因为没有两个线程同时写的问题，所以很安全。这里可以下载例子。最后提醒，文章提到的kill，是不带参数的，不要用kill -9。

[ad]

刚收到魅族寄来的月饼，前几天魅族打电话和我确认邮件地址，我问他们要这个干什么，电话那头说是邮寄一个协议给我，原来是盒月饼。保密工作不错。

[ad]

看《盗梦空间》前，并不知道它的大致讲的是什么样的故事，据说IMDB上的分数很高，下午就特地去科文中心观摩了一下。看完以后，我严重的怀疑编剧是个程序员或者曾经是个程序员。下面我们来简短的分析一下它的Script（脚本）。

植入
电影的主题是“植入”思想，这个其实就是Spring中的IOC – Inversion of Control，所谓的控制翻转，就是将外部的思想注入到内部。

多层的梦
电影中，有一层的梦，两层的梦，三层甚至四层的梦，这个就是函数调用中“栈”，调用的层次越深，系统开销越大，所以Leonardo们不太愿意使用多层调用。

穿越(Kick)
当片中人从深层次的梦回到上一层的梦时，他们使用的技术就是异常(Exception)，注意这里可不是简短的return，return是安静的、正常的，而他们返回上层的梦，用的都是开枪自杀、电梯坠楼这样的非正常行为。而且我们可以注意到，异常只能一层一层的抛出：比如电影的最后，他们先从第四层返回、然后第三层、第二层、最后回到现实。

对于最后Leonardo直接从第四层回到现实中，我怀疑这小子偷偷使用了GOTO语句，虽然我们不推荐使用，但是在坠入水底，这种特殊的情况下，我们还是可以考虑使用这种技术的。

用于同步用的歌声
还记得他们如何通知分布在不同层次的人吗？放一首歌曲。对，这个就是设计模式中的Observer模式。一人放歌，每个层次的人都能收到。

造梦者
还记得Leonardo找Ellen Page干什么的吗？让她去造各种各样的“场景”。Page担任的就是设计模式中的Abstract Factory的作用(请参考其字面意思)。而Leonardo本身并不去造梦，他使用的是代理模式(Proxy)。

Limbo（迷失域）
什么是Limbo，很恐怖的一个地方，你进去了，就很难出来了。程序员通常叫它死锁(Deadlock)，一旦陷进去，等你老的像齐滕（一说为斋藤）那样，你都出不来。

时间的快慢
为什么现实中的时间过的慢，梦中就快呢？你想想啊，电影的Script在计算机中运行的时候，它们是多快啊！车从桥上掉下去的那么短短的10秒钟，可以容许我们执行很多指令。

多人一起做梦
Leo和同伴们是如何一起在梦中交流的呢？他们用的是共享内存(Shared Memory)和进程间通信(Inter-process Communication)技术。我怀疑他们没有使用消息队列和Web Service这类技术，因为这些技术较共享内存这类老的技术，还是显得有些慢，不满足那种惊心动魄的场景。

综上所述，我推断编剧也许大概可能是个程序员，因为他的很多灵感都来自软件开发中的技巧、技术和模式。

[ad]

周日尝试一下登山，顺便锻炼下身体，6点多出发，近10点钟返回，从灵岩山行走至天平山，历时3个多小时。

临近结束，下山的时候，膝盖有些不舒服，之前跑步的扭伤的，还没有好，才知道下山挺伤膝盖的。

上图为领头的两位队员。

– 分割线 –

坎坷的人生，来自家乡的高逸峰：

傍晚去买3D眼镜，在回来的路上，偶然发现路边的书报亭有《独唱团》出售，遂买下。前些时候准备从淘宝上买，卡有些问题，一直耽搁至今。

——–分割线——–

看了这篇文章，就去买个3D眼镜（红蓝）玩玩，不是专业的那种，10-15块的而已，千万别戴时间长了，看多了眼睛会累。这里还有3D播放器和片源。这种眼镜不适合看3D电影，效果不好，想看，还是去影院看吧，偶尔看看图片还是可以的，Flickr上还有很多红蓝3D图片，请点击这里。

[ad]

周末的时候和team讨论了下如何用最简单的方式，提高数据文件的单位时间传输吞吐量。下面是一个简单的应用场景：

一个目录(DIR1)，有很多Producer向这个目录里面放文件，同时有很多的Consumer负责从这个目录里面消费这些文件，插入数据库或者做其他的操作，然后删除或者移走这些文件。

假设条件：

• 一个文件中转目录DIR1，这个目录位于一个网络存储上
• 一个生产者，每一秒钟向DIR1里面放一个文件
• 若干个消费者，假设有8个，其实是8个不同的服务器，都可以访问DIR1，多台服务器可以起负载均衡的作用，任何一台或者几台出问题，整个数据流不会中断
• 解析一个文件大约需要2-14秒
• 最后一点：位于网络存储上的目录DIR1，我们认为它是不会出问题的，它不是这里的问题核心

这个场景很普遍，很多公司大概都会用到，尤其是那么比较老的系统(Legacy System)，下面是两种方案：

方案一

Consumer循环扫描DIR1，一旦发现有文件，循环解析这些文件，这里有8台服务器，也就是说有8个Consumer一起这样做。代码如下：

	public void run() {
		System.out.println("Created consumer:" + threadName);

		while (true) {
			File file = new File(Constant.STAGING_FOLDER);
			File files[] = file.listFiles();
			for (int i = 0; i < files.length; ++i) {
				File f = files[i];
				parse(Constant.STAGING_FOLDER + "/" + f.getName());
			}

			Commons.sleep();
		}
	}

看起来很简单，可是上面的代码效率非常的差，多个Consumer有很大的几率拿到相同的文件，当某个Consumer尝试去解析一个文件时，却发现这个文件已经被别的Consumer解析过了，并且文件也都删除或者移走了。这样浪费的很多的CPU时间。

可以用下面的方案来替代：

方案二

	public void run() {
		System.out.println("Created consumer:" + threadName);

		while (true) {
			File file = new File(Constant.STAGING_FOLDER);
			File files[] = file.listFiles();

			int nCapacity = files.length > Constant.CAPACITY ? Constant.CAPACITY
					: files.length;
			System.out.println(this.threadName + " found " + nCapacity
					+ " files");

			for (int i = 0; i < nCapacity; ++i) {
				File f = files[i];
				f.renameTo(new File(Constant.TMP_FOLDER + "/" + f.getName()));
			}

			for (int i = 0; i < nCapacity; ++i) {
				parse(Constant.TMP_FOLDER + "/" + files[i].getName());
			}

			Commons.sleep();
		}
	}

它和方案一的不同之处在于：它每次扫描完目录后，最多只取前若干个文件，这里是10个。并且，它不急于去处理文件，而是把文件马上移动到一个临时工作目录，其他的的操作都是相同的。

对于这个方案，有个附加条件：这个临时工作目录tmp，一定要和staging目录在同一个文件系统(filesystem)，这样的话，mv操作就只是修改一下inode，几乎瞬间完成。

比较（Benchmarking)

为了测试两中方案的效率差别，我写了一个模拟程序(http://googlestop.com/download/SimConsumer.7z)，它有7个class：

1. App.java - 程序入口
2. Commons.java - 共享的函数
3. Constant.java – 配置参数
4. Producer.java - 生产者，每隔一秒向目录staging里丢一个文件
5. AbstractConsumer.java – 抽象消费者，定义消费者的一些基本属性和行为
6. Consumer1.java - 具体消费者，实现方案一
7. Consumer2.java - 具体消费者，实现方案二

在App.java中，你可以指定调用Consumer1还是Consumer2。

对于前者(Consumer1)，staging目录下的文件数目不停的增长，并且如log显示，有很多冲突：一个Consumer准备处理的文件已经被其他的Consumer处理完了，造成了很多无效的操作，由于消费速度更不上生产速度，DIR1被撑爆只是时间的问题。

对于后者(Consumer2)，staging目录下的文件几乎马上就会被移动到tmp目录下，大部分时间，文件数都为0。而tmp目录下，在程序稳定后大概保存在20多个文件左右，保持一个动态的平衡。用这种方式，你也会看到很多冲突，但是只会发生在程序刚开始，原因是，刚开始的时候，8个线程几乎是同时去访问staging目录，势必拿到很多相同的文件，待到稳定后，就很少有冲突发生了。

这两种方案都是最基本的，没有借助于第三方工具完成的，成本是最低的，其实还有一些其他的方案，可能会借助一些服务来实现，比如消息分发、数据库等。有时间的话，我继续补充。

[ad]