2014 年终总结

有了秒秒,年终总结真简单。

  • 1月 等秒秒出生。年会抽中一张京东卡。夫人送了台 rmbp13。帮大家抢火车票。
  • 2月 等秒秒出生。给某电子货币矿池 gpool.net 打杂。
  • 3月 家里多了一只秒秒,拿到 g 的 offer,从 mstr 离职去了 g。
  • 4月 陪秒秒玩。
  • 5月 每个周末坐火车去郑州陪秒秒玩。陪秒秒去九江玩。team 被拆。
  • 6月 每个周末坐火车去郑州陪秒秒玩。HT060 的大梁折叠扣被骑断,收了台二手白色 mup8 通勤用。
  • 7月 每个周末坐火车去郑州陪秒秒玩
  • 8月 每个周末坐火车去郑州陪秒秒玩
  • 9月 陪秒秒去香港玩。team 被干掉,准备换组
  • 10月 秒秒去澳大利亚玩了,只好跟朋友一起玩 ingress。美国签证被 check 整三个月。
  • 11月 陪秒秒玩。在公司养了一盆碗莲。
  • 12月 陪秒秒玩。得知明年初继续换 team。圣诞晚会抽中2等奖和4等奖,但规定只能领一个4等奖。

有关技术的小事:

  • 从没写过 java 的我,突然在贵司转行做 android 工程师。
  • 利用零星的时间玩起了 golang。
  • 有了 mac 之后,再也不习惯用 win 了。
  • 没时间维护的 yupiao.info 和 railmap.cn 还没断气。

 

2013北京IT企业一日游 – 腾讯地图

作为GIS专业毕业的码农,很想去某个互联网地图玩玩。这次是soso地图。

9月初,请饼干君帮我投了一份简历,然后我就去面试了。小插曲:由于正赶上jike离职高峰,保安的登记单上各种熟悉的jike同事。

2013-09-12 10.55.22

 

soso地图也很赞,办公室在第三极书店原址。办公区有各种饮料机,休息区和会议室也很漂亮,相比百度更有大公司的范。soso地图这边由一面的面试官负责跟踪从头到尾的流程,包括各种约面试,约经理,保持联系等等。为啥不弄个hr实习生来干这活儿呢,比用码农经济实惠很多啊。

2013-09-12 11.01.27

前两轮面试的体验不是非常好。可能是由于腾讯不发笔记本的缘故,面试官不愿意在候选人做题的时候在一旁陪着写代码。一面和二面的面试官都是把题目丢给我,然后就跑回工位忙自己的事儿了。这样你怎么能看到候选人的思维过程并深入讨论问题呢?

一面的情况是:“这两个题看明白么?” “没问题” “要多长时间?” “20分钟吧” “这么快?我给你半小时吧”。妹的,明明是两道水题,约瑟夫环和一个字符串题,太藐视我等竞赛健儿了。难怪不需要面试官陪着做题,这种题能讨论出什么东西!向推荐人咸饼干吐槽后,他嘱咐我水题别水做,于是写完代码又检查完工工整整抄了一遍。最后面试官过35分钟才回来管我。

二面情况类似,又丢下我一个人写代码,基本不涉及一点算法的水题,又自己跑回去忙了。写完了等着半天,打电话给一面面试官让帮忙叫,才把人叫回来。二面面试官很神的是CUGB地院那个GIS专业的学长。普遍来看,互联网地图企业更喜欢CS毕业生,而不是GIS毕业生。原因大概是GIS的学生coding能力普遍太弱了,无法做出互联网级的产品;而GIS的专业知识,让CS的人学起来却很容易。所以,一旦在互联网行业里碰到学GIS的人,一定是大牛。

三面比较有趣,是一个刚从g.sh过来几天的gg,问了一个他正在接触的实际的开放的问题,就这个问题聊了40分钟。感觉题目很有趣,兼顾工程和算法。我各种扯,最终想的比较接近了,但最终没有提出面试官期待的“隐马模型”。应该还是因为自己没在生产环境中用过隐马,所以还没形成相关的条件反射吧。还好,我还能勉强跟他扯几句隐马模型。

回家路上,接到电话约了第二天经理面。我10点早早过去,等了俩小时,眼看大部分人都吃完午饭回来了,忙碌的经理才出现。聊了聊,交换了互相目前的情况,最后表示他们有几个候选人,他们还要看看,一周给答复。嗯,好。然后到写这篇文章的时候快三周了,还没消息。

