梦的碎片#70 | 青岛之行，一只猴子，ATRI
什么是梦的碎片？
一个随记系列，当有值得记录的事情发生、有新的未来计划，亦或是发生了重大变故。这些碎片都会成为推动或是阻碍梦想的一部分沉淀下来。
1.青岛之行
总感觉这个标题写出来像个游记……实际上是去青岛出差来着，此行是去跟总公司负责数字化的同事们交流学习、看看总公司在这方面的建设和经验。聊完发现即使是总公司，在全面数字化的转型里也是困难重重：积重难返的脏数据问题、各省区、地区的数据积累习惯问题乃至于当初和太多第三方合作开发的平台系统如何打通的问题。
不管怎样，于我而言，这趟出差拿到了一些我想要的东西、没有拿到一些我想要的东西、还有一些我想要他们也想要但是搞不出来的东西。我想要的直连数据总算是有了，但是只能通过公司的数据平台取得；我想要的源库API终究是没有要到，答曰数据保密和安全的双重考虑，暂时不给IT部门以外开放此权限；我想要的多平台联动数据，他们也想要，但是这些平台里的键值和字段实在是过于混乱，想要统一可以说是比登天还难。
于是大家一起讨论这些难题，这一周的青岛之“行”基本上也局限在这座能直接眺望海岸的会议室里了。
2.改用FineBI
我要是能影响总公司的采购，我一定尽一切可能劝说大伙购买PowerBI的授权，而不是这个半吊子的FineBI。然而咱们是FineBI的合作伙伴，而总公司也只在内建的FineBI上开放了我需要的直连数据——那么，改吧！
FineBI相比PowerBI，在复杂参数的构造水平上简直是天差地别。用PowerBI期间一再吐槽他的函数限制之多，这一问题在改用FineBI之后立刻得到缓解——他压根就没有这么多函数可用了。稍微举点简单的例子描述一下吧：如果希望筛选器（切片器）不影响同一个组件（视觉对象）中的某些字段，在PowerBI中我们只需要针对该字段设置REMOVEFILTERS 来取消特定筛选器的影响；但在FineBI中，我们只能构造参数，禁用筛选器和组件的关联，再把组件的特定字段绑定参数。看出区别了吗？PowerBI只需要对不需要被筛选的这一个度量值做设置，而FineBI需要对所有需要被筛选的字段作参数绑定。好在总公司用力大飞砖的方案，给了一个足够详尽和超级明细表，省去了很多计算，否则报表的转化过程简直难以想象。
吐槽了半天，稍微说点FineBI的优点吧。这玩意对导出Excel的优化和支持已经大大超越了微软自己的PowerBI，输出数据的规模大的不可思议，对于零售行业这种经常需要拉明细表来说确实非常友好。除此之外……不需要占用咱分公司预算了也算是一个优点？
3.阵雨、海
本来计划着没事干就去海边逛逛也好、去青岛的特色地标拍拍照也好，最终都因为持续不断的暴雨而不得不取消了。不知道是不是沿海城市的特性，天气预报的降雨预测对这个区域似乎完全失效了，于是养成了时刻把伞带在身边的习惯。
最终在离开青岛的最后一个下午，顶着看起来怎么都不会下雨的太阳，抽空去了趟海边。其实严格意义上说没看过青岛的海是不准确的，总公司的数据中心就是一个正对海岸线的海景办公室。但是总归比不上在海岸线上走一样闻闻海风的味道有沉浸感。随手拍了拍海岸线上的房子和对岸的建筑（考证后应该是
4.一只猴子
这个周末最热的热点无非是期待已久的国产3A《黑神话：悟空》。在发售前就饱受争议和讨论的黑神话，最终还是交出了一份基本令人满意的答卷。优秀的美术、音乐、战斗设计和背景故事，共同构成了这部作品的成功。其实抛开这些优点不谈，这部作品给我留下映像最深的东西居然是每一回结束的动画，用一种独属于中国的含蓄方式清晰的勾勒了每一回背后的故事，既隐晦、又清晰，还能让人回味无穷。
5.低开低走
ATRI的动画开播到第七集，已经从对它低开高走的期待变成了不要继续低开低走的恐惧。故事章节分割缺少重点、对原作的过度改编，让这几集的观感越来越下降。其实按照计划ATRI应该是ZeroCounter收藏集的第15号藏品，但是目前看来在动画完结前我能把它的鉴赏记录写出来的可能性不大了，只能奉劝各位想要看番的话，不如先去steam上买下原作体验一番吧。我个人的见解是，原作唯一的争议剧情、也是原作唯一值得修改的剧情，就是结局——所以我个人的见解是，目前为止花田十辉老师的一切改编，都是画蛇添足。
其实一直让人很难理解的是，对于已经公认非常优秀的原作，动画化的脚本家往往喜欢做些改动，仿佛这样才能体现他们的价值。这一点在异画天开的《三体》中凸显的尤为明显，且看起来仍然有不少脚本家要源源不断地踩这个坑。
小结
其实说到底，也许不存在是否要尊重原作，只存在对原作的理解和改写到底是否到位。
