image.png

年度总结

  1. 2015年末总结
  2. 创建于 2016-01-04 15:01:49

“浮躁”是过去一年的基调。

2015经历了创业失败、毕业、应聘第一份正式工作，一切都来得很快，在冲动和被动中前行。
关于“创业”，其实自己都不确定那算不算一次创业，虽然是自己的idea，也是自己把产品从0做到了1，但从始至终。对于技术以外的东西，没有任何兴趣，当然一夜暴富的想法除外。后来，退出了这场创业。现在还时不时有人提起那段往事，但内心慢慢也看淡了许多，或许我只是想做个好玩的东西，就像个geek一样，而不是创业。面对资本、世故，我还显稚嫩，这一场过后，自己踏实了很多。

后来有一场短暂的初创公司的实习之旅，七月份毕业后，面对松散的团队，内心是惶恐的。仗着项目经验，信心满满的去面试了几家大公司，结果100%卡壳基础知识轮，这才明白，自己的技术是做得多轻浮，静下心来，默默的补了一个月基础知识。

8月是今年的一个分割点，纠结好久投了一份简历给芋头，投完很不是自信，半夜爬起又补发了一句，说道，自己基础还太薄弱，不想浪费来之不易的面试机会，等以后准备好了再来。没想到头哥居然回复我了，说他对应届生更加看重的是成长空间和技术热情。当时没多想，就回了句，“从未怀疑过自己对技术的热情，我想试试”。

这句话，也确实是大学四年的写照，热情是有，但更多的是浮于表面，浅尝则止。
来到大搜车后，幸运地坐在头哥工位旁边，开始面对远远比过去复杂得多的项目，当时的感受是面对着一个黑盒，无从下手。去尝试剖析这个黑盒成了这小半年的主旋律。
那时写完代码一上线，就感觉像是风筝断了线，当线上一旦出现问题需要排查的时候，会有深深的无力感，因为线上系统还没有一个完善的错误收集和性能监控模块。
利用空闲尝试做了一些这方面的工作，无奈宥于视野和基础知识，目前仅仅利用sentry实现了错误栈上传，12月份参加D2，听了QZone的日志收集方案，其中关于按请求和用户聚合的思路，准备在2016年实践下。

搜车的前端团队对新事物的吸收能力特别强，react、angular、web component、Flux等各种新技术都有被分享和实践。面对如此多的新事物，这小半年个人还是选择了坚持补node、javascript方面的基础知识，因为没有根基的大厦，风一吹就倒了。明年会选择性的尝试阅读几个框架的源码，感受下大师们的编程思想。对于流行框架，还是持需要才知道的态度。

对于2016年，希望

  • 对于node程序性能优化、线上集群监控、错误收集不再有心无力
  • 努力多赚点，存点小钱，准备人生大事
  • 学会享受每一个过程，工作、生活、旅行。
  • 把博客坚持下来。
  • 对女朋友好好好好好很多，争取得到5星好评

最最重要的是，2016年更加踏实点～～～

失望和希望

15年11月总结
创建于 2015-11-30 21:22:51

1）2015-11-15 21:26:12
最近不太敢去写代码，编程似乎一直停留在if/else。想写RESTFUL API SDK封装，想啊想，一个request网络库加一些结构化的配置，再加一个工厂函数，再加一些基础测试、性能测试，然后日后多加维护，似乎也想不出什么新意了。写的代码似乎没有了灵魂。
于是，害怕写代码，面对写下每一行都熟悉的代码，想问出个为什么要这样写，奈何眼界狭隘，思而不得。
下午听到大学几个朋友在beta咖啡讲Linux源码解析，就过去凑热闹。
大概记得讲了

  • 页目录、页表、内存之间的映射关系，
  • Linux源码内存初始化，进程fork的本质。
  • 还有线程和进程原理上的解释。

关于线程和进程，想起了朴大大的一句话，大概意思如下，面对线程和进程都不理解的人，没必要麻烦的打一堆比方去让其明白，一个写程序的人，这是编程的基础。然而，到现在我还真的不知道，
华哥说，当时他有一段时间也怀疑自己写的每一句代码，后来他选择了看更加基础和底层的知识，比如去阅读Nginx源码，Linux源码，去解答自己的疑惑。
以前自己也常说，编程是一种思想，语言只是一种实现工具，后来也听过很多大大也这么说，但思想的根基是什么，没人告诉我，所以似乎现在的我，也没有什么思想，语言倒是切换了很多门。
今天，有了一点点感悟，思想的根基是扎实的基础，具体点如，Linux系统的构成，内核源码剖析，数据结构，一些数学模型和算法；引爆思想的导火索，应该还是具体的需求，比如大数据分析的需求，恐怕现在只有BAT那种体量的公司才会有。
华哥举了个例子，说在他管理的一片机器集群里，有一次做了内核升级后，一些机器的Load抽风性的飙到满负荷。于是，他就给所有机器加了告警通知，然后不管半夜还是啥时候，一旦发现问题，立马ssh上去查证，然而很多时候，还没等连接上去，事故现场已经消失了。
后来，他们部门的一个女生也碰到了类似问题，但是她没有选择加告警的方式，而是统计所有机器的负载随着时间变化的情况，然后再去统计相关的业务特征、机器特征、内核系统特征，然后进行统计学和概率论的分析，最后当然解决了问题。
这或许就是一种由数学为基础、需求引导出来的思想，换做自己肯定也就是加个日志报错，扮演救火队员的角色，几台机器还救得过来，成千上万台呢？当然我还没有那种需求。
回归现实，面对现在的瓶颈，我能做些什么，先做好这几点吧，看看能不能有什么成长。

  • 回顾下几种基础的数据结构
  • 至少从原理上理解线程和进程吧
  • 好痛苦，为什么我会觉得Linux软件这么难装，编译和包依赖，到底如何解决，能不能有一天能够愉快的装上自己要装的软件，出了问题，除了看报错，还能有哪些方面可以怀疑。
  • LintCode一周一题，要求很低很低了。。