两年前校招的offer也说一周给答复,等了两年还没答复我!

于是,soso地图给我留下这么一个印象:不守时,效率低,对面试者不够尊重。

北京北-清华园

谢谢你,每天都能订到票的神车4471。

节后第一天上班略早,碰巧下雪没骑车改坐地铁,碰巧追上停靠清华园的4471。

4471 2014-02-07

 

以及,初次体验自动售票机。

2014-02-07 13.11.37

还有,无数次订你的票不付款。

2013北京IT企业一日游 – hulu

2013年换工作的时候面了几家公司,分享一下面试记录吧。
hulu
hulu1
北京的为数不多的技术非常靠谱的外企之一。snoopy 的某队友在 hulu,并且近期要H1B 去 G.MTV,联系求推之,正好赶上他离职前一天丢过去简历。正巧我打算投的那个坑,又是他走后放出来的。
8月30日推;9月3日 hr 安排电面,是工程师自己跟我约时间,很奇怪的流程。顺便赞一下 hulu 的 recruiter 是从 google 来的,靠谱程度跟 google 相比只多不少,介绍情况的电话也足足打了7分钟之久。顺便提一下,粗粮公司著名 hr Amphi 也来自 google。

9月6日,面试官来电话约了9月9日的电面。

人肉了面试官的背景,除了发现他养了几只萌猫。他的 id 也经常出没水木宠物版,人人上也全是猫的照片。养猫的事儿让我对 hulu 好感倍增。然后面试官居然每天都是8点就到公司了,神啊,这作息习惯真的很赞。

电面之前,看了各种面经,说 hulu 的智力题多么不靠谱。怕怕,各种准备。结果约电面时被告知不写代码。电面时也没问任何算法相关的话题,只是让介绍一下简历上的项目经历。介绍完,心中拔凉拔凉的。因为只问项目经历的话,我这种来自菜公司菜校的小菜大概率会被干掉吧。

做好了被挂掉的准备,9月16日接到 recruiter 电话,安排了23日的 onsite,整个一下午。
一面。上来先被问面向对象的概念,与面向过程、面向函数的区别,完全慌张了有木有。于是只好说概念背不下来,我给你举几个栗子行不。然后多态和重载还有点搞混。完全慌张了有木有!然后开始问算法,写代码,立马进入稳定发挥状态。
二面。记不清是什么题了,总之很有趣,从来没见过,并且答得还不错。
三面。把简单的 dp 题想歪了,于是跟面试官一起兴致盎然的琢磨我那个看起来很有趣的方法对不对。直到时间快用完才老老实实回来写dp。
四面。是我面试这个 team 的老大,说最近做产品的事情多一些。然后就请他看了一下我的网站,跟他聊了聊产品上的想法,他也提了不少建议。最后也做了个技术问题,还不错。

 

9月24日通知我过了,约了25日见见VP。
VP – Joyce Zhang是大牛人,相关情况可以自行搜索。她介绍了她的理念: 把 hulu beijing 带成一个小而美的精英团队。她比较喜欢问系统设计方面的事情,问了抢票和 antispam 的细节,特别好奇为啥我不用一下机器学习的东西来做 antispam。我感觉VP这轮不是很美好,或许是一些软的技能不太合适,发 offer 的事情被放缓了,跟我说10月底再给下一步的消息。

 


一个月后,由于 Joyce 离职,需要再面一次当前北京部分的负责人。时间安排在了10月31日晚上6点,感觉是临时挤出来的时间加了这一轮,很感谢 hr 帮忙安排。按 hr 的描述,说技术上我足够 solid,hiring manager 也很想要我,但是由于我的背景跟别人不太一样,大家有各种各样的担心。如果这轮面试能证明我组够靠谱,就帮我争取名额。这次也是问系统设计,讲讲自己的背景和经历。然后做了俩题,终于见到了传说中的比较难的智力题,然后华丽丽的卡住了。
最终,11月5日成功收到拒信。
hulu2

hulu 北京的办公室布置的很小清新,跟logo一致的鲜亮的绿色。没有雇前台,因为这里只有工程师,不需要前台。有各种免费食品饮料的茶水间,命名十分有文化感的会议室,还有风光不错的小阳台。

