2019/12/24

goodbye eclipse

goodbye-eclipse

从大一开始自学java开始一路用到现在,终于要告别陪伴了快9年的eclipse。全部替换为IDEA

作为一个只索取不付出的码畜说来也有些惭愧,毕竟使用这么久,一行代码也没贡献,一毛钱都没捐献过,最多就是去网上问问对应的问题,提过几个issue。

因为其他地方都在使用jetbrains家的东西,整个切换是比较平滑的,2019.02这个版本已经相当顺滑,依旧使用了eclipsekeymap,换成dark plus的主题之后,使用起来和之前的eclipse也没差多少,一天写下来没发现什么问题。

除了这次较为成功并且不会再退回来(可预见的未来内吧…)之前,还有过三次的迁移,第一次是大二,当时自学java是为了安卓开发(结果也就大二学了点…做了几个没人用的app),尝试了下IDEA,结果因为小破电脑退了,不过当时的安卓开发在IDEA上似乎只是个插件还不是android studio,后面两次都是公司里,当时还是eclipse主流,现在基本都是IDEA了。8G的运存不能支撑同时打开过多项目(一个项目一个窗口,一个项目多module的使用方式),整体使用会比较卡顿。
但那时候还是很多人迁移过去了,可能信仰的加成比较多,看着同事一个智能提示要卡个几秒才能出来,但还是选择继续用着。

但之前2,3年电脑的配置就已经足够支撑了,运存也到了16G,硬盘也都是SSD,迁过去已经没有物理环境上的限制了。

但心里肯定还是对eclipse有点感情的,也因为习惯了各种操作快捷键,界面上倒是不怎么考虑,毕竟一个全屏写代码也看不到toolbar和menu之类的东西。

最终决定迁移的,还是因为文本渲染的问题。
https://bugs.eclipse.org/bugs/show_bug.cgi?id=536562,首先是之前就有的问题,有一定记录下,注释如果以非英文数字开头,缩进的显示会很奇怪,几个空格会被“压”在一起,但这种情况下,绝大多数连字符是正常的 ->之类的会正常显示为,还有些情况是缩进正常了,但只有少数连字符能工作了,绝大部分的箭头都阵亡了。
缩进不正常不打紧不过是注释,我更在意连字符显示,而且打开IDE又是那种十天半个月不会关的,一次打开连字符不正常多试几次就可以了。
然后上周看到出了新版,也周期性升级到最新,结果发现缩进的问题可能已经fix了(issue也VERIFIED FIXED了),然后这个状态下连字符爆炸。
在92楼已经有人发现这个问题:

It’s good, but still doesn’t support font ligatures because fMergeNeutralItems is false. so some font such as ‘Cascadia Code’ or ‘Fire Code’ has no completely effective. see also https://bugs.eclipse.org/bugs/show_bug.cgi?id=398656
The following code has been tested, seems ugly but maybe worth considering:

    segmentsText.getChars(0, length, chars, 0);
    // enable font ligatures and avoid ligatures between ascii and non-ascii chars
    scriptControl.fMergeNeutralItems = true;
    for (int i = length - 2; i > 0; i--) {
        char i0 = chars[i];
        char i1 = chars[i + 1];
        if (i0 > 255 && i1 < '~' && i1 >= ' ') {
            chars[i + 1] = 'A';
        } else if (i1 > 255 && i0 < '~' && i0 >= ' ') {
            chars[i] = 'A';
            i--;
        }
    }
    OS.ScriptItemize(chars, length, MAX_ITEM, scriptControl, scriptState, pItems, pcItems);

这就是所谓的修好了一个bug引入了个新bug。
去爆栈问也被人说箭头之类的连字符从来没有支持,附上截图后也没了回复,顺带close vote被投了一票。
也失去了耐心,刚升好级却看到了如此。恰好一些插件还没导入重新配置,索性主力直接切到IDEA
没想到箭头符号成为了压倒骆驼的最后一根稻草/(ㄒoㄒ)/~~

