近期在技术上的进步
距离自己来新公司也快两个月了，在技术上收获不少。昨天在和老同学聚餐的时候，云铎问起我很久没写文章了，那今天就随手写点东西，分享一下我最近在技术上的进步吧。这篇文章会写的比较流水账，权当是给自己记个日记。我希望在一年之后，我在回顾今天的这篇文章时，能由衷地说道：“哦天啊王雨峰你那时候可是太菜了啊。”
最近主要在使用的编程语言是groovy，这是Java的一种方言，支持Java的全部语法，同时也是解释型的动态语言。这门语言写起来感觉挺好，很多特点能很明显感觉出来是为了程序员的方便而设计的，比如说，默认导入常用的Java库、一些非常方便的遍历语法等。同时也有一种奇妙的体验：我既可以像Java一样严谨地声明每个变量和函数返回值的类型，也可以像Python一样，给自己省点脑细胞，让程序自己去推断类型。
这感觉和golang的赋值有点像，但groovy在数据处理方面比golang更灵活，比如对于json的处理，groovy几乎不用提前声明任何数据的具体结构，但是在golang中（大多数情况下），你是需要先把json的结构声明地非常清楚才行。
由于我最近做的工作主要是数据搬运性质的工作，程序工作起来很过程化，所以还没接触面向对象的要素，不过这也是我自从大二上完Java课之后，距离面向对象语言最近的一次了。
说实话我觉得Java真的挺好的，实际上，我很少觉得什么东西真的不好。一旦当我产生这种想法时，我偶尔告诫自己，既然身为井底之蛙，就要好好琢磨琢磨怎么从井里往外跳，而不是走到哪都背着自己的这口井。
还有就是对Linux的使用有进步。我的工作，也就是数据的处理，主要是在服务器上进行的——因为数据量很大，只能让服务器来处理。
首先，我对tmux的使用熟练多了。其实一直以来我都会使用tmux，但之前都是比较轻量的使用，顶多在一个session里开几个windows而已。但最近的工作，对窗口数量和并发处理工作的要求变大很多，比如，我需要在同一个窗口中，同时运行脚本、观测系统性能、观察日志输出，那么我就需要分panes。其实都是很简单的操作，只是之前确实没有这个需求而已。这也是应了那个总是正确的道理：只有在真实需求和真实问题面前，学习的效果才是最好的。
还有就是对Linux的性能问题有了更多了解，也是被逼着学的。我们的数据在云服务器上进行处理，其实服务器的性能已经很不错了，但是由于种种原因（具体是哪些原因，仍然在探索中），经常能碰到一些性能上的问题。
比如，内存满了、swap满了，磁盘IO负载满了，load负载飙了，之类的。有一些问题解决了，比如磁盘负载的问题有望在下周得到改善，但有些问题，比如swap和load的问题，可能还没有明确地发现解决问题的办法，但是在研究问题的过程中，倒是学到了不少，比如load的值不仅仅包含running的进程，也包括处于io阻塞状态的进程；而swap的问题现在也不是很清楚（内存还有大量cache/buffer空间的情况下，os还是会非常用力地使用swap）。
总之，Linux的性能问题感觉是很有意思的，很多问题往深入看，就发现自己os方面的知识有欠缺，比如内存的交换、进程的调度等等。也许借解决这些性能问题的机会，补一补os方面的知识漏洞。
由性能问题引出的，我最近还给业务搭建了一个基于监控系统，其实监控本身并不复杂，但监控系统对项目的工程化来说是个进步。有了监控后，我们可以全局地、直观地观测系统中各个组成部分的运转状态，尤其将监控数据以时序图形的方式展现出来后，可以发现单独检查系统状况时所难以发现的问题，比如磁盘占用率的发展趋势等。
但是现在的监控仍然有一个缺失，就是对系统组件内部状态观察能力的缺失。比如，我想看到cassandra更详细的运行负载，或者脚本报错的频率等。对于后面这类需求，可能就需要引入日志系统了，这也是后面一个可能要做的事情。
还有一点进步是日志意识。刚开始做数据处理时，脚本的日志输出和日志留存都做的不好，以至于难以通过日志发现问题，甚至因为日志丢失而难以定位程序发生的问题。现在这些脚本的日志还比较简陋，基本都是println出来的，后面看看有没有机会把日志这块完善起来，毕竟如果能把日志集中管理起来，当然是最好的。
正则表达式，也是我最近的一个收获。其实之前也不可谓不会写正则表达式，但总是忘点这个忘点那个。最近用到正则的地方还是挺多的，比如匹配我想要的日志、匹配特定模式的文件名、写监控系统的报警规则等等。我在看《正则指引》这本书，其实只看了前3章就基本上能涵盖我日常工作对正则表达式的所有需求了，也就是字符组、量词和分组。
大概就是这样，也许还有一些边边角角我一时都想不到的东西，但是想不起来可能也就意味着并不重要。我非常喜欢这份新工作，公司的环境、身边的同事、工作内容的挑战，都很好。