面试题目没有遇见过让人抓狂的 tricky 的题目,也没有偷懒直接用 poj 原题。流程安排十分紧凑流畅,休息和等待时间稳定的控制在20分钟左右。可见对 candidate 的尊重。
hulugans 都很喜欢穿公司的文化衫,文化感极强;工程师们都很年轻很精神,完全没有屌丝公司码农的颓废感。

hulu3
再赞一下hr,很多细节让人觉得十分贴心。比如,会议室门上的手绘姓名牌(超赞!!)。比如,第一天给我拿了瓶雪碧,临走我说不爱喝太甜的碳酸饮料,感谢之后就放回冰箱里了。第二次去,拿了个脉动拿给我,太贴心了。

hulu4

毕业季

每次想认真写点文字纪念逝去的 jike,语气就无法控制的转为调侃模式,写出一些乱七八糟的东西。只有这样才不会很难受吧。

2011年11月,大家在千军万马中抢来人搜的 offer,为了一个共同的目标,放弃了BAT和牛逼外企的机会,相约来年的金台夕照。

几个月前,忘记从哪一天起,大家完成了手头的工作却发现不再有新的事情需要做,茶余饭后讨论内容从房价涨跌变成了面试算法,从遮遮掩掩讨论offer升级为明码实价互相攀比。一顿又一顿请散伙饭,一次又一次的合影留念,一个又一个同学相继离开。这一切,都像极了毕业。而即刻,也像极了一所大学。

2013年9月,即刻搜索大学大部分同学顺利毕业,进入百度和百度等知名互联网企业工作。少数优秀毕业生免试升入中国搜索研究生院,继续深造。

今天离职,办完手续不舍得走。虽然已寄盘古篱下多日,故公司远在东三环,但还是很想四处转转,找找即刻存在过的痕迹,跟大家都打打招呼合合影。

无法祝你前程似锦,只剩一句,
Jike, farewell.

jike

拆个百度影棒

前些天看到京东百度影棒首发,就顺手买了一个。早上听笨狗同学说起,天猫盒子给人就是华强北的感觉,于是小期待了一下这个百度影棒。

下午京东如期把影棒送过来了。盒子很小巧,忘记放拍照参照物了,抱歉。

IMG_20130929_163659

 

盒子背面有个二维码,盒子要配合手机使用的。
IMG_20130929_163715

 

还有保护标签,真是贴心的设计啊。可惜由于材质太坚固,轻松就无损截开了。

IMG_20130929_163854 副本

打开盒子的过程很费劲,上下盖卡的太紧了,最后用撬棒撬开的。内容物如图,并没有之前评测中所说的会送hdmi-vga转接线。

IMG_20130929_163955正反面大图

 

IMG_20130929_164038

 

 

侧面模具做工略有不完美的地方

IMG_20130929_164113

 

好了,开拆。

IMG_20130929_164757

整体是卡扣+点胶的方式结合的,于是只要从接口处轻轻撬,撬开接口附近点胶的地方,剩下的就是几个卡扣了。

IMG_20130929_165017

 

 

 

开始还以为内部很简单,就一块PCB。正面可见CPU,和两颗内存。内存每颗256MB,正反面各2颗。拧开两个小螺丝,看到还有第二块pcb。

IMG_20130929_165346

 

 

 

第二块PCB是存储和无线,一个SOP8的NOR型FLASH,一个TSOP44的NAND型FLASH,以及无线网卡+天线。

IMG_20130929_165441

 

IMG_20130929_165450

 

PCB做工还不错,焊点很漂亮。可见的问题是,上图中有一个SOT23的焊盘,估计是控制某个设备的电源的MOS管,用了一颗0欧电阻代替。猜测是电路有需要修改的地方,来不及重新制版了。

好,全文完。

为啥没有功能评测?网上不是有各种软文么。并且,他没送hdmi-vga线,公司配的显示器没有hdmi口……

11天台湾铁马环岛游记(目录)

再不写完游记就剁手!已经两个月过去了!再不写就忘了啊!

于是丢一篇目录上来以敦促自己……

2013-06-09 09.04.21台9_164k_20130611_0959162013-06-15 12.56.3820130615_103010

@taiwan

