为什么要在 WSL 上运行呢？因为今天在虚拟机里测试的时候偶然发现，云音乐的 Linux 客户端无视了大部分播放限制，比起 Windows 客户端要不知高到哪里去了。——这是一条新的路，不是俗套的本地代理。我一直是挂着代理用云音乐，但是毕竟代理有速度（勉强能接受）和隐私两个问题；还有一个无法下载封面的副作用。
发现了这个有意思的东西之后，我首先测试这是不是因为网络连接方式的不同导致的。如果两个客户端的内部逻辑是一样的，那么在不在虚拟机内应该不会影响可播放与否。除此之外就可能是客户端的逻辑不同了。不管是哪一种，都需要 WSL 来测试。WSL 和主机是共享端口和硬件的，所以不存在虚拟硬件，也不存在桥接，在服务器看来和其宿主是一样的。正好作为实验组。
为了验证猜想，同时也是解决代理带来的问题，我决定在 WSL 上运行云音乐客户端。
摸索试验花了五个小时（包括本文开始写作之后），大概有了一套理论，不过仍然有暗坑。使用注意。
主要内容是在1月10日写的，发到了漫版群里。想了想这个问题抛出来也不错。博客的版本有修改，加上了由我之后的若干条回复组成的补充，和 MLTD 部分。
正文修改部分：
“live”，要是准确翻译的话，得翻译成“现场演唱会”。但是每次都要把这么长的词讲一遍实在是费劲，而且土里土气。但要是简称“现演”的话……对，你们应该听过这相声，就不多说了。而且在手机游戏中其形式未必是演唱会。要是说“演出”，又太泛了，因为 live 特指唱歌跳舞的演出。作为动词可以翻译成“现场演出”，在常用语境中指的就是去表现这种艺术形式；名词是否也可以用“现场演出”，待定。所以暂时还是用原词“live”。
我可能会有用语上的失误和概念的不准确。这个我尽量用阅读百科的方式避免。不过如果发现了问题也烦请指正。
那么开始吧，手游的 live 怎么好看？（可愛くなりたい！）
（2D live 方面请咨询作豚索尔。索尔最近正好在狂刷各种各样的动画 live。←其实只要是2D动画都可以咨询索尔）
Game Off 2017 上的一个游戏。
玩了一下装饰器（decorator）。这是个好东西，但我还是没法实现 @Sealed 啊。
回想了一下 JavaScript 的入门，觉得经历挺神奇的。可以作为实用主义的体现。
受到 uTorrentAPI 的影响，我尝试使用了一下 WCF。之前在老周的一系列文章中读到过一点，不过由于讲的是比较深层的东西，所以感觉云里雾里。这次试用了一下，真是不错。
中文版见这里。
THE iDOLM@STER Million Live Theater Days (abbreviation: MLTD) went online on June 28 (UTC +01:00). Similar to its sister app CGSS, it uses CRI Middleware’s audio solution. More specifically, encrypted HCA audio. We must obtain the decryption key to reveal the contents of those audio files. In this article, we discuss the concept and procedure of obtaining the key.
Beware, MLTD does not have a game library for X86 processors, and it requires OpenGL ES 3.0. Don’t be surprised. So we cannot run it on normal Android emulators (there is one but it brings other restrictions), and we have to face ARM assembly language instead of usual X86 assembly language.
I wrote this article to share the thoughts and the method I used. I appreciate the way of hackers in 1960s-1970s. Challenging and sharing. Exciting. Hope this article lights up more inspirations.
Click here to view the English version.
MLTD（THE iDOLM@STER Million Live Theater Days，偶像大师百万演唱会剧场时光，俗称“麻辣土豆”）在6月28日（欧洲时间）正式上线了。在音频上，它使用的还是 CGSS 那一套 CRI Middleware 的技术，音频编码为 HCA。自然，这个 HCA 也是加密的，需要密钥解密。在昨天下午（欧洲时间，国内时间为6月30日凌晨），我成为了世界上第一个取得其密钥的人，然后这个密钥扩散到了日本和美国（似乎吧；我忘了triangle是在哪里的了）加拿大（感谢caimiao说明）的开发者手中。嗯，“第一个攻破”，这个感觉不错。上世纪六七十时代的先锋黑客们感受到的应该就是这种心情吧。
在这篇文章里，我就讲一下这次我是怎么取得密钥的。
CGSS 的master数据库的 live_detail 表里，有几个带“guerrilla”字样的列。研究数据结构的时候，第一眼看上去并不知道这是什么——一个萌妹子音游，和游击队有什么关系？转了好大个弯之后才明白过来，原来这是日替（每隔一段时间轮换的曲目）的意思……这么一想，大概就是取其中的“运动”义吧。
*这一条可能需要先了解 CGSS 的玩法，才知道我说的都是什么东西。*服务器 API 里有一个 /live/supporter，这个是对应在选歌之后选嘉宾（guest）的。这次通信在对应的通信实体类为 LiveFriendListTask（响应体，主要是其对 Parse() 方法的重载）和 LiveFriendListTaskParam（请求体）。在 UI 中，对应的是 LiveSelectGuestSelectList 类。而“supporter”，也就是“支援”，在游戏中是有其他意义的，就是那10个不上场、用援力加分的爱抖露，相关方法如 WorkDataUtil.GetSupporterList()。你看，有意思吧？三种称呼。我不知道这是否是一种人肉混淆法，反正它在反向的时候对我的精神造成了极大的损害。Cygames 的家伙们对这乱七八糟的分布，估计看着文档也够呛。
CGSS 目前有5种活动类型：传统活动、大篷车（caravan）、3+1（live groove）、协力（little party）、公演（live parade）。它们在代码中的名称分别为 atapon、caravan、medley、multiparty 和 tour。转晕了没？虽说我一开始并不需要知道哪个是哪个，但后来因需求，得分清了，所以琢磨了一下。问我为什么传统活动叫做 atapon？我认为是这样的：atapon 是“アタシポンコツアンドロイド”（Atashi Ponkotsu Android）的简称，而根据百科这是第一期传统活动的活动曲，写的人绞尽脑汁想不出合适的词，因此代码命名就这么定下来了。虽然现在你们看不到了，但是以前 atapon 可是曾经骄傲地拥有一整个命名空间的，非常抢镜。
不是我黑，但是上面的例子看起来都像是临时工的大作。真的。
当然，这不影响万代躺着数钱。
今天有一个需求。本地有一个代码库，我希望推送到自己的远程代码库的master（A/proj.git）作为存储；同时还要发布到另一个人的远程代码库，作为一个全新的、不带他的提交历史的分支（B/proj2.git），因为二者文件完全不相关。不过，B/proj2的feat分支现在并不存在。首先想到的方案就是，在B上创建一个孤儿（orphan）分支 feat，然后本地master直接 git push B feat 不就好了？嘛，被 Git 的各种机制坑了。
PS. 2016年8月到今年1月的文章，以后会放上来……
就在刚才，在重新组织项目结构的时候，见识到了一个 NuGet 依赖管理造成的bug。这个bug很隐蔽，症状让人莫明其妙，初见成功让我乱了阵脚。
我申请了新的域名 mottomo.moe，打算以后就将此作为包括博客在内的杂物的存放地。这个博客所使用的 DNS 已经设置将对 http://uiharu.moe/ 的访问自动跳转到 http://blog.mottomo.moe/。（DNS 免费账户的配额满了……所以只好忍痛弄了个 VPS，配置 httpd 来跳转。）
为什么要从 uiharu.moe 迁走呢？uiharu.moe 是我刚入宅不久还处于初春饰利狂热的时候注册的。后来我发现，将自己绑在一个角色上是不可能的。并不是说让大家都成为我的翅膀，而是因为他们都有着不同的闪光点，让人高度肯定。
说起来有点意思，“一番萌え”（ichiban.moe） 是在lan姐手上的。他（再一次指明，没写错）非常喜欢这个域名的 domain hack。当初是丧丝提出 ichiban.moe 的想法，好像是在一年以前吧，我记得。lan查到这个域名没注册，劝他赶紧买下来；丧丝说好贵不买，于是lan就将其收入囊中了。
为什么六月下旬到七月这段时间基本上没文章呢？因为储备不够啦！没有做出值得写的东西啦！六月毕业后游戏颓废了半个月，回家后也不知怎的效率低了许多，多个方面碰壁。
两个月前写的，吐槽一下微信的两个毛病。
2017-02: 好多积压的文章……