不过不得不说,eclipse本身没有网传的那么糟糕,很多卡顿问题并不是来源其本身还是插件,比如装了spotbugs又开启了修改后就检查,这样保存文件的时候就会感觉卡卡的,又比如一些优化极差的插件疯狂在workspace下的log里刷报错。
其实很多时候都是有点妖魔化的,一些较为基础的功能都可能被认为缺失,但其实都有,Ctrl + 3找一找就可以了(对应Shift + Shift)。很多诸如quick action可以在problemview里批量部分报错和警告的功能也不被人所知。
但细节上的确有很大差距,已经做了差不多两年的code mining依旧是个半成品,以及上面说的这个bug愣是改了一年半(不过受影响的主要是诸如中文之类的字符,本身重视程度也很低吧);EJC有自己的优势但是对annotation processor支持比较稀烂,等等。

也许之后的升级会再回来看看。
但现在就暂时告别了~
(我也是闲得蛋疼换个IDE也要写篇文… …

Written with StackEdit.

2019/12/14

如何处理业务上的较多表对接

handle-lots-of-data-tables
最近这2个月来的主要业务是和数据组打交道,将他们提供的各个维度的数据表(实质上是基于底层的各种事件已经计算并聚合过一层的view,这边统一用表表述)在接口层面进行封装为前端提供接口。简单写文回顾加总结一下。

场景描述

和一般的重查询的业务基本相同,但有个比较明显的问题是表的数目比较可观。
现在的业务已经涉及到了几百张表,主要是接入的领域,以及领域下的各种指标累加起来比较多。
举一个业务无关例子,比如用户访问论坛的行为,需要展示用户的发帖数,编辑数,回复数,查看数,点赞数这几个指标,功能上分为了单个用户的指标汇总,单个用户指标趋势和某个指标的具体实体排行榜(比如查看数是展示具体的帖子数),时间维度分为日,周,月,季度和年。
数据组会根据业务需要的指标给出对应的表,但他们给的表不会直接业务相关,所以可能发帖,编辑在一张表里,回复在另一张表里,查看和点赞在第三张表里,这边获取一个单用户指标的汇总就需要查3类表,其次因为有去重的操作,数据组会选择将不同的聚合时间段分成不同的表,于是根据时间的维度在这个方向上又会有5类表(当然时间段内可累计的话就直接日期表累加就好了,不可累计指的是比如在一周内7天都看了同一个帖子,那按每天累加的话是7,但是按一周内看的帖子应该是1),指标可能有不同的筛选维度,不同的维度也是不同类的表,比如可能需要按帖子主题,帖子分类,帖子用户所在地区这3个维度分类,如果维度间有交叉那所需要的表就更多,主题x分类,主题x所在地,分类x所在地,主题x分类x所在地等等,假设没有交叉,那就是3类维度表,那总的表的数量就是3 * 5 * 3 = 45,这只是单个用户的汇总数据一个功能。
对于上面为什么不同筛选维度要有不同的表,而不是全部放在一张表里,这其实是数据组底层实现的选择。一来是数据量过大底层会聚合过多的物理表,对之后的扩展和维护是个很大的挑战;另一方面则是数据查询的意义,你只设定了一个筛选维度,那要返回的是选定的筛选维度+所有其他维度的值的汇总数据呢,还是选定维度+所有其他维度的值的行呢(也就是你到底需要的是一个group by distinct sum 还是一个返回所有维度值的行),当然这可以使用类似特殊值的方式来区分;最后一个问题就是之后增加新的筛选维度怎么办,只在一张表里的话新增字段数据会翻倍增长。
如下图,当前只有两个筛选维度,各自都只有1这个值,我们用all这个特殊值来表示筛选项不指定的情况(也就是group by distinct sum的值)。
filter1 filter2 value
all all 1
1 all 1
all 1 1
1 1 1
那增加一个新的filter3会变成如何。
filter1 filter2 filter3 value
all all all 1
1 all all 1
all 1 all 1
1 1 all 1
首先之前的数据要先填充filter3是all的情况,接着要写入filter3的所有值,原来表的大小是(m+1)x(n+1),现在就会变成(m+1)x(n+1)x(z+1),m,n,z是筛选维度的所有值。

解决方式

初期

表的数量已经无法减少,在第一次接入的时候使用了之前的方式,结果变成了实打实的重复劳作机器,经历了漫长的半个月完成了一个领域的接口,但接下来还有更多的领域,以及会有一些额外的短时离线任务和长时离线任务,用这种方式不可控。
但在最开始还是大致摸通了一些规律,比如时间维度拆分的同类表有同样的表名模式,以及内部只有时间字段不同,相同指标系列的表的指标名都是一致的,筛选维度的同类指标表的指标也是一致的只有筛选项不同。

模式化

结合初期发现的规律,基础的解决方式有了一定的雏形。
不需要写每一个表查询,只需要抽取合理的模式。
  • 日期+指标类型决定表名
  • 选择的筛选维度可以确定路由到某张表
  • 同样指标类型的表可以共享字段名等元数据
因为项目安排比较紧的关系,在编码上慢慢往这个方面靠拢,但是还没有抽取出通用的方法。

现在

省略更多中间的探索,直接说下结论。
现在要接入新的已经有比较明确的编码流程。
  1. 元数据抽取和整理(这部可工具化):
    将数据组给的表进行分类和整理,在代码中定义表名,表名模式(比如user_posts_d,user_posts_w,user_posts_m,定义为user_posts_{0}),定义同一类指标的字段名,定义表名和字段名的映射关系。
  2. 写对应router,(筛选项,日期类型)-> 表名,这边要注意这个router是个通用的router,那种只选定一个筛选项,要返回其他所有筛选项值的功能还是单独写的(比如选中一个一级分类,返回不是一级分类的汇总值,而是底下所有二级分类的值)。
  3. 主流程。传入参数 -> 构建filter list -> 选择表名 -> 根据表名-字段映射返回需要filters。
上面举的例子中的45张表就在这一套流程中完成。
时间上有了很大的收缩,之前可能需要2个星期才能接入完毕的一套表,现在大致可以缩短到2天(毕竟还有其他衍生功能要做)。

总结

如上面括号里的,这一套方式其实有很多可以自动化的点,比如根据数据组给到的数据定义自动全面地(不全面的已经有了脚本)生成代码里的元数据定义,甚至router和最后的代码,然后进行微调,在理论上完全可行,至于实践层面可能就需要耗费比较多的精力,而且可能ROI不高,现在已经在用一些脚本自动生成些代码了,完整的工具的必要性和能提高的工作效率。
Written with StackEdit.

2019/12/05

又搬了一个新家

这两年来搬了第三次了,从最初的cnblogsgithub pages,再到这里。

从在线的平台到免费的自己维护的静态页面平台又回到了在线平台。

能随时打开浏览器,编辑内容不断保存,最后发布还是要比生成静态页面来得便利。
特别是笔记本不在身边的时候,而且就算在手边,一想到要打开笔记本,自己编写好markdown,构建发布就觉得有点消磨意志(虽然这个步骤很简单。 后果就是这两个月来想写点什么,但又什么都没写,给自己常用的几台电脑都装上hexo也不失为一个办法,但想着在单位的工作机上放着自己的博客还是不怎么合适。

也看了几个平台,还是选择了blogger,简单免费但也有不少扩展点,不用操心其他的事情,至于没有markdown,用stackedit就解决了。
之后有什么点子也可以直接写草稿,最后在发布,也不用把文章之类放在私有仓库在不同地方clonepush了。

应该可以稍微多写点把…应该
enter image description here