6.7
1500 桃园机场
1630 高铁桃园站
1700 台北车站
1730 台北车站地面
1800 新月
2000 阳明山
2400 新月
2500 找吃的!!
6.8
1000 出发
10:00 NTU
12:00 淡水
14:00
白沙湾
九份
瑞芳
6.9
瑞芳
瑞滨
宜兰
苏澳
6.10
南方澳
苏花公路!!
东澳
南澳
和平
6.11
清水
太鲁阁
花莲
丰田
6.12
丰田
瑞穗
台东
池上
6.13
池上
知本
太麻里
小狗狗!
金轮
6.14
金轮
达仁
寿卡!!
车城
6.15
恒春
鹅銮鼻!!
垦丁
6.16
垦丁
屏东
台东
6.17
台东
台北
桃园机场

铁路地图那些事儿

这个版本的铁路地图网站上线两年了。最初,做这个网站只是想尝试做了上一版中一直想实现的瓦片图,瓦片图上线后面临研究生毕业,之后网站一直沉寂了两年没有更新。

2013年6月,因为不忍浪费网站很大的流量,开始开发空间分析相关的功能,包括列车路径、线路车站路径等等的功能。这些功能的基础思想都参考了上一版,但实现方式更互联网一些。

瓦片地图

地图数据来自各种网上公开的kml之类,人肉加工之后丢到数据库中。
瓦片图是自己了写的绘图引擎,画的是经典的黑白线。黑白线其实很简单,先画一条宽一些的黑线,然后再画一条窄一些的白虚线。地图是从0开始逐级绘制的,下一级的瓦片数量是上一级的4倍。网站上的瓦片图只画到了level 14,因为再往下画磁盘空间受不了了,反正够用了,是吧。
受不了的不仅仅有磁盘空间,还有网络带宽。最怕的就是用户拖曳地图了,那流量对2M带宽来说无异于DDOS。于是瓦片图是用一个专门的静态域名挂在 jiasule.com 的免费CDN上的,等图片资源全被他们缓存之后,就木有很大的带宽压力了。

列车路径

列车时刻表上是有里程的,根据客里表生成的铁路拓扑图上也是有里程的。列车路径是这么来的:

  1. 在拓扑图上DFS或者BFS的找等于时刻表上的站间里程一条路径,就知道火车大致是怎么走的了。
  2. 再将“大致怎么走的”用过查询客里表,解析成该径路上全部车站的列表,就更明确列车是怎么走的了。【以上工作在yupiao.info完成】
  3. railmap.cn通过api拿到一个抽象的列车运行路径(车站序列),将车站位置解析出来,可以得到一个折线版本的列车运行路径。
  4. 在地图上寻找相邻两站间的连线的坐标序列,在地图上展示出来就是弯弯曲曲的列车运行路径了。
yupiao.info搜索拓扑图的平均时间开销为每个车次40ms,为了不用每次都重新搜索拓扑图,把最近查过的列车路径缓存到了memcached。
railmap.cn为了加速从拓扑路径到地图上的曲线的转换,则是把地图上每个车站的位置,以及两点间的空间线段存到了redis中。

列车位置

承上,在任意时间,根据列车时刻,可以估算列车区间上下两停车站间的位置关系;根据时刻表上的里程,可以计算出列车距上下两个停车站的里程。再根据列车路径和客里表,可以知道列车当前处于哪条线路上的哪两个车站之间多少公里的位置。根据这个距离描述的相对位置,再去地图的空间线段上找绝对的坐标位置,就得到了该时刻的列车位置。
正晚点数据是要用来修正列车位置的。但是铁道部的数据信息量有限,只给出了晚点多少分钟。于是我们做一个简化处理,晚点多久,则展现多久之前的列车位置。列车晚点m分钟,当前时刻是n,实际位置用pos(time)表示,理论位置用ontime_pos(time)表示,则pos(n) = ontime_pos(n-m)。
有同学会说这样不准啊!对啊,是不准。等以后有了手机客户端,就可以UGC修正位置了。

网站流量

网站上线这两年来,得益于B哥的指导,SEO 曾经一度出奇的好,各种铁路地图相关的关键词在百度都排到第一,每天可以到4k的UV。对于一个只有一张首页的网站来说,这样的效果很是奇迹。列车路径功能上线后,开始从yupiao.info导流量,每天能导400个UV。

最近,整个网站莫名其妙的被百度大搜索干掉了,相关的关键词都木有流量了。不过每天依然有1k5的UV,还好吧。

12306最近修复的BUG们

最近半年关心12306不多,但也关注到他们陆陆续续修复了不少bug。他们也在努力,赞一个;但他们发现问题明显不够快,努力的程度明显赶不上互联网行业。

下面列举关注到的几个修复的BUG:
FIX: 查询余票时可以通过在列车等级和发车时间字段提交合法的随机字符强制刷新余票缓存
点评:遏制了抢票插件过快强制刷新缓存的势头。有修复这个bug的时间,为啥不修复一下12306缓存刷新过慢的问题?
*****
FIX: 通过修改接口可以使用“临时身份证”等证件类型
点评:遏制了某些人通过漏洞订第二张票。不过咱还有护照、港澳通行证、台湾通行证,天朝一个人可以办3本护照呢。
****
FIX: 用护照注册的账号可以给身份证信息的乘客订票
点评:那黄牛们就用身份证注册大批账号呗,只会给普通旅客增加麻烦,完全没用的策略。
FIX: 通过学生票的余票查询结果可以强制订成人票
点评:遏制了黄牛通过不正常渠道插队订票。
***
FIX: 同一乘客可以购买同一车次跨0点的两张车票 感谢 闫米参-CSQ
点评:普通旅客接票越来越难了,对黄牛基本木有影响。
**
2013.08.13日前后
FIX: 订票mmstr加密串加了一层base64编码,mmstr中加入生成日期防止隔日使用
点评:刷票不好刷了

余票网的那点事儿

yupiao 运营至今已经有三年了,逐渐由一个小网站变成了一个小系统。分享一些经验。
最初的网站是用asp.net写的,只是简单的数据获取和展现,很挫。后来研三(2012)有时间搞了python和django,逐渐才把 yupiao 搞的有点像一个互联网产品。本文也主要讨论2012年之后的事情。

服务器:

盛大云,当时在盛大工作的 Walter 推荐了他们的新产品,于是我就用一下吧,发现还真不错的说,就把网站搬了上去。后来中间因为促销优惠的原因,升级过两次机器。现在主服务器是华东 1Core + 2GB + 30GB + 15GB(云硬盘) + 2M电信网通双IP,服务器资源基本是榨干的状态。不过目前打算换阿里云了,有条件可以再考虑加台 Linode东京。
另外,参与工作的还有 BuyVM.com 在达拉斯的一台廉价VPS,CUGB ACM 的服务器,家中的廉价服务器……

爬虫:

余票的爬虫系统是一个通过 RabbitMQ 分配任务的分布式系统。爬虫在主服务器上部署 manager 分发并回收任务结果。在全球在不同网络环境下部署了多台爬虫 worker。
爬虫分布在教育网、米国vps、国内vps和国内adsl上。每个worker通过 rmq与主服务器进行任务和结果的交换,通过 api 访问基础数据,通过配置文件设置不同类型job的占比。gevent 保证高效的网络 IO 吞吐。其中一台为动态ip爬虫,通过自动重拨adsl实现IP地址轮换,抓取御策略强的网站效果极好。
说到爬虫,可以顺便提一下,我这里的数据应该是全网同步度最高的一份时刻表了。(但连票价模型都没做好……真是懒啊)

数据库:

主要是mysql和redis,redis里面放实时访问和性能要求高的数据,过时的数据存入mysql。
redis上的很多简单操作的QPS轻松万次以上,并且有成熟的持久化策略。列车和正晚点的数据主要放在redis上,列车数据并不很多,因此数据全部丢到内存中是很实惠的,redis内置的集合运算也让换乘之类关联查询的效率好很多。
mysql中的数据主要依赖django的ORM,很平常很普通。

服务:

http api server 基于 tornado + gevent,主要向web端和爬虫供应数据,包括一些远程查询及其memcached缓存(12306实时数据、天气、火车维基)。tornado和gevent相对轻量并且高效,有一些异步的特性,适合做api服务。
web server是就是django了,用到的都是基本功能,很够了。
下一次架构调整时会将比较重数据操作的部分独立做一个后端,现在这样的操作不多,所以暂时还是混在一起的。
最外层的服务是nginx,配反向代理到tornado的裸服务,用uwsgi驱动django。

备份:

看完上面的介绍,你有木有觉得,整套系统到处都是单点啊。不过,死翘翘也不怕,我有备份策略。系统代码是在Git上,所以不怕。数据库打包起来也只有几百M,每天凌晨时分异地备份一次,真遇到各种天灾人祸的话,换个地方搭一套就好了。

铁路地图:

单开一贴扯了,猛击:传送门