xingo

论垃圾佬的养成，一次 NAS 硬件升级与客厅电脑的升级的流水账

Mon, 16 Mar 2026 00:00:00 GMT

起因

自 2020 年自组了 NAS 之后，2025 年 4 月份的某天下午，进行一个非常常规的寻找文件，双击文件准备打开某个 pdf 的时候，嗝愣一下，等了十几秒文件都没法打开，直到半分钟后，邮箱里传进来了几封报警邮件，一开发现掉盘了，而且仔细一看，好几封邮件，一掉还掉俩硬盘，心想我擦……这下坏事儿了。

情况可算是惨烈，自己组装的这台 NAS 用的是 xfs 的文件系统，在网上找恢复数据教程也啥都没出来，只有两个官方命令，先脱机然后挂载到 debian 下，然后 xfs_repair，这也就决定了要么硬盘全好，要么硬盘全毁。

其中一块硬盘好像没什么问题只是引导区掉了貌似，几秒就正常了，另一块就没那么好运了，提示无法修复，于是强行恢复后把磁盘上那些个扫出来的文件全部都拉到了 lost+found，结果还得一个一个去看文件内容才能知道是什么，才能进行恢复。

背景以及第一代自组 NAS

技术选型的时候倒也没想那么多，2020 年也是一次事故导致的想自组 NAS 的念头。在 2020 年前都是用的群晖 916，四盘位+x86 架构，能跑 docker 能跑一点点虚拟机其实也已经很满足了，但也有很多问题吧，一个是 nas 方面只起到了一个下载和分享文件的作用，硬解可以用自带的 video station 和 ffmpeg，但除此之外全是 cpu 软解，相当的卡（可能可以，当然也是我之前不会用来着）,另一个是运算上，我有一些用 headless chrome 的爬虫脚本，可以正常跑，速度很慢，也算能用，但每次升级 chrome 就会是非常头疼的一件事，以及跑 PT，因为怕日本的家宽版权原因，不敢直接挂 PT，所以我通了一层 wireguard 去做种，然而如果不小心把 image 给删了，很有可能要对里边的内容进行重新编译。

当然以上是不满的源头，导火索是我在新冠的时候买了一个 2.5G 的 USB 网卡，稍微整了一下驱动就在群晖上跑起来了，结果在两个月回国的期间，离回日本还有一个月的时间点上，手贱点了一下自带的网卡驱动升级…………于是，NAS 失联了…………在剩下的那一个月里疯狂去看各种自组 NAS 的代餐，

也是第一台自组 NAS 的由来，那同样两三千块我可以买一台更好的配置干嘛还用群晖啊反正我也就用那几个功能，其他的现有的系统也是点点点就解决了的事情。

硬件方案

第一代 NAS 的硬件选型是当时 2020 年比较乞丐的，

CPU: QSRL（Intel 10100T）
主板: asrock B460M
PCIE1: hp 561 flr拆机10G网卡
PCIE2: IT卡HBA模式直通卡
机箱: 用的 TANK 的那个小洋房，自带散热解决方案
内存: pdd买的寨条16g ddr4 x 2 → 后换成 crucial 32g x 2
电源: 益恒 250W 小1u

具体价格可能记不太清了，除了那个机箱 850 前后以外，内存大概 400 一根？，益恒电源大概是 270，因为收的也都是二手，整套也就 3000 吧应该。

当然组装第一台 NAS 中也有一些小插曲，比如闲鱼上收的便宜电源结果点不亮到电脑城帮忙调试一下确定是电源问题不是主板和 u 问题，收的第二台益恒电源发现线太短以及少 4pin 口子还是 sata 口子？（忘了）

转接线到货时间会比较长于是索性直接买了一台全新的反正也就 300 不到，点亮无问题之后带到日本后又发现装系统定时死机。最后跑内存测试连续跑两遍才出内存问题之后在日本也没办法退随即在日本煤炉上倒出去了（论我干过的缺德事，只能说 windows 比较强大吧内存有问题也能正常跑，所以这种寨条到底是谁在买）

所以中间也是有了很多的装机经验，比如内存不可以在拼多多买，就算买了也得连续跑两次内存压力测试。但也比较有意思的，在闲鱼上买的一个 SAS 8T 硬盘居然到现在还没挂，一直把他当垃圾处理所以放在下载池跑 PT 结果到现在也有 6 年了，之前就已经十万小时的通电时间了寿命也太长了……

当然今天回过头来看这些其实交了不少学费，还是不够垃圾佬。

软件方案

也算是看哔哩哔哩的 up 主们的抄作业吧，试了之后发现确实这样做很好也很符合自身需求，就是底层装 pve，然后开虚拟机装 nas 系统加直通硬件，这样的话其他虚拟机的运算任务基本不会妨碍 nas 自身的问题，nas 自己的任务就放在自己的机器里运行。

我并没有完全分离比如 nfs 或者 smb 拉出来然后在其他虚拟机上进行一个再加工这样，我还是会觉得有延时很怕文件会有 conflict，另一个是对性能上还是有一道心理过不去的坎，会觉得同一个主机上的文件我为什么要再走一遍网络层在那边加工的感觉好傻。

当然也在 nas 自己上不能解决的事情还是会分开来这样，比如另一个录制电视的 mirakurun 我就单开虚拟机的，他那个 recdvb 的编译莫名其妙就是 ubuntu 下能过，好多 debian 的系统也过不了，因为 debian 默认没开某些参数编译。结果 nas 的系统还是有这样那样的限制，那也是现在多虚拟机方案的好处。

nas 系统上选择的是 omv，起初一开始选择的是网红 NAS 系统 unraid，最终没有选择它的原因当然不是价格问题，当时才卖 99 人民币终生。当然定价问题是我对 unraid 这个东西将来发展的存疑之一，现在来看他已经回归正常定价还蛮 make sense，当时我对他的感受是诶有缓存池，有自动搬运缓存功能，然后文件是分散分布的，加上一个看起来挺合理的一个校验池，那么最后不采用 unraid 的理由还是那个采用的小众的 linux 版本，而不是用的人多的 debian 或者 fedora 系，又是闭源的，那如果驱动装不上，或者报错了，我又没办法知道是我的问题，还是驱动的问题，还是系统的问题。事实上在 pve 下的 6.11+的 unraid 就没有办法使用 uhd 630 分出来的 vgpu，开机死机（之后有没有解决不是很清楚）。那么我觉得最终结果就是还是会重蹈群辉的覆辙。

omv 这个系统上手后其实也就是个带图形界面的 debian 吧，正好卡在我的好球区，我对 smb/nfs 共享，以及一些杂七杂八的小命令记得不是很熟，那 omv 正好把那些都帮我做了图形界面，而那些我自定义的脚本 docker 容器等等又能很方便的去自己使用命令行启动。

最后最后采用的硬盘方案是 mergerfs，无校验。我当时自己觉得，我的重要文件都做了同步，每台电脑上都有一份不需要额外再进行备份，剩下的那些丢了可能也一辈子不会再 review 了吧，又能充分利用各种容量的硬盘挺好的。

对第一代 NAS 方案的反思

很多事情不试过不发生也是一辈子不知道，包括网上搜也不知道怎么搜出来。

比如 pve 或者其他的一些直通硬盘，PCIe 可以单独通，但是直连主板的那几个 SATA 口子是一起直通（能读到 SMART 的那种直通，也就是SATA控制器）的而不是一个口子一个口子通的，所以在策划硬件的时候也要想好自己的 nas 定位和使用分配。

又比如这次 xfs 文件系统挂了之后才觉得嗯，要找那些用的人多的，恢复数据教程或者就要做冗余的，至少要设想一下如果硬盘炸了是要一个怎样的操作方法去解决硬盘问题。以及也让我真正认识到了说辛辛苦苦收藏的那么多人类文明一旦某一天消失了，那也是找不回来的。 特别特别是 mergerfs 这个文件系统，上手时你觉得感觉硬盘均匀用的恰到好处，可以混合使用不同大小的硬盘，结果炸了一个的时候没有备份就只能看空文件夹在那边哭，或者 1.jpg，3.jpg，4.jpg 而没有 2.jpg 的那种空虚感。

掉盘后续

你很关心盘掉了之后我是怎么处理的吧以及那个坏掉的盘到底是什么情况吧。

怎么处理当然是一个文件一个文件看过去然后再把他们放回原来的位置 & 如果没有了就没有了咯。如果我知道哪些是没有了的，有些还能重新下的话就重新下了，最恐怖的是不知道什么文件掉了。那就，让他走吧。

关于原因其实我自己也不是很清楚，后来把丢失文件复制到其他硬盘上后我就把盘拿下来全盘扫描了结果是全部绿块没有坏道，SMART 就更是完全没有问题

唯一稍微有点可能性的是我的这套设备长时间（超过 5 个小时）运行后，就很有可能会发生无法关机的问题，无论是 pve 系统下还是 windows 下都有发生过，我开着 pve 的 log 查看后发现系统已经发出了 ACPI PowerOff 的指令但最后就卡在那边没有关机，另外在发出关机指令之前最后提示无法卸载/dev/的某个设备，给 chatGPT 分析了说是无伤大雅不会影响关机因为最后已经发出了 ACPI 关机指令了。

这个无法关机的问题还没查明白，那边为啥硬盘会炸也不明白。可能是让磁头没有正常归位的原因导致引导区或者寻道的一些这样那样的问题？如果你知道原因欢迎跟我联系。

不过反正不是 CPU 就是主板，就是直通卡或者 561flr 问题咯？（？都猜了个遍）另外这块炸了的硬盘格式化之后被我放到作为第二代 NAS 方案的冷备用了。

但是经过这次掉盘之后，我想我是必须吸取教训了，数据必须要备份，无论是做RAID也好，还是说unraid的snapraid方案也好，又或者是最傻的手动多媒体多介质备份也好，其实都是必须的，而不是说我就做了同步，剩下的那些内容就跟着缘分走吧。其实是不行的，有些东西失去了才会知道价值，然而数据无价。

第二代 NAS 方案

然后就很巧的是硬盘坏了之后的几个月之后的某一天忘了哪个平台给我推了个 epyc 7d12 的帖子还是视频吧（也有可能是我手贱自己搜的）

感觉很香啊服务器板 U 整套加起来也就 5000？正愁感觉原来的NAS拓展性比较差，这次性能拓展一次拉满。嗨没想到大船过海又过海，过完太平洋还得过日本海，于是说搞就搞。

硬件配置

硬件就直接抄的几个帖子的，我这边也贴一下自己的配置

CPU: EPYC 7D12
主板：SuperMicro H11SSL-i
内存：三星 16G * 4 DDR4 REG ECC
散热：金钱豹SP3
电源：长城巨龙 1200W
机箱：追风者 614
显卡：NVIDIA P4

当然因为是要保证在数据迁移过程中原本的那些脚本也要持续运行（我也是要上班的），所以还是又买了一个直通卡 + 561flr 网卡。

整套设备真的是可聊的太多了，首先大家可以去参阅一些我当时看的帖子 ↓

12盘位NAS机箱和AMD EPYC大船靠岸之存储整合方案
 ALL IN ONE NAS 主机升级小记-2025
EPYC7D12 8盘3.5寸机械+多盘nvme闪存【25G高性能】 NAS搭建方案分享
 数框框狂喜，AMD 霄龙 EPYC 7D12 捡垃圾
 家庭服务器Step ZERO to ONE 这个是 7542，但为了了解 H11 这个主板也参照了这个

首先这套设备除了显卡和 PCIe 设备是找 js 买的整机，整套 4500 出头一点。之后替换成淘宝图。看了上边的几个帖子里说 7D12 因为是 OEM 的流出所以 H11 的某几个 BIOS rev 没法点亮什么的，那想着要是自己买没法确认点亮的情况下也没法退就比较麻烦了。那花点辛苦费让人帮忙装机 + 确认也不算贵了。

托朋友旅游从国内托运带到日本来，然后我去机场接机带回家的。你问我为啥不在日本买，那日本人又没有流出这些东西的途径也不收垃圾啊……其次是淘宝过境的话过关是个大问题，我也不是很想拆盲盒，万一被退了或者收了高额关税那也不是我们垃圾乞丐的作风了。

其次是店家装机确实点亮了，因为没有买硬盘所以店家进了BIOS拍了张图给我就当是点亮了。

我一开箱发现 reset 键没法用，然后风扇有个没转，然后装了 windows 测机发现 64G 只点亮了 32G。

嘛本身也是要加风扇和硬盘的，于是把线全理了才发现这神装机。

然后之最后，我又把所有的配置都换了一遍笑死。

首先是内存点亮问题，几个帖子也说了 7D12 是特殊 U 只能点外边两个，然后 js 给我装的是里边两个，嗨 BIOS 里正常显示进了系统就直接只有一半了。骚操作还有把那个风扇集线器自己插上自己，倒是妹短路。也是服了。

然后就是整套设备开起来，哇靠那呻吟声音震耳欲聋，就最低转速已经身如机房，嗡嗡嗡的。金钱豹这个暴力风扇，转速也太高了，我估计店家主卖那些二手组装服务器给那些实验室做流体运算的，结果我要求改个 7D12 也是不知道其实是个 100W 都不到的 U。

开始只是想把这个风扇改成不那么静音的，也不知道有啥牌子的风扇是比较安静的，看那个形状还以为那个风扇是弯的好像换不了，直接找淘宝上卖 noctua 店家寻思问问啥大小的能换上去，店家直接给我推荐散热器了，店主真的很会做生意上来先说原价 500 多给我直接优惠 8 折，我网上一查发现啊确实比日本免税 and 其他淘宝店标价也要低，正好也有朋友要回一趟上海就一冲动直接买了。事实上后来我拆散热的时候就发现那风扇其实可以单独换，也就普通 12025 风扇。

换完了暴力风扇，就是整 P4 的散热问题，淘宝上买的 3D 侧吹的模具不用附赠的暴力风扇就算是 noctua 满速也是压不了 P4 的满载，于是只好把盖板拆了拿了两个 6025 风扇在那吹，那这样单槽卡就变成了双槽的厚度了，也是为了静音要做出的牺牲。

最后都整完了发现电源的声音比较大了，主要是空载室温 26 度时会有中频到高频的持续性的电流声，偶尔会伴有风扇刮到什么东西的摩擦声，而不开空调室温到 30 度以上时，电源的风扇就会很响，于是也又拖朋友正好换了个 1200W 的酷冷至尊解决。

内存其实还算够用，但也属于是抠着在用了，这次因为上了可以用 ECC 的平台的话就决定把 NAS 系统的那部分变成 truenas，毕竟是在卖给企业卖系统的话稳定性什么的应该是不错的。而且也看到很多人都在吹 zfs 等等。那么现在 16T*4 的一个阵列的话官方推荐最好要配 64G 左右的系统内存，但我也有其他虚机需要用到，所以内存我先是分配的 48G 的。巧也是巧偶尔手贱在日拍上搜了一下 ECC 内存，发现有人在卖 32 *4 的 REG ECC 内存，叠上平台券价格和国内也差不多，而且国内问了几家闲鱼和淘宝还说缺货。那就拿下换上了，也是一次点亮。

所以整个配置只有机箱主板和 CPU 是当初店家给我的，后来全是我又花了好多钱买风扇改散热改电源的，也是一身汗。

软件配置

pve → truenas zfs + 其他小鸡

两个pool，data pool 6盘位 RAIDZ2，下载pool就raid0啦

smfc

整体上沿用第一代的思想是底层 pve 然后加 truenas 来管理 nas 的文件，H11SSL 是带 IPMI 的主板，主板设置里设置成 optimal 就是消费级的自动了，但是不能拉曲线是比较麻烦，因为 p4 的显卡的温度是不会被 IPMI 给监控到的，因此风扇也是被控制的。因此要有一些工具进行一个读取 gpu 核心的温度然后进行程序化控制，我最后找到的是 smfc。

CPU Zone 是 FAN 数字，也就是FAN12345，GPU Zone 是 FAN 字母区，也就是AB。安装好 hwmon 和 nvidia-smi 和 ipmitool 的话配一下config就可以了。

另外我这边发现 smfc 启动时因为温度没有读到导致全部风扇置零，IPMI触发error后风扇满转速的问题。systemctl restart smfc.service重启一下就可以了，但是每次重启都会需要重启的话也是比较烦，可以添加一个服务。

systemctl enable smfc
# 创建延时重启脚本
cat << 'EOF' > /usr/local/bin/restart-smfc.sh
#!/bin/bash
sleep 5
systemctl restart smfc.service
EOF

# 设置脚本执行权限
chmod +x /usr/local/bin/restart-smfc.sh

# 创建systemd服务单元文件
cat << 'EOF' > /etc/systemd/system/restart-smfc-once.service
[Unit]
Description=Restart smfc.service once after boot
After=smfc.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/restart-smfc.sh
RemainAfterExit=yes
EOF

# 创建systemd timer单元文件
cat << 'EOF' > /etc/systemd/system/restart-smfc-once.timer
[Unit]
Description=Timer to restart smfc.service 15s after boot
Requires=restart-smfc-once.service

[Timer]
OnBootSec=15s
Unit=restart-smfc-once.service

[Install]
WantedBy=timers.target
EOF


# 重载systemd配置并启用timer
systemctl daemon-reload
systemctl enable restart-smfc-once.timer
systemctl start restart-smfc-once.timer

其他的话就是要注意一下内核的一些参数，zfs安装的proxmox已经使用/etc/kernel/cmdline，更新启动参数也是用 proxmox-boot-tool refresh，需要注意一下网上的其他教程。

P4 的使用教程可以看

在Proxmox VE下开启vGPU - Tesla P4为例
 vGPU在Proxmox VE下的配置与使用

证书自动更新

truenas下的证书自动更新本来想写个脚本，发现已经有人写了，就拿过来用了

https://github.com/danb35/deploy-freenas

直通

根据主板手册架构图，H11SSL的SATA口是可以进行分区直通的，果然是服务器主板，所以SATA口上接了系统盘，也同时SATA口是可以接数据盘的，注意位置即可。直通时可以使用以下命令查看在那个PCIe通道的控制器上。

udevadm info --query=all --name=/dev/sdg

第 2.5 代 NAS 方案

所以之前掉盘原因其实应该是没有办法究明了，因为 B460M 主板被我卖了，系统我也装成了 windows，开机一个月也没有不能关机的问题。不过我留意到主板上有个针脚有点歪了，也许是那个问题？

p4 → dg1

整体装好后，系统是没什么大问题，但是pve在2025.09推出9.0之后开始升级linux内核，也就是nvidia 16系的驱动会被deprecated，vgpu的方案很有可能之后是行不通的，不过我知道这个事情后才发现原来英伟达很早就计划废弃pascal架构的vgpu了。

well，暂时我只需要vgpu用来解码喂给chromecast，本来是想玩玩大模型和生图什么的，但是这样的话就存算分离比较合理，因为pve的系统和里边的truenas我毕竟是想要一直升级下去的。

于是我就各种狂搜，发现解码最好还是intel的卡，又低功耗，又便宜，就算不能sriov，直通进去总可以了吧，于是发现最强丐卡dg1，从此折腾没停过。

dg1是目前Intel独显之中应该说解码最好的，能打很多网游，加上支持硬解新款的AV1，对于NAS垃圾佬的话是极品了。

在买之前我就搜了很多，发现dg1是可以在pve下进行直通的，于是我也没有多看教程内容，dg1也便宜，直接闲鱼下单了三块。各版本都来一块。

两块是80eu，厂家不同，但是一块被动散热，一块是主动散热，其实发热并不会很厉害。96eu是俗称“满血版”dg1。其实dg1是英特尔Arc系列刚开始出显卡给厂商试试的版本，从驱动到点亮上都有着不少问题。

长话短说，经过插插拔拔各种折腾，三个版本都可以点亮和直通，但是稳定直通的条件是使用别人定制过的内核，但是怎么定制的没有公开。

PVE直通DG1/DG2并使用群晖SA6400驱动DG1/DG2教程

对于我来说，没有公开方法的内核比较危险，另一个pve在不停的更新，内核也会不停的更新，暴露在公网的服务，如果没有及时的update的话，也是很危险的。我在线上跑了两个月后，最后还是决定放弃了dg1而去升级我的系统。

其次，96eu版本非常不稳定，直通进truenas之后，确实是可以跑jellyfin的，但是24-48小时后，就没有办法再启动了。而且，重启truenas是没有用的，需要将整体的物理机关机断电，然后再开机才能够重新把96eu的这块卡给启动起来。

所以dg1这块卡如果用在windows的机器上，或者是不做虚拟化的话，还是不错的，但是谁不虚拟化去用这块卡的话，主板上不就浪费宝贵的一根PCI的槽吗。消费级主板本来通道就少，如果是服务器主板的话，不做虚拟化又太浪费了。整体系统构成也很容易翻车。

可惜了，我都把96eu的壳子给拆了然后去准备放进机箱的，谁知道翻车那么厉害。装回去然后又溢价卖给了日本人（缺德x2

dg1 → A380

A380是相比于dg1之后的第二便宜的卡，相比dg1，价格x2，可是驱动和做工的话都是正式版本。A380一般是双槽卡，蓝戟和先锋各出了一款单槽半高卡，在闲鱼上会比双槽略贵小几十。

插上后点亮直通都没有问题。暂时只买了一块，之后如果有需要的话我个人还是会考虑可以购入的。不过也有一点小期待，手里还剩两块dg1，万一pve后期适配了呢。

最终整体配置如下

CPU：EPYC 7D12
主板：SuperMicro H11SSL-i
内存：三星 32G * 8 DDR4 REG ECC
散热：猫头鹰 NH-U14S TR4-SP3
电源：酷冷至尊 1250W
机箱：追风者 614
显卡：Intel A380

不得不说整体装完后，这一整套的空载就是100W，我的天，日本一个月的电费就是下不了1w日元了。

对咯也上了UPS，那段时间有很多的消费活动，就全都买好买满啦。

附赠算力机方案

有了新机器之后旧机器该怎么处理是一个比较头疼的事情，原来是一台9代+2080Ti的itx小机器，但是机箱灯条有问题，也有点嫌弃了，想把淘汰下来的机器两台合并成一台。

正好乔思伯出了N5这个新机箱，就打算做冷备的同时还能当成算力机。9代卖了，新淘了一张二手的z490，哐哐就装上了。

CPU：10400T ES QSRL
主板：ROG Z490
内存：crucial 32g x 2 + 以前机器上淘汰下来的8g x 2 ddr4
散热：以前9代机器上淘汰下来的下压式猫头鹰
电源：银欣HELA 1200W
机箱：乔思伯 N5
显卡：dg1 + ASUS 2080Ti + NVIDIA P4

300不到的板子，收到手之后打算装机，掀开nvme装甲一看，哇靠一块500G的三星970 EVO？开盖有奖了啊哈哈哈哈哈哈哈哈😂直接回本。

而且ROG的这块板子就是好啊，有5条PCIe的插槽，SAS卡，10Gbe网卡，加三张显卡，一整个满满当当，Wifi模块还被我用来转接了NVMe。太酷啦。

使用dg1启动旧pve的时候有可能会报PCIe的总线错误，可以参考一下 Claude 是怎么解决这个问题的，我很奇怪我的大号机就没有这个问题。

https://claude.ai/share/675ea345-7acd-478f-b69b-8fcd779c65b0

在系统选择上，一开始是想用PVE+直通进行一个鱼和熊掌兼得的想法，然而腾讯等各种反作弊系统是不答应啊。

打造 All in One 主机之让虚拟机也能通过 EAC 检测

PVE使用Windows的话，鼠标和键盘如果直通给Windows，使用一会儿休眠就没反应的话，记得去硬件里边把休眠给关上，节能设置里也要关掉。

那么想想算了，这种都是道高一尺魔高一丈的猫捉老鼠游戏，于是考虑WinServer为底层，用Hyper-V去开omv。但是我都已经研究到了怎么直通HyperV的过程了，发现有个蓝牙的手柄驱动怎么都安装不上。趁还没完全开始装其他软件，重装到了Win11看，发现，没这个驱动装不上的问题。这可又让我心凉了一大截，好吧还是老实Win11 Pro梭哈到底了。

【Windows使用】之--Hyper-V网卡、显卡直通等PCIe硬件直通
 Windows Server 2022でもGPU-Pしたい！

Hyper-V启动OMV的时候记得要用传统BIOS，以及Windows 11下是不支持硬件直通的，所以每个硬盘要单独挂载。

最后提一嘴，因为有多个硬盘，也不是做raid，希望我的冷备机的数据管理和原来omv下的mergerfs类似，但我不可能开着那样的HyperV虚拟机进行拷贝数据，以及打游戏的话肯定是不能开着HyperV的。于是我搜索发现了MergerFS在Windows下的Alternative - StableBit DrivePool。软件不贵，是买断制的，也可以试用30天，还不错。

后记

其实10月后就已经把整个构成完成了，但是买的三星NVMe 990Pro 2T带Heatsink的，经常有不断电就会掉盘的情况。不应该说掉盘，东西还在，但是如果不断电，主控就没有了反应，关机重启之后就又回复了正常。一开始还以为是买的PCIe转NVMe的板子有问题，后来更换了位置还是发现这块盘每过28天就无法读取SMART而掉盘。拆下来本来打算送修，后来网上一搜发现原来固件更新，日志写的也是相关问题，于是再插到算力机上进行更新这样。无语，我算力机的插槽也是满的啊，又是一顿折腾，还错把算力机的系统盘给拆下来格式化了。这么长时间没有更新呢，也是因为想要看这套装置稳定性如何，不过前前后后也有大半年了，也经过了好几次我忍不在家的情况，似乎没有什么太大问题了，感觉是可以公开给大家看和参考了。

这么一算我手上其实有7条NVMe的SSD了，谁知道2026开局居然PC配件大涨，内存涨SSD涨机械也跟着涨，不知道是该庆幸自己买得早幸运呢，还是该说奸商无德呢。

本文尽量去模仿梨数码的文风，希望阅读的你能够像看小说看笑话一样的阅读完本文，轻松又有干货。

这篇时长纵贯整个2025年的 nas 升级，前前后后折腾了不少，花了钱买了不少的配件，也花了自己很多的精力，尤其是在边减脂边打比赛的同时还去绞尽脑汁抽出时间在工作闲暇空隙去完成所有的事情，本以为应该也是非常值得骄傲的事情，但现在回头来看机器装好了，也懂得了很多知识，踩过了很多坑，然后呢，这些内容似乎对我的将来好像也没有什么重复利用的价值了。唉，感慨一下吧，以后就知道了，时间应该有更重要的事情去使用。

一些实用小链接

CPU Benchmarks 用来查 CPU 评分 TDP等

2026-02-05 随笔

Fri, 06 Feb 2026 00:00:00 GMT

感情它一阵一阵来，也不知道他什么时候来，一涌上心头，我便难以集中注意力

昨天我开了某个交友软件的付费会员，这是我人生中第三个付费的软件。第一个是滴答清单，第二个是管理饮食的MyFitnessPal。其实目的还是蛮简单的，我今年30，那我觉得27-34这个范围应该是聊得来可能性最大的人群，于是去定向查看那些人的话，应该可以更有效率找到和自己类似经历，类似爱好，类似想法，并且“看得过去”的朋友吧。我承认不是好人，我也是看脸看身材下菜的人。

我对感情这件事情觉醒的很晚，怎么说呢，我在高一高二时喜欢过同班男同学一次，不过分班后也没有办法继续，只好自己被窝里大哭一场，也就过去了。在来日本之后的第一年的后半年，认识了一个二次元的朋友，前期我也看出来对方对我是有好感的，然后因为太喜欢了，讲了很多不切实际的内容，可能就把对方吓跑了，直接被绝交了。我总是善于把那些大顺风局打成逆风局，我把上天馈赠与我的礼物扔在一边，暴殄天物，把人际关系搞得一团烂，这一次也不例外。

当我开完会员，我意识到软件上我喜欢的人应该不会喜欢我，而喜欢我的人我也完全看不上了，我又开始后悔开始绝望。

我是个罪人，我去翻看我们的聊天记录，当他对我善意提醒我却恶语相向，当他发出求救信号我却含糊其辞。软件上的其他人问我，是不是回避型依恋，我根本没有说我们之间的任何事情，我问他是怎么知道的，他说他也是这样的。我懂了，原来我不是焦虑，我是依恋，我不是焦虑型，我是回避型。当他对我告白的时候，我总是想着怎么往后拖，怎么维持我们朋友的关系又不伤害他喜欢我的那颗心，但我只是在回避我自己对他的那份真正的情感。当时我认为我的生活只需要朋友和炮友，炮友负责解决性上的问题，朋友负责解决情感上，交心共情，以及日常娱乐的部分。我当然知道朋友的感情很重要，但我开始把一切当成理所应当，天平自然也就一方倾斜。

其实他在跟我告白的时候我也预知到我们这段关系可能走不远了，我自以为我的处理方式应该比较妥当，我自以为我也投入了很多感情，然而我还是犯下了一个又一个的错，他给了我挽回的机会，我却主动拒绝了，而去追一个身材好却毫无生活交集的小朋友，然而见面当天我就决心不再继续喜欢那个人了。我是不是贱呢？

后来有朋友当着我们俩的面问我，为什么他没有来看我的健身比赛，我说观众也要付费所以他没来，朋友说没事xingo会出钱的。我当时就呆住了，我，我确实应该这么做啊，我在这段感情里确实不知不觉索取了太多，但我好像很少主动想到要为别人做点什么。其实也是想的，但总是觉得以自我为中心，自己不要的东西去送给人家，自己要的东西根本没有想过分享过。

断联的那几个月，我又是招待爸妈，又是工作调动，又是薅尽羊毛，也有去试图给其他软件上勾搭我的人一些见面机会，闲暇时间也会去偷偷视奸对方推特主页看看风吹草动，我总是把自己的生活排的满满当当，让别人无从插缝，却又让别人以为有机可图。我真是有罪，我罪该万死。

这一个多月来我还是没有恢复到之前的状态，我早晨起来我还是会毫无目的地刷各种社交软件，小红书，推特，instagram，6点醒的我刷到7/8点，4点醒的我也刷到8点，我好像觉得自己心口堵，也想说点什么，AI跟我说让我写下来，那种状态我怎么静下心来去组织语言，去把我的话给想清楚写明白，还是不要给我添乱了AI。起床后到晚上坐在电脑前之后好很多，虽然工作没法像之前那样效率那么高，工作时间中也是到处看SNS，情绪上总体是稳定的。我以为我已经开始好起来了，然而看到他发动态我也还是有点欲言又止，看到另一个人的头像，我会心头一紧。他是答应了还是当朋友关系，但，还有更多的事情，应该是为了避嫌，可是这已经不是我心中的那个要好朋友的等级了，也总有一天互相不再会假装是对方的朋友了吧。

可能是被日本动漫毒害的比较严重，我一直认为的人际关系会有几个阶段，陌生人，认识的人，普通朋友，要好朋友。而普通的网友，你一句我一句的，我可能会把他放在认识的人或者普通朋友的关系里，普通朋友的这个阶段，可能是我会找到我们的共同话题，而我只会分享那些内容到这些朋友上，其他的我的内心话题都不会说，当然我本身也不是那种会展露出自己内心的人。毕竟我在日本6年多我独来独往，没有在这里上过学，生活两点一线，上班的日本人界限分明，当然也就不会有任何社交机会。因此要好朋友自然是0人。而我没有想到2024年的11月初老天却让我认识了一个从生活成长经历，到工作经历，到喜欢做的事情，到性癖都出奇一致的人，自然是互相吸引，关系发展迅速也是不出为奇。对我来说，我们有很多共同点，而他身上也有太多让我欣赏的点，我有时会嫉妒，而他也很包容。他以真心待过我，只是我理解得太晚。每个人对朋友这个词语的理解不同，在其他人眼里那样的要好朋友可能已经是亲密关系，但我也只能打碎牙往自己肚子里吞，当然就算是我的要好朋友的定义来说，我也付出还不够。

最终还是错过了，当时想要的朋友关系，现在求仁得仁。我现在的懊悔感，失落感，无力感，是理所应当的惩罚。我不会怨天尤人，理智知道自己应该回归正常生活节奏，这样才有机会遇见下一个更好的，而在早晨和晚上，那些开头的后悔与绝望又占上心头，让我的脑中充满了负面的想法与行为。软件上的人有些脸好，或是身材好，却与我似乎风格格格不入，又或是完全没有话题可聊，再也没有共同爱好，又或是一开口就满嘴哈哈，想要掩盖那些没有共同点的尴尬。我很怕自己成为《被嫌弃的松子的一生》的主角一般，最后死在堆满垃圾的自己家里而久久无人发现。我怕自己像是《野良神》里的无名神，被人遗忘之后再也无法重新复活。我痛恨那些以前让我没有好好与他相伴的破事，我开始讨厌做一些浪费时间不感兴趣却又只带来一点蝇头小利的案件，我甚至听到某些地名，某些事情，看到某些照片，也会让我起鸡皮疙瘩，产生生理性的厌恶。我在日本的家附近看了心疗内科兼神经科，医生听我说了一堆，然后问的是，我什么感受，想开什么药，我不知道该回什么。一开始我有过反抗，叽里呱啦给他发了一堆，他也很好没有对我任何过激词语，只是一次又一次之后我觉得他应该也是累了，我也开始学着把自己的情绪如何再像之前那样藏起来。

我们仍然还可能会见面，但我不知道哪一次会是最后一次，我把每一次都当成最后一次见面，我还是希望把我最好的那面展现给他看，只是那天独处没有说出口的话，也再无价值。

我把我instagram链接到threads上的链接给隐藏了，反向也是，我知道可以通过搜人名看见，也知道threads自己会推荐，本身贴文也会被推荐到别人的首页，只是想要避免一些认识我，但还没足够了解我的人，让他们以为我是个疯子。

一切都已经过去了，我不知道还有多久才能回归自己，但是再不快点我的工作可能很有危险。

谨以此文纪念我不成熟的30岁与一份逝去的至高友情。

原文在2026年02月05日晚发布在我的 Threads 上，略有修改

升级 Jellyfin 到 10.9

Wed, 28 Aug 2024 00:00:00 GMT

前两天刚谈到用 nyanmisaka/jellyfin 的镜像做的 Jellyfin，但是 Jellyfin 的 Android TV 版本升级到最新之后只支持 10.9+ 以上版本的服务端，虽然也能把 Android TV 版本的 Jellyfin 降级到 10.8 兼容版本，但 Jellyfin 更新勤快，降级 TV 版本只是最后保底之策，将来如果有其他新特性，那么长痛不如短痛赶快升级到最新版本才是上策。

TL;DR

从零重新根据向导起环境 + 设置库才能获得最正常的体验

尝试直接升级到 jellyfin/jellyfin 镜像

nyanmisaka 镜像是在官方镜像上进行的修改因此数据目录和官方镜像一致，可以直接升级，docker-compose 修改 image 值，compose up 一下就完成了。

但是发生了以下问题

播放时不调用 GPU 加速，CPU 100%
只有 Android TV 客户端在播放时中文字幕乱码，表现为口口口
部分番剧的 Extra 消失，或者上层文件夹并不是 Season X 的标准文件夹也会被吸收进正片一个文件夹并被刮削成标准集

播放时不调用 GPU 加速，CPU 100%

我的 CPU 是 10代 UHD 630，在查看 Intel 支持后发现并不支持 AV1 的解码和编码，因此要将硬件加速部分的 AV1 的解码和编码部分的对钩去掉。

客户端再次播放时服务端调用了GPU，CPU的占用也得到了改善

中文字幕乱码

在 nyanmisaka/jellyfin 的镜像的说明中，已经添加了中文支持，而且我也为了部分字幕的效果有设置了备用字体。

但在原版镜像下，即使我启用了备用字体，字幕还是乱码。

然而在网页端和在官方 Android App 以及第三方 Findroid 播放时没有乱码。

反复查看官方文档也表示，字幕依赖客户端字体，乱码在开启备用字体后就能解决。

最后抱着尝试性的心态在容器内安装了 CJK 系统字体，重新启动 jellyfin 服务端后，Android TV 客户端已可正常渲染字幕。

apt-get install fonts-noto-cjk-extra

Extra 文件夹不显示

没找到解决方案，没有人提 Issue 也很奇怪

更换为 linuxserver/jellyfin 镜像

因为用户权限问题，最后还是更换为了 linuxserver 的镜像

但是数据文件夹结构不同，首先参照此 issue 手动调整目录结构

然后修改 docker-compose.yml，添加安装字体包

最后

正常启动后发现无法修改库的任何配置，最后删除了数据文件夹重新扫描重建了库（寄）

2023 你的名字飛騨高山圣地巡礼

Sun, 18 Aug 2024 00:00:00 GMT

一直很想把君名的山里的部分也巡礼一下，总算在2023年8月和朋友一起去了飛騨，把照片都拍了，住了一晚但第一天坐的夜巴所以实际上走了玩了两天。

年初的时候已经在微博上整理了几张，今天把对比都都好好整理一下。

飛騨古川駅后边的天桥上

放一张沉浸式的

然后是立花泷出车站

车站前

剧中的图书馆其实是飛騨市图书馆

电影一开始的宮水的部分

这边最开始镇上回家的聊天，道口这边不能进铁路线拍，所以应该差不多是横过去看的感觉，可能也不一定是这个道口。

飛騨古川駅隣

飛驒市立古川西小学校

巡礼的时候电影已经上映了快10年，但去到偏远乡下的圣地当地还是张贴了当年的海报，以及很欢迎别人来参观和打卡，还特地放了留言本等等，还是很有意思的一次巡礼。

2024 年如何中间人 Android 网络请求

Tue, 09 Jul 2024 00:00:00 GMT

不像 iOS，在 Android 下，设置完了代理并安装与信任了自签证书后并不能让 Apps 信任被中间人了的网络请求。这篇文章是记录了 2023 ~ 2024 年我是如何中间人 Android 的网络请求的。

背景

Android 从6版本开始，系统就会默认所有 Apps 的 https 网络请求都变成了只信任系统区证书，而不相信用户自己安装的证书。这提升了 Android 设备的安全性，但也让我们无法再简单的窥探 Apps 的请求内容。

以前我会使用 Xposed Framework，但 Xposed 好久不更新，后继的 LSPosed 等等也是风波不停，只是为了中间人 app 的请求，是否有更优雅的方式。

apk-mitm

这是唯一非 root 也能使用的工具，原理是反向apk后植入hook并动态信任 https 请求。

好处

不需要 root

坏处

webview 的内容无法被中间人
App 可能并不会按预期的工作

Frida

专为反向而生的 Frida 在运行时hook内存并强行信任证书。

手机端准备工作

下载对应的 binary 推送到手机

# 16.1.8 改成对应版本
adb push ./frida-server-16.1.8-android-arm64 /data/local/tmp

切到 root 权限进入 adb shell

adb root && adb shell "chmod 755 /data/local/tmp/frida-server*" && adb shell "/data/local/tmp/frida-server-16.1.8-android-arm64 &"

要注意 Pixel 等手机有时可能在 adb root 时报错

adbd cannot run as root in production builds

使用 su -c 或者一行一行手动敲命令↓

adb shell
# 进入 Android shell后切换超级用户模式
su
# 付与 frida server 执行权限
chmod 755 /data/local/tmp/frida-server*
# 启动 frida server
/data/local/tmp/frida-server-16.1.8-android-arm64 &

# 按 Control + C退出
# 敲两次 exit 退出 shell
exit
exit

至此手机端的准备工作就完成了

电脑端准备工作

电脑端也要安装命令行，首先安装 Python 3后，执行

pip install frida-tools

结束

启动脚本

Frida 服务器只是监听内存并劫持，在启动时也需要指定动作，我搜到的一个比较全的脚本是 frida-multiple-unpinning

启动命令

# apk.packagename是包名
frida -U -f apk.packagename --codeshare akabe1/frida-multiple-unpinning

同时，Frida 也支持 Work Profile或多用户，添加--aux="uid=(int)10"参数来启动

frida -U --aux="uid=(int)10" -f apk.packagename --codeshare akabe1/frida-multiple-unpinning

10 代表 Work Profile，多用户的情况下可以查看用户 uid 后打开即可。

执行命令后应用自动启动，此时 SSL 已经被绕过并可以使用 Charles 等分析请求内容。

References

It's all about Bypassing Android SSL Pinning and Intercepting Proxy Unaware applications.
Android | Frida

聊聊管理番剧动画片这件事

Mon, 08 Jul 2024 00:00:00 GMT

我刚开始看动画的时候也是B站或者优酷这些流媒体看的，最开始从国外录电视，翻译添加字幕重新压制再上传各个视频网站然后被我们所观看到。之后就各种政策变化，以及有了一些版权意识之后，一些没有引入版权，又或是动画本身有一些镜头并不符合国内情势被剪辑的事情发生之后，我看动画的方式就从在线变成了找资源下载看了。而后又对DVD，高清，蓝光等事情产生了兴趣，以及喜欢的动画如果想再回去看看的话又不想每次再翻回去看这一点之后开始研究 PT 等等的事情。

与此同时也购入了人生第一台 NAS ，群晖ds215j之后，到我卖掉我的DS916这期间，找番看番离不开动漫花园和幼儿园等网站，但也只停留在下载，使用 PotPlayer / IINA 播放阶段，即使之后一个人生活也是在客厅里放了一台电脑接上电视机观看。

搬新家之后买了很多新的家用电器，攒了很多家电积分后没有想买的东西了，于是去买了个原价率最高的「Chromecast with Google TV」来玩，但接上后发现完全就是一个播放流媒体的工具，然而下载党 & 抠逼并不愿意为流媒体多付一分钱的情况下研究播放下载了的番剧，但群晖自己的 Video Station 会预转码占用硬盘空间，加上也没有系统性的整合剧集非常不好用，以前对转码的认知也停留在很肤浅的阶段，认为转了码画质就低下了，所以大多数情况下也还是继续打开电脑来播放下载的动画。

又过了两三年左右我自己使用 OMV 为底组装了自己的 NAS，一方面想着如何盘活客厅里的 Chromecast ，另一方面从开电脑到打开共享文件夹从乱七八糟的PT的文件夹名找到自己要看的番剧到找字幕解压再看其实步骤很多，对心理负担很大，会容易让自己不太想看电视了。因此能否使用简单操作快速播放 NAS 中的番剧文件，并且还要能实时转码推流，并保持做种是做这件事情的目的与动力。

以上就是这篇文章的背景，那么开始动手。

jellyfin

大数据果然没有让人失望，在组装 NAS 的时候就给我推送了很多有关这方面的文章，而我让我了解到了 jellyfin 这样东西。

关于 jellyfin 是什么，大家 Google 一搜就能搜出来了，他对我的好处无非就是

实时推流
支持外挂字幕
喂影片数据简单

jellyfin 如何搭建这个应该没有什么问题吧，最简单的 docker compose 一起就好了，唯一要注意的是硬解的话 docker 内驱动要装好我现在用的是 nyanmisaka/jellyfin 的镜像，已经带了 Intel QSV 驱动，但是最近 jellyfin 升级到了10.9+，而他的镜像还没更新，也许之后再不更新的话我可能就会换回 linuxserver 镜像了。

插件

Bangumi

这个插件可以让jellyfin自己搜索到 bgm.tv 上的数据下载展示，而不需要手动去喂数据制作 nfo 文件了。

Kodi Sync Queue

这个插件是用来同步 Kodi 和 jellyfin 的内容，在 kodi 中也能看 jellyfin 的内容，具体在后边也会说

硬链

那么 jellyfin 有了之后我们不能让 jellyfin 在原来的文件夹里大做文章，首先问题是很有可能无法识别，如果下载下来的视频文件名太过奇葩，jellyfin其实有可能无法识别集数。但最要命的，其实是那些个PT文件夹名，那种真的是jellyfin完全查不到的话也就不会jellyfin中显示，或者乱显示了。同时源文件夹也会乱乱的，整理起来也会更乱。还有一些什么蓝光带的无字幕OPED特典啊，访谈啊什么的也会被jellyfin抓取，但又识别不出来的话或者被乱识别的话也没有办法在jellyfin自己的系统中好好显示。

那么最妥当的办法是，硬链一个出来之后把那些不要的文件删除，只留下推流的东西就可以了，如果识别不出来再把文件名改一改就可以了。

首先是硬链，我现在用的工具是 hlink，配置好源文件夹和目标文件夹后点一下启动几秒钟就做好了几千几万个文件的硬链，同时默认配置已经是符合jellyfin的那些文件了，其次这个工具可以配置缓存，硬链过一次之后，源文件不改的情况下，下次启动任务后都不会再硬链过去，也就是不会把你整理过了的文件再让他们重头多来一次。

重命名

大多数情况下，jellyfin 已经可以识别季数集数，但日本的动画其实很不系统，有的时候算季，有的时候一开始就说要做多久的动画所以就没有季，有的时候呢换个名字出续集，bgm.tv 的数据和老外的AniDB的数据也有时并不一致。季的问题还算好，总集篇的问题可真让人头大，有时算 0.5 集，有时算中间集，有时不算集。各个字幕组或者是压制在做的时候也是各做各的。

因此有这样那样问题的存在也就导致了并没有办法可以全自动的去对这个动画重命名，但能够用脚本去做的事情还是自动化掉，这样看剧才能看得舒服。

收拾 Extra

首先要收拾的就是那些OPED啊，送的特典视频啊，什么访谈啊，什么CM啊，新建一个Extra文件夹扔进去就行了（不看的话删了也可以）（我相信没什么人会看的）。

Episode-ReName

一般来讲粗看一下如果集数和bgm.tv的一致的话把字幕文件和视频放在一起，文件名保持一致也就不需要重命名了，但有的时候首先视频的集数要是和bgm不一样，或者季不一样，又或者字幕文件和视频文件不是一个文件名的话，那我推荐这个一键脚本，做的算比较好的，把要重命名的视频文件和字幕文件放在s1或者season 1类似于这样的文件夹下，然后执行脚本就行了。这个脚本的效果就是会把 ajfkdjkfjdlajf 01 jfkdajfkd.mkv 重命名成 S01E01.mkv，字幕的话，jlkf23jinvnsvpsa 01 fjdklajfkl.chs.srt 重命名成 S01E01.chs.srt，保留语言并且和视频一致而且可以让 jellyfin 识别。

我一般是用 python 容器做这样的事情

git clone https://github.com/Nriver/Episode-ReName.git


docker run --rm -it \
-v /srv/mergerfs/all_disk_pool/jellyfin:/jellyfin \
-v /path/to/anime:/path/to/anime \
-v $(pwd):/rename \
--workdir="/rename" \
python:3-alpine \
sh -c "python3 -m pip install -r requirements.txt --user && pip3 install py-rename && sh"

py-rename 这个包我之后再提，但这边你应该注意到我用的是 mergerfs，而硬链在 mergerfs 上跨硬盘也能创建。

然后对准要重命名的文件夹

python3 EpisodeReName.py --overwrite 0 --path "/jellyfin/.../s1"

这边 overwrite 参数指定之后，如果有两个文件都被重命名成了相同集数，也就是识别错误了的话，会取消重命名操作。

另外他还支持偏移集数，比如刚才说到其实是第二季分开的，但是字幕组在做的时候连续编号了，又或者反过来，又或者总集篇没算进集数等等，可以参考这里，写个all.txt单独批量增加集数重命名一下。

py-rename

然后是 py-rename 这个包，其实是单纯的正则匹配重命名，专治👆🏻这个匹配不出来或者匹配错的，手动写规则去重命名。

cd 到要修改文件名的文件夹底下，首先预览

py-rename -n rename '(.+)第(\d{2})話([^.]+)\.([\w\.]+).ass' 'S01E\2.\4.ass'

然后去除 -n 参数就会重命名了

py-rename rename '(.+)第(\d{2})話([^.]+)\.([\w\.]+).ass' 'S01E\2.\4.ass'

还是比较安心的👍🏻

Kodi

到这边 jellyfin 自己的配置就可以了，这个时候在任何设备打开 Chrome 就已经可以看了，但我的最终目的还是要在 Chromecast 上串流。

在 Android TV 上有几个选择，

Jellyfin for Android TV
Kodi + Jellyfin
Jellyfin 在安卓上的客户端去强行安装到 Android TV 上（例如 Findroid）

Jellyfin for Android TV

官方客户端其实还可以的，我试了一下到目前为止没什么问题，属于保底手段吧。但感觉好多不需要转码的流也转了码，或者字幕效果其实不是很好可定制型比较差，主打一个能看。

Jellyfin for Kodi

Kodi 的话本身播放器属于就很强大，可以配置源

https://kodi.jellyfin.org/

加入源之后再从 zip 安装扩展 Kodi Jellyfin Addons / Jellyfin for Kodi

另外官方推荐在服务器上安装 Kodi Sync Queue 这个插件（在刚才安装bgm.tv插件的地方），可以保持库的同步。

Kodi 20 + 10.8.3 的时候我配置好看了，也没什么问题，但最近 Kodi 升级成了 21 之后，官方插件可能也升级了吧，有些动画没有了声音，在界面里开启强制转码也不行，我怀疑是音频部分并没有写进判断语句导致音频流不转码。。。所以暂时这个作罢。

Findroid

是最近新出的 Android 第三方 jellyfin 客户端，尝试了一下使用 Native 的播放器的话，画质给转的好多马赛克，开启了 mpv 播放器之后，画质是有了但卡的不行，卡帧。那只好冷藏起来咯。

另外要注意如果下载 apk 推送到 Chromecast With Google TV 的话，要下载 armeabi-v7a 架构的。

参考

本文鸣谢如下先辈提供情报

理想影音库构建之路（二）：关于老番管理这件事
 安卓TV端Kodi部署Jellyfin，使用Jellyfin打造最强媒体中心（篇二）
py-rename
Episode-ReName

解决在 Ubuntu 24 中用 Docker 安装服务器端 Wireguard 的一个问题

Thu, 27 Jun 2024 00:00:00 GMT

背景

前文提到了客户端使用 Wireguard 在 Docker 中连接 VPN 后将整个做种使用服务器网络的过程。但很不幸，这台 Kimsufi 的杜甫在上上个礼拜莫名其妙的失联了。期初我以为是网络问题或者可能死机了暂时性无法访问，一开始还能 ping 通于是在面板上操作了重启，重启过后无论是在中国大陆这边去 ping 还是在日本这边去 ping 都没有办法通，而且没有任何可 ping 通的迹象，遂重装。

问题1 ip6tables 报错

services:
  wireguard:
    image: linuxserver/wireguard:1.0.20210914
    container_name: wireguard
    cap_add:
      - NET_ADMIN
      # - SYS_MODULE
    environment:
      - TZ=Asia/Tokyo
      - SERVERPORT= #optional
      - PEERS= #optional
      - SERVERURL= #Wireguard VPN server address
      - ALLOWEDIPS=
    volumes:
      - ./wireguard-server/config:/config
      - /etc/localtime:/etc/localtime:ro
      - /usr/src:/usr/src # location of kernel headers
      # - /lib/modules:/lib/modules
    network_mode: "host"
    restart: unless-stopped

因为之前就已经容器化过了，所以直接敲

docker compose up -d && docker-compose logs -f

结果启动后出现如下报错，而且宿主机的 IPv4 还没办法从外面 ping 通了

ip6tables v1.8.7 (legacy): can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)
Perhaps ip6tables or your kernel needs to be upgraded.

很明显是 ip6tables 的有点问题，搜了一些文档进行自查后有可能是 ip6_tables 模块没有载入

modprobe ip6_tables

开机载入后启动容器便能成功启动

问题2 客户端只能访问 IPv6 地址但无法访问 IPv4

客户端没有办法访问公网 IPv4 地址，但是能 ping 通并访问宿主机的服务，真是让人头大，怎么会有这么奇怪的问题。

能够 ping 通宿主机说明客户端和宿主机的连接成功建立， Wireguard 端应该是没有问题，那么问题应该是出在宿主机的内部包转发上，宿主机的 wg0.conf 一动也没动过，网卡名也设置成通用的，怎么会不通也是很不明白。

[Interface]
...
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eno+ -j MASQUERADE
PostUp = ip6tables -A FORWARD -i eno+ -o %i -j ACCEPT; ip6tables -A FORWARD -i %i -j ACCEPT;
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eno+ -j MASQUERADE
PostDown = ip6tables -D FORWARD -i eno+ -o %i -j ACCEPT; ip6tables -D FORWARD -i %i -j ACCEPT;

第一句是允许 wg0（建立的nic）上进出包，后面那句是开启NAT转发，一切看起来都没有什么问题，在互联网上搜搜索索也没搜出来什么结果，于是问了新出的 Claude 3.5，也是来回问了好几回，最后给了的几个方案中有了这个解决方法

iptables -I DOCKER-USER -i eno0 -o wg0 -j ACCEPT
iptables -I DOCKER-USER -i wg0 -o eno0 -j ACCEPT

在宿主机的 bash 中敲入后客户端就马上能 ping 通 v4 地址了，于是上网搜索后发现 reddit 的这个帖子并稍微瞄了一眼 Docker 官方文档，看来是某个升级后导入的措施，可能是容器中建立的网卡怕影响到宿主机的网络所做的改动吧。

太长不看

首先第一个问题感觉不太像是 Ubuntu 会有的问题，因此怀疑是不是 kimsufi 修改的镜像问题（因为网络部分确实是有被修改），上述两个问题合在一起，有了以下解决方案。

首先编写 iptables.rules

*filter

-I DOCKER-USER -o wg0 -j ACCEPT
-I DOCKER-USER -i wg0 -j ACCEPT

COMMIT

其次编写启动脚本

#!/bin/bash

modprobe ip6_tables
iptables-restore -v -n /root/iptables/iptables.rules

然后给这个脚本上个服务保证开机启动 & 出错再运行

[Unit]
Description=My Startup Script
Before=network-online.target
Wants=network.target

[Service]
Type=oneshot
ExecStart=/root/startup.sh
ExecReload=/root/startup.sh
RemainAfterExit=yes
Restart=on-failure
RestartSec=3s

[Install]
WantedBy=multi-user.target

ip6_tables 模块需要在 docker 容器启动前便加载因此选择在network-online.target 前这个时间点运行脚本，但此时 docker 服务本身并不一定已经启动，因此如果才还原 iptables 的时候如果报错则让脚本自动再运行

Ubuntu 24 默认内核允许 10s 内运行 5 次因此注意 RestartSec 不要小于 2s 。

最后让服务开机启动

systemctl enable myscript.service

余谈

这台机器第一次重装过后刚安装好 docker 和 zsh，还在操作 ssh 呢，结果唐突失联，再次面板操作重装后又被告知硬件出现了问题。待 kimsufi 那边检查过后重新安装完成后发现 500G 的硬盘变成了 1.8T 真是受宠若惊，本以为是主机坏了给我开了台新的但 CPU 和内存大小也没变 ~~不管反正给了就要用满~~

另外每次重装机器，虽然已经做了容器化，但还要配 ssh 和安装 docker 这件事让我很是心烦，即使弄好也会出现像上面的奇怪问题 ~~也怪自己从 Ubuntu 22 改成了 24~~，不知道有没有什么解决方案适合自己

工作第7年，我从日本微信辞职了

Sun, 09 Jun 2024 00:00:00 GMT

转眼之间我在LINE已经工作了6年整，期间经历了大大小小，风格不同的产品和项目。5/17号我提了辞职申请，上星期，我走完了离职流程。今天这篇除了想写我和LINE的一些故事，也想留下一些自己对日本和将来的看法，更是为了自己将来的职业生涯中不要犯下同样的错误和正面去思考将来自己需要掌握的技能。

7年之前我感觉自己中了头菜

我和LINE的结缘是在7年之前日语N2出成绩的下午，当时我拿到成绩单知道自己合格之后，兴奋之余也幻想着能不能去日本工作，于是投了LINE和square enix，最初，投完简历后的第三天LINE让我再发一遍简历的pdf，我以为是程序的自动回复，毕竟那时我还国内刚毕业，怎么会有人要刚毕业的，于是没有回复，一周后又是一封邮件让我再发一次正式简历，我发过去之后，便是一次笔试加上三次面试，最终神差鬼使的拿到了offer，我至今仍然不知道当时的面试官们究竟是看上了我哪点才招我进去的。

至于square enix，第二周我就收到了拒信。

跳槽

为什么干了6年都没有跳槽

我其实不是没有想过，2020年的时候有跳过，那时投了メルカリ，smartnews，和百度日本，最后是拿到了百度日本的offer，但金额只能说是非常不如人意，于是最后没有去。在三年前的这次跳槽活动中，其实也给我留下了不小的心理阴影。メルカリ让我用web做一个他们app的首页，我手工撸了一个双向绑定，得到的反馈是“虽然自行实现了类似框架，但没有实现app的abcdefg功能，因此不予采用” SmartNews问了“你有没有看过Chrome源码？” “你对使用Rust重写前端工具是什么看法？”这样的问题，我不知道怎么回答，也确实没有看过，怕他问我更细节的问题，于是回答没有看过，以及没有接触过用Rust重写的工具链，于是挂了。然而我准备过的算法问题和前端问题一个也没被问到过（笑） Google、Indeed、微软这三家，投了简历却始终没有被回复过。我当然知道自己实力不行，同时也因为新冠有看了一些YouTuber和b站up主的成功故事，也同时自己平时的一些个人开发积累（bot等）给自己一直有在产出不少的被动收入，在LINE的生活属于平稳安宁不忙的情况下，那么在那时认为其实不跳槽耗到拿到永住后其实也没问题。等拿到永住后，副业去找单子做也好，去当YouTuber就算没有收入也是有吆喝的。

那么为什么现在又打算跳槽了

跳槽这件事从产生想法到付诸行动是有一定的门槛的，特别是公司各方面都相对其他公司比较安稳的情况下，并且如果和新职业的某些方面不是有巨大的差距下更是拿到offer也不会想去的。

三年前的那次跳槽，当时目的还是说能否有更好的挑战更高的薪水，在那时大家还是觉得互联网大厂福利好工资高技术氛围很棒。时至今日这些大家也知道其实是因为背后有足够的钱在支撑，今非昔比，开源节流是各大厂现在的主要目标，自然也会感受到寒冬。另外对于技术氛围的解读，三年前和现在我对这个的整体感受也是不一样的。

2023年6月，我工作的产品LINE证券决定关停，我对这个结果毫不意外。9月份我被调到出前馆这个产品（类似于饿了么），我很疑惑为什么没有被调回原来的大前端部，而是把我外派到子公司去。

起初的三个月，我依然按照以往自己的工作风格，适时造成开发任务但并不在空闲时间主动去索求开发案件。但没过多久上司就找我谈话，要求工作时间内积极响应。

上司对我盯的很紧，包括Slack的在线状态也心心念念，这让我觉得工作中时刻有人在监督我让我很是不自在并且透不过气。但与这相反，在出前馆，所有的一切贯彻日本人的三大优秀传统ほうれん草，即报告联络相谈，所有的事情都需要进行确认，否则你的同事就会给你下马威，包括又不仅限于PR里的骨头挑刺。

PR需要两个同意才能被合并，但一个大组中谁又了解你手里的功能性案件？然后就被要求去向同事整体说明你的设计你的想法，但这时如果对PR的修改意见不是你的写法有问题，而是对你案件整体功能的设计持有意见的话，那我想说关我屁事啊！？为什么在我已经做完功能的情况下要把这一切推翻从头来过？案件评审的时候你又不出席，老大都说可以了你为什么现在要跳出来拖人后腿？

而这一切甚至发生的更过，我总觉得同事的工作是在敷衍，感觉他是在为了表现他在工作所以才在工作的。我一周前就已经做完了案件的大部分，每天都在大群里喊，早会喊希望大家积极 review 但直到最后一周甚至最后一两天前同事才会给我做评审。我很理解大家手里都很忙，但如果你给了评审意见需要我修改，那我修改之后你还得再评审一次，我等到猴年马月？我急得像热锅上的蚂蚁，同事提的意见是“我觉得 if / else if / else不太好，能不能改成switch，能不能抽出一个函数提前return？”。我觉得你如果早个几周说我也不会那么生气，为什么要在马上要QA的这个节骨眼上提一些可有可无的意见？我观察了很多次，让我开始猜测你是否真的是在推动整个产品向前。

当然不止包括你的评审同事，整个PM也是追求KPI数字，做一些我认为可有可无的功能，类似于短信认证改成电话认证等，而且途中还没做完PM自己也跳槽了，那这让我觉得你的动机不纯，你也只是逢场作戏，并不是真正想让这个产品变得更好。

短期来看也许可以直接跟他们说去让他们不要这样做，但长期来看这一切都非常符合内耗这两个字，而我只能说对不起，耗不起。

包括也有12薪改成了15薪，很多福利被取消或者改差，办公室也变得很远等等硬性条件，但多少还能忍受，只是实在是让我觉得调到这个新的出前馆这边，完全看不到前途。

值得一提的是，我在2023/10的时候因为合并，HR系统完全并入雅虎的系统，然而雅虎用的软银的人事系统非常旧，字符还是JIS的第一版，我的名字因为字符集原因没法导入因此全部被录入成了片假名，虽然之后通过申请把能够显示的字符改了回来，但我当时在递申请的时候就觉得“啊，我估计呆不长这家公司了”。

LINE的这6年与我的这6年

我回顾我自己这6年，前三年我可能还稍有技术长进，也确实回顾自己各种留下的笔记博客以及留下的各种脚本等，前三年也确实是很积极的对内为自己留下将来很多的积累，对外输出自己的各种知识形象价值观。但后三年几乎没有任何输出，正面上的输出只有给自己不停地写脚本去自动化生活中的各种系统。

回过头想怎么会变成这样的结果，我自己觉得原因可能是：我为公司提出的贡献很少得到正反馈。

这个正反馈包括工资，评价，以及人给我的语言上的反馈。在前三年为公司的各种项目上提出了很多想法，很多改进，但却因为各种原因迟迟不能落地，有因为测试范围太大，测试时间不够，也有在PR评审阶段被人怼回去的。

其实现在去想，如果双方都能做一步后退，比如我去跟进了瓶颈，思考如何去解决瓶颈，比如，范围太大那我能否仅对某个地方做改动，测试排期久的话那先约定时间，之后记着去盯紧。

这个原因应该是最大的，我经历过的一件事是我发现了架构上的某个问题，然后我打了PR之后 Leader 说，你这个写法我没看过啊，你一动动了整个系统该怎么测试，我说这个写法只是你们不知道，现在小范围能跑就说明整体也没有问题。

最后PR过了，然后还因为改了这个架构上的问题 leader 还录了个 podcast 说是自己发现的问题。我当然是很生气一连好几条日文推特，被组里的其他人看到了然后负责人来向我道歉最后删推结束。我自己也申请换到了其他组去了。

那么在碰到过这样的事情之后我就开始变得比较“惰性”，你叫我做什么案件我就做什么案件，你指出我的代码有什么意见需要修改，我就完全按照你的意见去修改，首先这样很省时间我也没那么多心理上的负担，其次我主动去提出任何的想法，主动去改进项目中存在的问题和麻烦，对我的评价和工资没有任何反应，那我为什么要花那么多时间和精力去思考。我不如多学点新技术，多打会儿游戏，多写点自动化脚本。

同时我对升职加薪也有过期待，但总是事与愿违，我并没有能碰上类似的空缺机会，在一开始以为表现够好就会有机会但其实也是一个萝卜一个坑。

经历了三年前的那次面试失败后其实心里是有一些不平衡的，凭什么他们能够进我没能进的公司，他们的PR或者代码其实也就那回事，跟我差不多或者甚至还没我会写。但是这次我面试了近30家大中小公司，最后只拿到了2家公司的 offer，给的反馈也大多与沟通，或者没法推进整个面试的话题更进一步。这样的结果现在来看其实是和这么一连的情况是有因果关系的，因为我从来不会对同事和上司有任何的意见，永远都是好好先生，他们说什么我都是是是的，那么最终其实在沟通技能上也是毫无成长的。

那么反过来，很少给员工正反馈的公司做得如何呢？

2018年在刚进公司的时候股价平均也有4500点左右，而到合并前也只有4000点，一度跌下过3000点都不到，LINE的问题在我看来是只有流量但没有内容留住顾客，因此多元化的策略非常必须，但至于为什么明明做了这样那样的事情，却还是没能做起来最后还是不温不火的就不是我能分析的了。

LINE曾经是一家好公司，感觉产品推动很快，感觉自己做每件事情都很有意义，而且在2018年，我觉得在日本，没有一家企业可以称得上是真正意义上的互联网公司，比如乐天，比如mixi，比如メルカリ，这些企业的文化我觉得都无法和LINE相提并论，他们并不是一个频道上的。但近3年合并，总觉得写代码以外的事务性工作变得多了很多，做完的功能也推翻一次又一次，还有莫名其妙多出很多可有可无的一道步骤。其实是变得越来越像传统日本企业，而且这样的问题应该不只是LINE有，其他公司肯定也会有，所以如果今天我呆的不是出前馆这个组，也许我还会继续干下去。但这并不意味着出前馆这个组不行，如果其他的硬性条件没有发生变化，那我也不会萌生跳槽的想法。就和7年前一样，为什么来日本？我的回答也不会只有一个答案。

将来的打算

和国内的朋友聊天，大家一直在说卷卷卷的，我自己是认为合适的卷是有必要并且对公司行业和自我发展都是有益的。卷这个词可能有点用烂了，”合适的卷“应该被称之为适当的走出舒适圈以及抱有一颗对任何事情的上进心。国内有好多人为了不愿意强制加班跳槽到了其他国家，但未必不是另一个围墙。

三年前我对“技术氛围”的认知是大家是否积极会对新技术抱有开放的心态，积极采用，是否能够以技术再去推动产品发展等等，当我现在谈到“技术氛围”这四个字的认知的时候，我觉得应该解读为，你的同事是否是真的用心在工作了，他们是否真的在乎你写的代码，他们的技术水平是否达到了一定程度，能够看懂你写的代码。在我看来最后这个屎坑用什么框架用什么代码砌成的可能没有什么关系，重要的是你的同事是否对他有一颗积极向前推动发展的心。这跟日本的终生雇佣制，安稳的劳动法可能有关，有可能是他们觉得这样做其实风险最小，最能保住自己的工作，最不会节外生枝。（这样的思想我觉得在日本的很多地方都看得到）

那么在这样的环境下国内的朋友跳槽来日本的话，是否会感觉真的舒适就仁者见仁了。一方面下班手机关机是日本人的常态，大家会觉得这点很好，但自己的技术价值职业生涯能否得到提升，也许大环境可能还不如国内，需要你强于常人几倍的沟通和推动能力才能实现自己想要达成的目标。而我甚至会想如果毕业后没有来日本，在国内会不会有更好的发展？但没有办法考究，毕竟我不能同时活两个人的人生。

这篇文章可能是我自己的借口，包括同事对工作不上心那我也是不上心，包括为什么自己没有在工作中意识到去学习沟通技巧去多推动事情发展，那么换个工作环境，希望能成为自己重新向前的动力吧。

技术面上是深耕某个领域还是广泛熟知整体技术上的领域，我至今也没有想好，但我觉得工作之后，重要的不是去想方向，而是只要是自己喜欢的事情，找准一个去花时间和精力参与，参与是最重要的。

用 Astro 翻新我的博客

Tue, 04 Jun 2024 00:00:00 GMT

好久没有写博客了，忙是比较大的一个因素以外，事实上这几年也感觉确实没有什么积累，一方面前端虽然还是变化很快，但翻来覆去其实就那几个花样，我会觉得这也要写一篇文章水吗？另一方面博客本身也是各种长草，另外把想法组织成语言很难是因为当写成文章时就必须要归纳和整理，提升了整个难度。今天这篇文章主打一个想到哪里写哪里，希望能够降下自己写文章的门槛，聊一聊 2024 我用 Astro 翻新了我的博客。

为什么要写博客

在我刚开始工作的时候我觉得写博客只是一件很酷的事情，“哦你/他在写博客”，在我内心的想法中是为了记录所以才记录的感觉。然而最近我在写自己的项目的时候，当我思考如何解耦的时候我翻到了之前写的 CLS，最后成功的解决了问题，收获很大。我才意识到其实写博客是一个知识整理的过程，把工作时出现的问题能够记录下来在脑袋里消化最后用语言总结成文章，其实对自己应该是有所帮助的。

为啥很久没有写博客了

文章开头简单说了一下理由，首先前端本身在我个人的观测下其实整体架构趋于稳定，每件事情都有着固定的解决方案了，就算是Next.js，也只是整合整合再整合的感觉。其次是写博客本身的心里难度，很多事情一旦有了条条杠杠，做起来就会觉得有了难度，比如一旦动起笔来就会想我这篇文章标题起什么，小标题起几个怎么分段等。而其实我们每个人有想法的时候经常是一段一段的，并不太会事先规划好。而且事实上我在写离职的那篇文章的时候，就是先在TickTick中把自己想到什么就写下来，最后再一起搬到记事本里调整顺序和归纳。因此从个人的习惯，到支撑整个博客的系统上需要能够支持这样的碎片化的想法。

Hexo 的问题

直到2024年的年初为止，我都还是使用Hexo在书写博客。Hexo 之前的静态网站生成是 jekyll，jekyll 我没用过但 hexo 的命令行整体一看就是专为博客而生，再加上当时国内大学生之间都很流行，于是就用了。没想到这一用直接用了近10年，还蛮意外的。

Hexo 在我的观测下是内容和主题做到了分离，而且主题可以使用ejs等模板引擎进行一个不错的根据内容的区分进行生成。也正是这样简单的架构让我一直用到了现在，也催生了许许多多的主题的产生。几年以来我对我的博客主题修修补补，经历了多说倒闭到自己的评论系统的迁移等等。

早期 Hexo 的包依赖有 node-gyp 等，我不是很清楚为什么会有这样的依赖，导致 CI 有时掉线，换个平台就炸了生成不了，每次执行 npm i 总是心惊肉跳的，近年 Node 生态渐渐稳定，也有了锁定版本等等，但旧版本的 Hexo 在新 Node.js 版本上好像没法运行，再去官网看的时候发现更新了很多大版本。结果最近的大版本好像把很多设置项给取消掉了，主题也没法调用了。就觉得 Hexo 也开始显得老态龙钟了。

当然这只是一个导火索，长期以来前端环境不断发展，打包系统从 Gulp 到 Gulp 到 webpack 到 rollup 到 vite 等等等等，都是在补齐原生浏览器的包系统的不足和网络资源的最优化。然而 Hexo 对这些构建系统完全是没有支持的，那么在调试过程中就比较麻烦了，需要自己搭建构建系统后再开一个预览，但是 Hexo 的 markdown 就不是实时更新了。而且 Hexo 的 build 命令也不会帮助你去构建你的那些资源，也就其实相当于完全是两套。整体来说会变得相对麻烦，虽然理清楚了也还好。我也一直很想引入打包系统对整体的代码进行一个重构和前端代码压缩等等。但其实一想到要自己再搭个脚手架就完全没有了动力。

当然我对整体设计其实也不是很满意的，反而到了现在这个年龄我更会在乎内容，如果内容吸引人，那么自然会去找作者的信息，而不需要主动去展示自己的信息。之前的那个主题还是有点过于 fancy 和二次元了。

那么正好年初开始 Astro 开始流行了，于是便看了起来。

Astro

Astro 也是一个静态网站生成器，但他与其说静态网站，其实也在服务器上运行，并有处理类似 cookie 这种和 db 交互的能力（SSR模式）。具体就不介绍了 ~~（我自己也会去摸透）~~ 。

谈一下 Astro 的优点，首先是卖点全新 Markdown 格式 MDX，Markdown里可以插组件，导入包等等。大概挺好用的吧，~~我暂时没这个需求让我怎么评价~~，这个格式暂时观望吧，因为如果有其他框架，其他 CMS 支持的话，那我也许会使用，但我更倾向于在 layout 也就是主题上做文章，我觉得对张鑫旭这些写 sample 教学文章的大佬可能会有用，同样一个 component 可以直接展示出来。

其次是框架混用，Astro 自己的 layout 里边可以使用你喜欢的框架比如 svelte，Vue，React等等，但内容本身都是在静态生成命令执行的时候产生的，所以传统的 onMount、useEffect 等等都不会如你所想的在客户端进行绑定事件监听。需要在调用框架组件的时候加入以 client: 为首的 directive。但无论加入哪个指令，script中的内容将会完整的被打包系统吐出来最后写进脚本里，因此做多语言的时候你的语言 Map 有可能会被单独打包成一个chunk，有人可能会在乎，有人可能不会，而对于我来说，HTML中既然已经存在了这样的语言，是不是就不应该再写一遍进 JavaScript，那么我就会用 props 传进去之后，调用直接渲染模板，就不会被打包了。但这样进而会导致写法冗长，不利于代码的可读性，不过这也是仁者见仁，或者说是全看写代码的人如何协调了。

以及还有一些小问题吧，比如我需要format时间，Astro 经过 parse 后给到我的时间是一个 UTC 时间，我理解 Astro 支持多时区，文章的DateTime可以有时区信息，但现有的文章全都是没有时区的，因此我必须把 Node.js 的时区也得默认改成 UTC，然而官方的推荐做法是根目录添加.env使用 import.meta.env，进而避免对 process.env 的污染？但现有的框架比如 date-fns 都没有使用 import.meta.env 就导致了我还得手动去想在哪里安排设置这个环境变量。

另外每个“框架组件”都会生成一个 chunk，即使我在 vite 中配置成合并一个，但仍然产生了 1kb 的 import chunk，这我就觉得很奇怪了，但也不知道该怎么去搜和提 issue。以及在 src 下的图片引入一定经过 processor，就算把 astro-compress 的图片选项关掉，也还是被进行了一次转换。我就觉得很不能忍受。

我很有理由怀疑这些个问题我不但不会去找解决方案，可能直接就下次换新框架了🌚

至于为啥不用 Hugo，兄弟，前端你必须得用最新的啊，不然这堆翔你都赶不上热的啊

Waline

评论的问题之前自己撸了一个实现，但打工人，没有什么时间去维护这些事情，而且当时没有加入包括验证码等防止刷评论的实现，以及把 home server 换掉之后，构建完成的前端 dist 我忘记移动到新的 server 了，又懒得去再从源代码上重新构建一下，于是那就找个现有的实现吧。

现在 2024/05 的时间点上，self-hosted 的评论系统有 waline 、 twikoo 、 artalk 这三个，另外还有个利用 github 的 giscus，首先我对评论借 github 这个行为不是很喜欢，总觉得有种错误使用方式的感觉因此排除，而且我曾经在数据库里的评论数据感觉也不是很好导入（花时间肯定可以）排除。几家的实现功能和实现方式和我当时构想的都差不多，那么剩下三个就是比较一下星星数和开发状态，issue 状态，有没有踩到自己不能忍受的雷点等等。

最后还是选择了星星数和开发状态最活跃的 Waline。数据库用的 PostgreSQL，改了一下mySQL导出的语句三下五除二就复原了原来的数据并现在展示了出来。

余留课题

[ ] Google Analytics & Google AD 能恰的话还是想恰口饭的嘛（谁不想呢）
[x] photoswiper → fancybox 我靠 2024 年的 photoswiper 居然可定制化程度还没2014年的高？
[ ] 分类显示不同语言的post 自己给自己挖了个大坑吧，routing 搞的自己头都大。。。
[x] 代码片段支持复制 真的很需要，但好像得写插件 / 纯 JS 添加
[ ] waline 后台 post 重定向到各个博文正确的地址 后台看评论但没法直接点到哪篇post的感觉很不爽

Reference

Astro & Shiki line number issue
.nojekyll

wireguard + v6 双栈环境下构建 Transmission PT 做种客户端

Sun, 21 Jan 2024 10:07:32 GMT

背景

寻找技术上既能规避自家网络使用 BT 协议又能利用本地环境的大硬盘的解决方案

采用方案

Wireguard + Transmission

原因

以前一直使用 docker-transmission-openvpn 这个 repo 的 OpenVPN

但是因为如下原因

wireguard 配置简单、现代化
想上 IPv6
可以自己控制 Transmission 的自由化决定更换方案

在 Docker 中安装 Transmission

使用 linuxserver/wireguard 镜像启动 wireguard 并在镜像内安装 transmission

注意查看 Docker 中配 IPv6 的方式，直接指定公网IPv6地址即可，如果外网无法 PING 通，宿主机上可以尝试安装 ndppd

version: '2.4'
services:
  transmission-wireguard:
    image: linuxserver/wireguard:1.0.20210914
    container_name: transmission-wireguard
    cap_add:
      - NET_ADMIN
    environment:
      - DOCKER_MODS=linuxserver/mods:universal-package-install
      - INSTALL_PACKAGES=dnsutils|traceroute|transmission|transmission-daemon|transmission-cli
      - USER=
      - PASS=
    volumes:
      - ./wireguard-config:/config
      - ./custom-cont-init.d:/custom-cont-init.d
    networks:
      - transmission
    ports:
      - 127.0.0.1:9091:9091

networks:
  transmission:
    enable_ipv6: true
    ipam:
      config:
        - subnet: 240f:10c:bcfb:1:4:1::/96

在 wg0.conf 中添加 PostUp / PreDown 脚本启动 Transmission

[Interface]
PrivateKey = PrivateKeyPrivateKeyPrivateKey
ListenPort = 54321
Address = 10.13.13.2/32, 2001:ipv6:public:address:1::2/128
# Cloudflare 1.1.1.1 DNS
DNS = 2606:4700:4700::1111, 1.1.1.1
PostUp = start.sh
PreDown = stop.sh

# server here
[Peer]
PublicKey = /pX3pc/Lwxc94O93sjKaAG/v0VJM5wkqr3HZxX6GD0Q=
PresharedKey = 5bQ18jyDGwtNyX37Iv6AiI9TDPo02oDzwMaIJM/SKgE=
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = [2001:ipv6:public:address:1::1]:54321
PersistentKeepalive = 20

s6-setuidgid abc transmission-daemon -f &

echo "Stopping transmission..."
pid=$(pidof transmission-daemon)
if [ ! -z "$USER" ] && [ ! -z "$PASS" ]; then
  transmission-remote -n "$USER":"$PASS" --exit
else
  transmission-remote --exit
fi
# terminate when the transmission-daemon process dies
tail --pid=${pid} -f /dev/null
echo "Transmission exited."

问题 - 发现 PT 显示只有 IPv6 权限

启动做种之后在各大 PT 站发现自己只有 IPv6 权限，然而在容器内可以 ping 通 IPv4 地址（从延迟上来看也确实走了 VPN）

解决

调整优先级让 IPv4 优先 IPv6

Google 中搜索过后大多数的解决方案是添加一行 precedence ::ffff:0:0/96 100 到 /etc/gai.conf 文件中

这个方案我之前在宿主服务器上试过是有效果的，但在容器中尝试之后并没有起到有效作用，原因有可能是因为容器的网络顺序很有可能并不遵从文件，于是尝试在 wg0.conf 中不分配 IPv6 地址后发现站点显示拥有 IPv4 权限，一度尝试放弃准备起两个容器一个走 v4 一个走 v6

屏蔽做种服务器的 IPv6 DNS 响应

再次更换搜索词为 “双栈 transmission” 后，出现了一些结果，发现写到

需要通过更改 host 或者调整系统前缀策略让 BT 客户端通过 v4 连接 tracker

设置双栈做种时，先在本机网络适配器中关闭IPV6协议，然后ping一下tracker服务器，得到一个IPV4地址，将这个IPV4地址和tracker服务器域名写进系统的hosts文件，再开启IPV6协议即可。

这才醒悟到根本原因很有可能是 transmission 汇报的ip地址为网卡地址，种子服务器接收后不认可私网IPv4地址，于是开始屏蔽汇报服务器的AAAA地址

custom-cont-init.d 下新建安装启动 bind9 脚本

#!/bin/bash

DEBIAN_FRONTEND="noninteractive"
apt-get update
apt-get -o DPkg::Options::=--force-confdef install -y --no-install-recommends bind9 bind9-libs bind9-utils

named -c /etc/bind/named.conf
echo "nameserver 127.0.0.1" > /etc/resolv.conf

创建 named.conf 挂载进容器喂给 bind9

plugin query "/usr/lib/x86_64-linux-gnu/bind/filter-aaaa.so" {
  filter-aaaa-on-v4 yes;
  filter-aaaa-on-v6 yes;
};

容器挂载

# ...前略
  volumes:
    - named.conf:/etc/bind/named.conf:ro
# ... 后略

后正常拥有双栈权限

问题 - IPv6的传入链接有问题

发现交换客户端中永远没有 IPv6 地址后，遂尝试 ping IPv6地址，无果，traceroute 之后发现停留在 VPN 服务器上不到达 container

解决 VPN服务器上安装NDP发现服务

Ubuntu 上 apt -y install ndppd

创建

# eno0 is your NIC name like eth0 etc...
proxy eno0 {
  rule 2001:public:ipv6:address::/64 {
    static
  }
}

运行 service ndppd restart 就可以了。

参考

双栈做种
 双栈环境挂 PT 需注意
 关于IPv6的常识科普，以及VPS通过ndppd向母鸡广播小鸡内网IPv6邻居的方法教程

回顾

其实搭建这个东西是 2021 年做的事情了，当时这个东西还挂在群晖上还解决了 wireguard 代理 IPv6 路由表的奇怪问题，但现在回想整个过程，其实是对网络部分，与操作系统这边的实现细节并不清楚才会走了很多弯路，回想发生过有很多类似的事情，不刨根问底就会有“感觉上对这个东西应该很熟悉每天都在打交道”但为什么最后会有偏差的问题

另外整体一遍做过之后调试之后也对 IPv4 / IPv6 有了进一步的认识，对网络问题如何定位，查找也有了一些心得。

~~终于可以把 2021 年的 Chrome Tab 给关上了呢~~

Node.js 路径大小写的坑

Wed, 01 Jul 2020 18:59:40 GMT

大多数前端开发同学都用的是 macOS ，然而 macOS 上文件名不区分大小写，因此你不能在同一个文件夹下同时创建 package.json 和 packagE.json。

这个细节很小，因为大家不是英语母语，现在又越来越依靠 intelliSense 补全文件路径，在这个事情上翻跟头会比较少，就算翻了跟头也很容易忘记。

大多数情况下你在这个上边会跌进的一个坑是

Linux 下部署时找不到 Module

也许是之前哪位高人用记事本写的代码

const list = require('./List');

然鹅现实生活中你的 List 的文件名是list.js

完了，你就得在你的代码库里把 List 统统改成 list

所以这其实是个很小的问题也很容易解决就是浪费了一点时间。

但我碰到一个浪费了我一个下午的问题，也促使我写了这篇其实没有什么技术含量的笔记

`require('./a.js') !== require('./A.js')`

前因后果：

在用 TypeORM 写增删改查的时候，新引进了一张表，于是挂上去调试。发现一直报找不到表的错

TypeORM EntityMetadataNotFound: No metadata for "***" was found

就是这个错。

反反复复确认了表已经挂到了 option 下边。

怎么办，只能进 node_modules 下边直接改源码调试了（

进去 console.log 三下五除二，发现表确实挂载了，然而

https://github.com/typeorm/typeorm/blob/master/src/connection/Connection.ts

    /**
     * Gets entity metadata for the given entity class or schema name.
     */
    getMetadata(target: Function|EntitySchema<any>|string): EntityMetadata {
        const metadata = this.findMetadata(target);
        if (!metadata)
            throw new EntityMetadataNotFoundError(target);

        return metadata;
    }

    /**
     * Finds exist entity metadata by the given entity class, target name or table name.
     */
    protected findMetadata(target: Function|EntitySchema<any>|string): EntityMetadata|undefined {
        return this.entityMetadatas.find(metadata => {
            console.log(metadata.target, target, metadata.target === target) // ←ここ
            if (metadata.target === target)
                return true;
            if (target instanceof EntitySchema) {
                return metadata.name === target.options.name;
            }
            if (typeof target === "string") {
                if (target.indexOf(".") !== -1) {
                    return metadata.tablePath === target;
                } else {
                    return metadata.name === target || metadata.tableName === target;
                }
            }

            return false;
        });
    }

左边右边都是 Function xxx，但是却不完全相等。

于是我开始疯狂比较两边 import 的代码，最后才发现，import 的时候因为 Class 名和文件名一样，所以一个用的是 intelliSense 自动补全，一个是我复制粘贴的 Class 名，但是 Class 名是首字母大写的，但文件名不是。

那么为什么同样的文件，引用的时候文件名不同，引用会不同呢？

https://github.com/nodejs/node/blob/master/lib/internal/modules/cjs/loader.js#L936

我们都知道 Node.js 的 require 只会引用一次，究其原因是因为 Node.js 会把模块缓存到内存里，以便快速重复调用。我们在上边的源代码可以看到，Node.js 会使用 filename 进行缓存，而这里的 filename 是你 require 的文件名 + 绝对路径。

因此 Node.js 会认为这是两个模块，就会重复 require 两次，但是如果是在 windows 下，filename 会被 path.resolve 给 toLowerCase 成一个模块，在 Linux 下，又会因为大小写敏感而找不到模块，也就是只会在 macOS 上出现的一个问题。

所幸不是到部署才发现的问题，也所幸这个只会在调试的时候出现问题。。。。

Node.js 依存モジュールのファイルはケースセンシティブの件

Wed, 01 Jul 2020 18:59:40 GMT

皆さん開発の時ほとんど macOS を使ってるんでしょうか、だが macOS のファイル名はケースインセンシティブ（大小文字は区別しない）。つまり同じフォルダ下に package.json と packagE.json は一緒にいられない。

ほとんどの人は知ってるかにもかかわらず、あまりこれに注意を払ってないのではないかなと思って、だってみんなの母語は英語ではないし、インポートの際は intelliSense も結構賢く補足してもらってるので、あんまりここに転んだことはないと思います。転んでもすぐ忘れるんだろう。

よく会った問題はこれです👇

Linux でデプロイ時にモジュールは見つからない

多分誰がメモ帳で書いたコード

const list = require('./List');

でも List のファイル名はlist.js、

そしたらすべての List を list に変えなきゃいけない。

細かい点で解決には難しくないが、時間ちょっと無駄しましたね。

でも今日話したいのは僕の午後をまるごと無駄しましてこの技術的な内容あまりない記事を書くことになったこれです👇

`require('./a.js') !== require('./A.js')`

TypeORM を使ってる時新しいスキーマ（テーブル）を入れたが、デバッグの時ずーとそのスキーマが見つからないエラーに怒られて

TypeORM EntityMetadataNotFound: No metadata for "***" was found

option に何度も確認しまして確かにスキーマは入ってるが。

どうしようと思って、 node_modules に入って直接ソースコードを改ざんしてデバッグすることになった。

console.log でスキーマはたしかに入ってますが、

https://github.com/typeorm/typeorm/blob/master/src/connection/Connection.ts

    /**
     * Gets entity metadata for the given entity class or schema name.
     */
    getMetadata(target: Function|EntitySchema<any>|string): EntityMetadata {
        const metadata = this.findMetadata(target);
        if (!metadata)
            throw new EntityMetadataNotFoundError(target);

        return metadata;
    }

    /**
     * Finds exist entity metadata by the given entity class, target name or table name.
     */
    protected findMetadata(target: Function|EntitySchema<any>|string): EntityMetadata|undefined {
        return this.entityMetadatas.find(metadata => {
            console.log(metadata.target, target, metadata.target === target) // ←ここ
            if (metadata.target === target)
                return true;
            if (target instanceof EntitySchema) {
                return metadata.name === target.options.name;
            }
            if (typeof target === "string") {
                if (target.indexOf(".") !== -1) {
                    return metadata.tablePath === target;
                } else {
                    return metadata.name === target || metadata.tableName === target;
                }
            }

            return false;
        });
    }

左と右は同じく Function xxx がリファレンスは同じではない。

これは事件ですね。んでファイル両方の import を一行一行で確認して、最終的に import のパスに問題を見つかった。自分がインポートした際に、一つは Class 名をそのままコピペしたが、もう一つはファイル名でしたが、Class 名は PascalCase が、ファイル名は camelCase でした。

そしたらなぜ同じファイルで使う時ファイル名が違ったらリファレンスは違うになりますか？

Node.js のソースコードに見てきました。 https://github.com/nodejs/node/blob/master/lib/internal/modules/cjs/loader.js#L936

Node.js の require は一回しか実行しない、その原因は Node.js はモジュールをメモリに保存して、その後コードの中で require したらすぐ使えるという意図で設計されました。ソースコードからも見えて、Node.js はファイル名でキャッシュしますが、ここの filename は require のファイル名 + 絶対パス。

なので Node.js は２つモジュールとみなすが、windows だと、 filename は path.resolve で toLowerCase で同じファイル名にするが、Linux だとケースセンシティブでモジュール見つからないで弾かれますが、この問題は macOS しか出ませんね。

ま、デプロイまで問題出るよりラッキーですね。

什么是 CLS？在浏览器和 Node.js 中实现 CLS

Mon, 29 Jun 2020 19:48:05 GMT

在写 Flutter 和 Serverless 查资料的时候，在某个博客里看到了 CLS 的相关内容，感觉其实是个很不错的软件工程的解耦想法，于是保存了下来。今天回过头来仔细研究了一下并决定给自己留下一些记录。

场景

无论是在浏览器，还是在服务端 Node.js，我们经常会碰到打点上报，追踪错误这样的需求，即使不对特定用户进行追踪，我们也会给某个 session 分配唯一 ID 以在 log / analytics 界面能够看到用户的完整行为，对于产品分析与错误再现是十分重要的。

假设我们需要写一个 error handling ，这个 error handling 会 hold 住所有的请求的异常，我们如何分辨哪个错误是哪个请求造成的呢？

log.error("Error occured", req);

那么这个 error handling 就跟 req 耦合了

假设我们需要追踪某个错误，是哪个 user 产生的，又或者是哪个错误，user 干了什么导致的？

log.info("User has done xxx", user);
log.error("Error occured by", user);

于是跟 user 也深深的耦合了。

单单这样的例子好像没有什么大问题，不过多两个参数嘛。但写过大型应用的同学，后期不断增加功能的时候，你一定写过那种长长的参数列表的函数，又或者是好几百行的一个函数，实在是太不优雅，重构起来也太难。

尝试解决

函数如果是同步的，那么我们可以直接挂到全局变量（某个对象）下

const global = {};
$("button").click((event) => {
  global.event = event;
  log("button clicked");
});

function log(...args) {
  console.log(global.event, ...args); // { x: xxx, y: xxx, target: xxx } 'button clicked'
  // other logic
}

显然这在异步中行不通

const global = {};
$("button").click((event) => {
  global.event = event;
  setTimeout(() => {
    log("button clicked");
  }, 1000);
});

function log(...args) {
  console.log(global.event, ...args);
  // other logic
}

你会发现打印的 global.event 全变成了同一个对象

我们需要能够从始至终在同一个异步调用链中一个持续化的存储，又或者是我们需要能够辨识当前的异步函数他的唯一辨识符，以和同样内容的异步函数但并不是本身的运行的这个作区分。

CLS 登场

在其他语言中，有一个叫做 Thread-local storage 的东西，然而在 Javascript 中，并不存在多线程这种概念（相对而言，Web Worker 等与主进程并不冲突），于是 CLS ，Continuation-local Storage，一个类似于 TLS，得名于函数式编程中的 Continuation-passing style，旨在链式函数调用过程中维护一个持久的数据。

浏览器的解决方案 Zone.js

先看看是怎么解决的

$('button').click(event => {
  Zone.current.fork({
    name: 'clickZone',
    properties: {
      event
    }
  }).run(
    setTimeout(() => {
      log('button clicked');
    }, 1000);
  );
});

function log(...args) {
  console.log(global.event, ...args);
  // other logic
}

Zone.js 是 Angular 2.0 引入的，当然它的功能不只是提供 CLS，他还有其他相关 API。

一个并不完美的解决方案

我们试着思考一下， Zone.js 是如何做到这些的。如果浏览器没有提供异步函数运行环境的唯一标识，那么只剩下唯一的一条路，改写所有会产生异步的函数，包装了一层后也就能加入hook了。

我尝试自己写了一下

看似好像没什么问题，不过

angular with tsconfig target ES2017 async/await will not work with zone.js

浏览器中现在并没有完美的解决方案

我们可以做个实验，在 console 里敲下如下代码

const _promise = Promise;
Promise = function () { console.log('rewrite by ourselves') };
new Promise(() => {}) instanceof Promise
// rewrite by ourselves
// true

async function test() {}
test() instanceof Promise
// false
test() instanceof _promise
// true

async function test() { return new Promise() }

test() instanceof Promise
// rewrite by ourselves
// false
test() instanceof _promise
// rewrite by ourselves
// true

也就是说浏览器会把 async 函数的返回值用原生 Promise 包装一层，因为是原生语法，也就无法 hook async 函数。当然我们可以用 transpiler 把 async 函数改写成 generator 或者 Promise，不过这并不代表是完美的。

Node.js 的解决方案 async_hooks

Node.js 8后出现的 async_hook 模块，到了版本14仍然没有移去他身上的 Experimental 状态。以及在刚出现的时候是有性能问题的讨论（3年后的今天虽然不知道性能怎么样，不过既然没有移去 Experimental 的标签，如果追求高性能的话还是应该保持观望）

虽然没有移去 Experimental 的状态，但是稳定性应该没有什么太大问题，大量的 Node.js 的追踪库 / APM 依赖着 async_hooks 模块，如果有重大问题，应该会及时上报并修复

对于性能问题，不展开篇幅讨论，取决于你是否愿意花一点点的性能下降来换取代码的低耦合。

如何使用

async_hooks 提供了一个 createHook 的函数，他可以帮助你监听异步函数的运行时创建以及退出等状态，并且附带了这个运行时的唯一辨识id，我们可以简单地用它来创建一个 CLS。

Node.js 13 后的官方实现

在社区中已经有了那么多优秀实现的前提下，Node.js 13.10 后新增了一个 AsyncLocalStorage 的 API

https://nodejs.org/api/async_hooks.html#async_hooks_class_asynclocalstorage

实际上他已经是开箱可用的 CLS 了

const {
  AsyncLocalStorage,
} = require("async_hooks");

const express = require("express");
const app = express();

const session = new AsyncLocalStorage();

app.use((_req, _res, next) => {
  let userId = Math.random() * 1000;
  console.log(userId);
  session.enterWith({ userId });
  setTimeout(() => {
    next();
  }, userId);
});

app.use((_req, res, next) => {
  const { userId } = session.getStore();
  res.json({ userId });
});

app.listen(3000, () => {
  console.log("Listen 3000");
});


const fetch = require('node-fetch')

new Array(10).fill(0).forEach((_, i) => fetch('http://localhost:3000/test', {
  method: 'GET',
}).then(res => res.json()).then(console.log))

// Output:
// Listen 3000
// 355.9573987560112
// 548.3773445851497
// 716.2437886469793
// 109.84756385607896
// 907.6261832949347
// 308.34659685842513
// 407.0145853469649
// 525.820449114568
// 76.91502437038133
// 997.8611964598299
// { userId: 76.91502437038133 }
// { userId: 109.84756385607896 }
// { userId: 308.34659685842513 }
// { userId: 355.9573987560112 }
// { userId: 407.0145853469649 }
// { userId: 525.820449114568 }
// { userId: 548.3773445851497 }
// { userId: 716.2437886469793 }
// { userId: 907.6261832949347 }
// { userId: 997.8611964598299 }

参考

CLS とは？ブラウザとNode.jsで CLS を実装してみます

Mon, 29 Jun 2020 19:48:05 GMT

資料を調べる際に、CLS の存在を知りました。エンジニアリングで結構いいデカップリングのやり方と感じまして、シェアしたいと思います。

シチュエーション

ブラウザか、サーバーのNode.jsか、どっちでもエラーハンドリング、ユーザートラッキングのニーズは日常茶飯事。例えユーザーを特定しなくても、id をつけて、ユーザーの行為を追跡して、エラーの再現にも重要し、プロダクトの改善にも役たちます。

仮に今エラーハンドリングを書こうと思って、このエラーハンドリングはすべてのエラーを処理しますが、どのリクエストから生み出したエラーを知りたいと

log.error("Error occured", req);

このハンドリングは req と結合しちゃった

仮に今このエラーどのユーザーから出たエラー、ユーザーが何をやったかを知りたいと

log.info("User has done xxx", user);
log.error("Error occured by", user);

ユーザーとも結合しちゃった

この２つの例は一見するとそんなに大きいな問題ではなさそう、ただ２つのパラメータが増えただけじゃ。だけど、大型サービスを作る時、どんどん増えた機能に対して、関数の引数と関数の長さと共にどんどん伸びちゃって気持ち悪くてリファクタリングしようとしょうもないこと、少なくありませんでしょうか？

解決してみよう

関数が同期のであれば、グローバルで変数につけたらいいじゃんー

const global = {};
$("button").click((event) => {
  global.event = event;
  log("button clicked");
});

function log(...args) {
  console.log(global.event, ...args); // { x: xxx, y: xxx, target: xxx } 'button clicked'
  // other logic
}

だが、非同期関数のであれば

const global = {};
$("button").click((event) => {
  global.event = event;
  setTimeout(() => {
    log("button clicked");
  }, 1000);
});

function log(...args) {
  console.log(global.event, ...args);
  // other logic
}

すべての global.event は同じイベントになちゃった(´；ω；｀)！それはだめですね。

我々必要なのは非同期呼び出しチェーンに最初から最後まで持続的なストレージ、もしくは今走ってる非同期関数の呼び出しの唯一の識別子。

CLS が登場

他の言語では、Thread-local storageと呼ばれるものがあります。が JavaScript はマルチスレッドはありません（Web Workerなどはメインと関係ないし、自分でもマルチスレッドしない）。CLS という名前は TLS みたいに関数型プログラミングからの Continuation-passing style 名前をもらって、Continuation-local Storage、そのチェインの呼び出しの中で持続的データストレージをメンテナンスする。

ブラウザの解決 Zone.js

どうのように解決したかちょっと見てみましょう

$('button').click(event => {
  Zone.current.fork({
    name: 'clickZone',
    properties: {
      event
    }
  }).run(
    setTimeout(() => {
      log('button clicked');
    }, 1000);
  );
});

function log(...args) {
  console.log(global.event, ...args);
  // other logic
}

Zone.js は Angular 2.0 から誕生したもので、もちろん他の機能も持ってる。

この方法は残念なところがあります

考えてみましょう、 Zone.js はどうやってこれを実現しました。ブラウザは呼び出しに対して唯一の識別子を提供するAPIがなければ、すべての非同期関数をリライトしかできなく、そうすれば非同期が入る時と出る時 hook できて、この効果が実装できますね。

自分も書いてみました。

また問題なさそうだけど、

angular with tsconfig target ES2017 async/await will not work with zone.js

ブラウザ今では完璧の解決方法はありません

実験をやってみましょう、console で下のコードを打ったら、

const _promise = Promise;
Promise = function () { console.log('rewrite by ourselves') };
new Promise(() => {}) instanceof Promise
// rewrite by ourselves
// true

async function test() {}
test() instanceof Promise
// false
test() instanceof _promise
// true

async function test() { return new Promise() }

test() instanceof Promise
// rewrite by ourselves
// false
test() instanceof _promise
// rewrite by ourselves
// true

ブラウザは、async 関数のリターンをネイティブの Promise で再ラッピングします。ネイティブ文法なので、async 関数はリライトできない。もちろん transpiler で async 関数を generator もしくは Promise にすることは可能ですが、完璧とは言わないでしょう。

Node.js の解決 `async_hooks`

Node.js バージョン 8 以降出た async_hook モジュール、バージョン 14 の今でも Experimental ステータスから脱却してない。出たごろ性能に関しての議論もあったが、今はどうなってるかまだわからない状態ですが

Experimental ステータスにしても安定性としては問題なさそう、大量な Node.js のトラッキング / APM が依存していて、問題があったら issue が立てられるはずです。

性能に関する問題はここは展開しない、コードの低結合と少しパフォーマンスの低下を交換するかしないかによりますね。

使い方

async_hooks は createHook という関数を提供した、これが非同期関数のライフサイクルに hook できます、しかも唯一識別子も提供してくれますので、CLS を簡単に作れます。

Node.js バージョン 13 からオフィシャルの実装も

コミュニティの中でたくさんの CLS ライブラリーがあった上に、Node.js 13.10 から AsyncLocalStorage の API がありました。

https://nodejs.org/api/async_hooks.html#async_hooks_class_asynclocalstorage

実はこれはすでにすぐに使える CLS です。

const {
  AsyncLocalStorage,
} = require("async_hooks");

const express = require("express");
const app = express();

const session = new AsyncLocalStorage();

app.use((_req, _res, next) => {
  let userId = Math.random() * 1000;
  console.log(userId);
  session.enterWith({ userId });
  setTimeout(() => {
    next();
  }, userId);
});

app.use((_req, res, next) => {
  const { userId } = session.getStore();
  res.json({ userId });
});

app.listen(3000, () => {
  console.log("Listen 3000");
});


const fetch = require('node-fetch')

new Array(10).fill(0).forEach((_, i) => fetch('http://localhost:3000/test', {
  method: 'GET',
}).then(res => res.json()).then(console.log))

// Output:
// Listen 3000
// 355.9573987560112
// 548.3773445851497
// 716.2437886469793
// 109.84756385607896
// 907.6261832949347
// 308.34659685842513
// 407.0145853469649
// 525.820449114568
// 76.91502437038133
// 997.8611964598299
// { userId: 76.91502437038133 }
// { userId: 109.84756385607896 }
// { userId: 308.34659685842513 }
// { userId: 355.9573987560112 }
// { userId: 407.0145853469649 }
// { userId: 525.820449114568 }
// { userId: 548.3773445851497 }
// { userId: 716.2437886469793 }
// { userId: 907.6261832949347 }
// { userId: 997.8611964598299 }

参照

用最热的Serverless，以最快的速度，写最野的JavaScript

Sun, 21 Jun 2020 15:52:35 GMT

Serverless，云原生，年初到现在，我关注的好几个前端公众号和资讯号都在疯狂推这些东西，去年年底就早有耳闻，原来以为是各种活动大会组织联合云厂商在对 devops 卖票整的新技术，但热度越来越强，于是我也跃跃欲试蹭个热度

Serverless 到底是什么¿

一句话概括就是 Cloud Function + Object Storage + Cloud Database + API Gateway and more by Cloud Service Provider. 简单来说就是有个叫 serverless 的开源框架把云厂商提供的这些服务整合成了一个配置文件，后端运维统统都不要了。好处显而易见，服务弹性伸缩，价格按量收费，大多数的运维问题，你的云服务提供商统统帮你兜了，小学生也能写网站。

这么牛逼，前端可得好好学学，让后端和运维统统下岗咯？

Serverless、启动！

既然 Serverless 图的就是快，那我们自然是不能自己手动一个一个的去到云服务商那里去手动设置的咯。当然你也可以这么做，只不过我的服务今天就上线，你的服务可能就要等到后天了。

Github 星星 3万个，1000万下载的 serverless npm package，npm install -g serverless，下载！启动！

任意位置，terminal 输入

$ serverless

友好向导一步一步带你迈向 serverless 美好大坑

进入你刚创建的项目，敲下

$ sls deploy

点击屏幕给出的连接！

Hello World!

牛逼！我们的后端服务器已经搭好了！太简单了吧！

国内用户 serverless 自动使用腾讯云以上内容其实在 https://www.serverless.com/framework/docs/providers/aws/examples/hello-world/node/ 都有

套个模板，快上加快

以下内容使用 aws 进行操作

今天我打算做一个信用卡外汇比价工具，三步搞定：

抓取汇率
保存当天汇率（云函数没有状态）
前端计算比价

非常适合 serverless 的初学应用

代码已经开源并上线，欢迎大家边看边 review

成品地址：https://whichcard.xingoxu.com/ 代码地址：https://github.com/xingoxu/whichcard-abroad

serverless 这个框架，还能使用 template 来创建项目，既然图的就是快，找一个现成的模板套进去，填一填就上线是不是更美滋滋

技术栈，就选 nuxt.js，开启 SSR，再加上可编程使用，妙啊

搜一搜

serverless create --template-url https://github.com/tonyfromundefined/nuxt-serverless -n whichcard-abroad

创建项目后，我们编辑一下 serverless.yml，加上非关系型数据库相关配置

resources:
  Resources:
    CurrencyTable:
      Type: AWS::DynamoDB::Table
      Properties:
        TableName: ${env:DYANMODB_TABLE}
        AttributeDefinitions:
          - AttributeName: ${env:DYANMODB_PRIMARY_KEY}
            AttributeType: S
        KeySchema:
          - AttributeName: ${env:DYANMODB_PRIMARY_KEY}
            KeyType: HASH
        ProvisionedThroughput:
          ReadCapacityUnits: 1
          WriteCapacityUnits: 1

数据库需要配置权限，要给运行 lambda function 的用户，也就是第一次使用 serverless 的时候让你发行的那个key所代表的用户，给他权限，那，同样在 serverless.yml 下加入

provider:
  iamRoleStatements:
    - Effect: Allow
      Action:
        - dynamodb:Query
        - dynamodb:Scan
        - dynamodb:GetItem
        - dynamodb:PutItem
        - dynamodb:UpdateItem
        - dynamodb:DeleteItem
      Resource: "arn:aws:dynamodb:${self:provider.region}:*:table/${env:DYANMODB_TABLE}"

好了，我们服务器已经配置完了，开始编写后端

刚才用的这个模板，大多数已经搭建好了，只不过后端这里没有 typescript 支持

tsconfig.json 复制一份，重命名 tsconfig-server.json

配置我就不粘过来了，大家可以自己参考上边连接。

用了 typescript 之后，我得把他变成 js 后才能被 lambda function 给读取，在 webpack.config.js加上 ts-loader。

抓取汇率

我们以 VISA 为例，他的汇率当天公布在这个网页上

我们导入 axios，导入cheerio，三下五除二，jQuery一把梭，轻松加愉快，摸出了他的汇率

import axios from 'axios';
import cheerio from 'cheerio';
import { format } from 'date-fns';

const getVisaCurrency = async ({
  transCurr = "USD",
  billCurr = "JPY",
  date
}) => {
  const { data: htmlBody } = await axios.get<
    string
  >(
    `https://usa.visa.com/support/consumer/travel-support/exchange-rate-calculator.html`,
    {
      params: {
        amount: 1,
        fee: '0.0',
        utcConvertedDate: '',
        exchangedate: format(
          date,
          'MM/dd/yyyy'
        ),
        fromCurr: billCurr,
        toCurr: transCurr,
        submitButton:
          'Calculate exchange rate'
      }
    }
  );
  const $ = cheerio.load(htmlBody);
  const $targetDOM = $(
    '.converted-amount-value'
  );
  const result = $targetDOM
    .eq($targetDOM.length - 2)
    .text()
    .match(/^\d+\.\d+/)![0];

  return result;
};

export { getVisaCurrency };

40行的代码我们就解决了战斗

保存当天汇率

既然按需付费，那么空闲的时候云厂商势必不可能给你资源，因此云函数是无状态这点其实还是比较 make sense 的

虽然我们可以对每个请求都实时抓取一次汇率，但是这显然也太影响打开速度、用户体验了吧。

而且如果被上游发现，对方直接把 aws 一整段 ip 给封了的事情也不是没有

即使是抓取公开数据这种事情，还是静悄悄搞比较好。

直接导入 aws-sdk，草草几行代码就能写好保存工具函数和查询工具函数

源代码

import { DynamoDB } from 'aws-sdk';
import { format } from 'date-fns';

const DATE_FORMAT = 'yyyy-MM-dd';
const DYANMODB_TABLE: string = "currencyTable";
const DYANMODB_PRIMARY_KEY: string = "currency";

const dynamoDBClient = new DynamoDB({
  region: process.env.DYANMODB_REGION
});

const queryFromCache = async (
  date: Date
): Promise<DBCurrencyObject | undefined> => {
  const {
    Count,
    Items
  } = await dynamoDBClient
    .query({
      TableName: DYANMODB_TABLE,
      KeyConditionExpression: `#key=:dt`,
      ExpressionAttributeNames: {
        '#key': DYANMODB_PRIMARY_KEY
      },
      ExpressionAttributeValues: {
        ':dt': {
          S: format(date, DATE_FORMAT)
        }
      }
    })
    .promise();
  if (Count && Count == 1)
    return DyanmodbResultAdapter(
      Items![0]
    ) as DBCurrencyObject;
  return undefined;
};

const storeResult = async ({
  date,
  result,
  billCurr,
  transCurr,
  brand
}): Promise<void> => {
  let cacheResult = await queryFromCache(
    date
  );
  if (!cacheResult)
    cacheResult = {
      date: format(date, DATE_FORMAT)
    };
  if (!cacheResult[brand])
    cacheResult[brand] = {};
  if (!cacheResult[brand]![transCurr])
    cacheResult[brand]![transCurr] = {};

  cacheResult[brand]![transCurr]![
    billCurr
  ] = result;

  await dynamoDBClient
    .updateItem({
      Key: {
        [DYANMODB_PRIMARY_KEY]: {
          S: format(date, DATE_FORMAT)
        }
      },
      TableName: DYANMODB_TABLE,
      UpdateExpression: `set ${brand}=:${brand}`,
      ExpressionAttributeValues: {
        [`:${brand}`]: {
          M: DyanmodbRequestAdapter(
            cacheResult[brand]!
          )
        }
      }
    })
    .promise();
};

export { queryFromCache, storeResult };

DyanmodbRequestAdapter和DyanmodbResultAdapter是为了解决 dyanmodb 存储的时候符合他的sdk的递归的key（加上类型），另外在这里篇幅过长略去了一些类型定义，大家可以在源代码里查看

同时，我们不要忘记，数据在抓取/存储的过程中都有可能发生新请求，因此我们再写一个工具类把刚才的抓取函数包装一下

export function asyncOnce<
  T extends (...args: any) => Promise<any>
>(
  func: (
    ...args: Parameters<T>
  ) => ReturnType<T>
) {
  let running: ReturnType<
    typeof func
  > | null = null;
  return (
    ...args: Parameters<typeof func>
  ) => {
    if (running === null) {
      running = func(...args);
      running.finally(() => {
        running = null;
      });
    }
    return running;
  };
}

前端计算比价

其实我们这个网站，如果没有关于帮助页面的话，就是只有一个页面的网站了。因此其实没有必要暴露 API，不过我这次为了尝试一下Nuxt.js的Programming Usage，那前端和后端就可以非常巧妙的结合在一起

我们直接在 SFC 中 import 进我们刚才写好的抓取函数

import { response } from '@/api/functions/currency';

export default {
  async asyncData(context) {
    let currencyData;
    if (process.server && context) {
      currencyData = await response(
        context.req
      );
    } else {
      const data = await axios.$get(
        '/currency',
        {
          params: { ...someParams }
        }
      );

      currencyData = data;
    }
    return { currencyData }
  }
}

这样的话，就算是 SSR，也不需要自己向自己发送一个 /currency 的请求。

如果我们没有其他页面，那么 /currency 的API也不用暴露，相当于把 Nuxt.js 当成了模板引擎！

写过 Express.js 等的小伙伴很清楚，一般是先生成数据，然后渲染模板，但是在这里，我们的重点是先写好前端后，导入 server 的函数，把请求丢过去拿数据。

是不是很野！（此处应该有惊叹声（哇哦好野））

剩下的写界面啊，写排序啊什么的就略过。

解决一些小问题

记得开启 extractCSS

Nuxt.js 默认不开启 extractCSS，如果你像我一样引了一个 UI 库，还对这个 UI 库自定义了的话，那你的 HTML 可能会长到令人发指。记得在 nuxt.config.js 中启用哦

Nuxt.js 把 aws-sdk 打包进了前端

我暂时还没有深入去看是 Nuxt.js 的 webpack 的问题，还是可能是 vue-loader 的问题（毕竟我们的宗旨是要快）

不过这个问题可以用 nuxt plugin 的方式去回避。

在 plguins 文件夹下创建 getData.server.ts，

把跟 server 有关的写成一个 handler，然后挂载到 Vue 上也可以，context 上也可以，都可以，只要是个在 SFC 中可以访问到的全局方法就可以了。

import Vue from 'vue';
import { response } from '@/api/functions/currency';
import { Context } from '@nuxt/types';

Vue.$serverGetCurrency = (context: Context) => {
  return response(context.req);
};

然后到 SFC 里把刚才 Server 的方法改成这个全局方法

if (process.server && context) {
  currencyData = await Vue.$serverGetCurrency(
    context
  );
}

另外 ts 定义的问题，在函数的旁边 declare 一下就没有问题了（源代码）

记得参考 Nuxt.js Plugins & Vue.js Augumenting Types for Use With Plugins

这么香？我读书少，你不要骗我

Serverless 本身其实并不是什么新鲜东西，云函数运行环境、对象存储、云数据库哪个都不是2019年或者2020年才出现的新东西，但他的想法解决了小微服务的上线速度问题，对刚起步的成长型企业，没有基础设施的小公司，或者是我有一个想法就差一个程序员的公司来说，是一个非常省时间省事情节约人力物力成本的选择。

不过...

本地开发，云端调试¿

就问你怕不怕本地跑得好好的，放到云厂商那边炸了，然后调试无门！为什么会这样呢，我们以 aws 为例，你有没有想过云原生是怎么处理 node_modules 这样的问题的？

Node.js 中的 AWS Lambda 部署程序包

答案是，和你的源代码一起上传！

🐂🍺了我的 aws，也就是说如果你的 node_modules 里边有依赖 native 能力的话，传上去必爆炸，而且你本地还检测不出任何问题。

比如 npm install with AWS Lambda - Stack Overflow

成本问题

云服务商又当基础服务提供商，又帮你干了运维 Scaling 的事情，还提供了友好的 Interface ，这么多这么好的事情，当然不可能是免费的，一年免费与看起来低价的 lambda 的背后，是高额的捆绑消费以及对价格不敏感群体的整体割韭菜

我没有办法直接对比使用 Serverless 的开销与传统服务器的开销，但是以AWS 为例，Serverless 使用的 API Gateway 每百万次 $3.5 请求对于一个正常企业来说，应该是不小的开销，甚至如果遭受一次 DDNS 攻击的话，确实是有点害怕你的房子明天是不是还在了。。。

而相比之下只需要多花几刀钱买一个不错的云服务器，独享内存，相对稳定的CPU，以及几乎无限流量（Fair Use），显而易见应该是一个更省钱的选择。

但还是香

在大公司里有着自己的基础设置，运营着自己的云原生，那么适当的下放一些简单的增删改查需求给前端，效率提升应该是毋庸置疑的。

最后

以上，希望本文的整体思想，又或者是代码片段，能够给你带来一些灵感或者启发。

本文有任何问题欢迎指出，也欢迎你对我写的这个小学生网站提出任何意见。

欢迎给本文打赏（在线要饭）

Serverless から見えてきた一体化設計

Sun, 21 Jun 2020 15:52:35 GMT

最近 Serverless を触ってみましてあるサイトを作ってみました、ってすごく便利で爆速でウェブを作れて、一番なのはNuxt.jsと相性良くてサーバーとフロントエンドが纏まって管理めっちゃ安くなったので紹介したいと思います。

Serverless なにそれ？

一言いうと Cloud Function + Object Storage + Cloud Database + API Gateway and more by Cloud Service Provider. 簡単にいうと Serverless というとある OSS フレームワークが AWS/Azure/GCP などクラウドサービスを一つの設定ファイルにまとめて、バックエンドもいらずサーバーを立てる。

メリットとしては：

サービスの弾性スケーリング
従量制料金
インフラもクラウドサービス業者がやってくれる

肝心のロジックだけ集中する必要なので小学生でもサービスを爆速で作れる時代に入ったかも？

そんなにすごいならみんな覚えたらサーバーエンジニアの職がなくなったんじゃ！

Serverless、やってやろう

以下、AWS を例として使います

爆速を言いまくったので、AWS で一つ一つ設定するわけがない。もちろんそうやっても問題ありませんが、今日俺のサービスを作って発表しますが、君のサービスは後日まで待たなきゃよ。

Github Star 3万個、一千万ダウンロード数の serverless npm package、npm i -g serverlessでインストール、そして、ターミナルでこれを打つだけ

$ serverless

チュートリアルが出てきてお手軽に環境構築を手助けしますね。

そして、作ったプロジェクトのフォルダーに入って、

$ sls deploy

出てきたリンクをクリックして、

Hello World!

すっげぇじゃん、もうサーバー立てましたじゃん！

Serverless と Nuxt.js 相性すごくいい

今日僕は https://whichcard.xingoxu.com/ このサイトを作ります。

何かというと、海外カードを使う時ポイント+手数料がどのカードが一番お得なのがわかんないので、ランキングがあるとわかりやすくと思って作ったわけ。

そして、これを作るために、たった三つのステップ。

為替を取ってきて
当日の為替を保存する（Cloud Functionは無ステータスのため）
フロントエンドで計算してランキングを出します

Serverless の実践としては最適と思いますね。

ソースコードはアップロードしましたので、そちらを見ながらレビューしていただけると大歓迎です。

ってなぜ Nuxt.js

こんなに小さいもので環境構築したくない（爆速したい）
Vue に一番詳しいのでなるべく Vue 使いたい（爆速わけ）
SSR がほしい（←重要）
Programmatically で使える（←超重要）

Serverless テンプレートと設定

んで、検索したら意外と Serverless のテンプレートに Nuxt.js もありますね！テンプレートを使ったら更に開発スピードを加速しよう、いいっすね～

serverless create --template-url https://github.com/tonyfromundefined/nuxt-serverless -n whichcard-abroad

作ったら、serverless.ymlを編集します。Non-relation Database周りの設定をします。

resources:
  Resources:
    CurrencyTable:
      Type: AWS::DynamoDB::Table
      Properties:
        TableName: ${env:DYANMODB_TABLE}
        AttributeDefinitions:
          - AttributeName: ${env:DYANMODB_PRIMARY_KEY}
            AttributeType: S
        KeySchema:
          - AttributeName: ${env:DYANMODB_PRIMARY_KEY}
            KeyType: HASH
        ProvisionedThroughput:
          ReadCapacityUnits: 1
          WriteCapacityUnits: 1

データベースに権限を与えないとはいけないので、lambda function を走ってるユーザー、すなわち serverless を叩くときに key を発行されたユーザーに権限を与えますので、serverless.yml の中にこれを加えよう

provider:
  iamRoleStatements:
    - Effect: Allow
      Action:
        - dynamodb:Query
        - dynamodb:Scan
        - dynamodb:GetItem
        - dynamodb:PutItem
        - dynamodb:UpdateItem
        - dynamodb:DeleteItem
      Resource: "arn:aws:dynamodb:${self:provider.region}:*:table/${env:DYANMODB_TABLE}"

はいサーバー設定終了🙌おめでとう

次は、バックエンドのTypeScriptを追加します

このテンプレートはバックエンド全部設定してくれましたが、バックエンドのTypeScriptは追加してないので、

tsconfig.json をコピーして、tsconfig-server.jsonに変更します。

内容もちょっと変わりましたが、ここに貼らなく上のリンクに見に行っていただけると🙏。

TypeScript追加したら js にコンパイルしなきゃ node.js の lambda function には使えないので webpack.config.jsにts-loaderの追加をお忘れなく。

為替を取ってきて

VISA カードを例として、為替はここで公表されます。

axiosとcheerioを導入して、jQuery感で40行のコードで楽に為替を取ってきました

import axios from 'axios';
import cheerio from 'cheerio';
import { format } from 'date-fns';

const getVisaCurrency = async ({
  transCurr = "USD",
  billCurr = "JPY",
  date
}) => {
  const { data: htmlBody } = await axios.get<
    string
  >(
    `https://usa.visa.com/support/consumer/travel-support/exchange-rate-calculator.html`,
    {
      params: {
        amount: 1,
        fee: '0.0',
        utcConvertedDate: '',
        exchangedate: format(
          date,
          'MM/dd/yyyy'
        ),
        fromCurr: billCurr,
        toCurr: transCurr,
        submitButton:
          'Calculate exchange rate'
      }
    }
  );
  const $ = cheerio.load(htmlBody);
  const $targetDOM = $(
    '.converted-amount-value'
  );
  const result = $targetDOM
    .eq($targetDOM.length - 2)
    .text()
    .match(/^\d+\.\d+/)![0];

  return result;
};

export { getVisaCurrency };

当日の為替を保存する

従量制課金なので、空いている時はリソースは配られるわけがない、なのでCloud Functionは無ステータスは筋が通っている。

一つのリクエストに対して、為替を取ってくるのは問題ないが、ユーザーエクスペリエンスとしては最低でした…

しかも、データが取られたサイトに見つかられたら、AWSのIP全部ブロックすると一番やばい。パブリックデータとしても、少しモラルがある方法で取るほうがいい。

aws-sdk をインポートして、TypeScriptではちょっと転換面では面倒（型定義では少しコード増やさなきゃ）だけど、基本的には時間かかってないと気がする。

import { DynamoDB } from 'aws-sdk';
import { format } from 'date-fns';

const DATE_FORMAT = 'yyyy-MM-dd';
const DYANMODB_TABLE: string = "currencyTable";
const DYANMODB_PRIMARY_KEY: string = "currency";

const dynamoDBClient = new DynamoDB({
  region: process.env.DYANMODB_REGION
});

const queryFromCache = async (
  date: Date
): Promise<DBCurrencyObject | undefined> => {
  const {
    Count,
    Items
  } = await dynamoDBClient
    .query({
      TableName: DYANMODB_TABLE,
      KeyConditionExpression: `#key=:dt`,
      ExpressionAttributeNames: {
        '#key': DYANMODB_PRIMARY_KEY
      },
      ExpressionAttributeValues: {
        ':dt': {
          S: format(date, DATE_FORMAT)
        }
      }
    })
    .promise();
  if (Count && Count == 1)
    return DyanmodbResultAdapter(
      Items![0]
    ) as DBCurrencyObject;
  return undefined;
};

const storeResult = async ({
  date,
  result,
  billCurr,
  transCurr,
  brand
}): Promise<void> => {
  let cacheResult = await queryFromCache(
    date
  );
  if (!cacheResult)
    cacheResult = {
      date: format(date, DATE_FORMAT)
    };
  if (!cacheResult[brand])
    cacheResult[brand] = {};
  if (!cacheResult[brand]![transCurr])
    cacheResult[brand]![transCurr] = {};

  cacheResult[brand]![transCurr]![
    billCurr
  ] = result;

  await dynamoDBClient
    .updateItem({
      Key: {
        [DYANMODB_PRIMARY_KEY]: {
          S: format(date, DATE_FORMAT)
        }
      },
      TableName: DYANMODB_TABLE,
      UpdateExpression: `set ${brand}=:${brand}`,
      ExpressionAttributeValues: {
        [`:${brand}`]: {
          M: DyanmodbRequestAdapter(
            cacheResult[brand]!
          )
        }
      }
    })
    .promise();
};

export { queryFromCache, storeResult };

DyanmodbRequestAdapterとDyanmodbResultAdapterは aws-sdk を使うためにデータの転換関数。長いのでここで貼らなく、ソースコード見ていただけると思います。

データを取る時と保存する時リクエストが来る可能性もありますので、asyncOnceの関数を書いて入り口をラッピングして一回だけ実行させることを保証しましょう。

export function asyncOnce<
  T extends (...args: any) => Promise<any>
>(
  func: (
    ...args: Parameters<T>
  ) => ReturnType<T>
) {
  let running: ReturnType<
    typeof func
  > | null = null;
  return (
    ...args: Parameters<typeof func>
  ) => {
    if (running === null) {
      running = func(...args);
      running.finally(() => {
        running = null;
      });
    }
    return running;
  };
}

フロントエンドでランキングを計算します

さっきも言ったけど、Nuxt.js の Programmatically で使えるのは重要。なぜ重要というと、Cloud Function の入り口は一つで、リクエスト来る時フロントエンドのレンダリングとAPIのサービングは両方立たなきゃ。

従来のやり方としては、Express.js などでRouterを追加して、静的HTMLをレンダリングする、いわゆるサーバーレンダリング。

それだとフロントエンドエンジニアにとってはちょっと不便、でもこれを使ったら、サーバーとフロントが賢く纏まった。

ちょっと見てみましょう

SFC でさっき書いたサーバー関数を import します

import { response } from '@/api/functions/currency';

export default {
  async asyncData(context) {
    let currencyData;
    if (process.server && context) {
      currencyData = await response(
        context.req
      );
    } else {
      const data = await axios.$get(
        '/currency',
        {
          params: { ...someParams }
        }
      );

      currencyData = data;
    }
    return { currencyData }
  }
}

そしたら、SSR の場合はサーバー自身が自身の /currency にリクエストすることはなくなりました。

また、この設計のいいところは、もしほかのページがなければ、/currency の API も外に出さなくてもいいです、Nuxt.js をテンプレートエンジンとして使った。

Node.js をサーバーとして使った方はわかると思います、普通のサーバーレンダリングはデータ生成してからレンダリングするが、ここではフロントエンドを先に書いちゃって、その後サーバーの関数をインポートして、データを取る。

書き心地もわかりやすい。

すごくない？

残りはインターフェイスなどは、ここでは略します。

問題を解決

extractCSS をつける

Nuxt.js はデフォルトとしては extractCSS を閉じてます、UI Frameworkを使った方はもしかしてHTMLはとんでもない長さにされました。nuxt.config.js にての起用をお忘れなく。

Nuxt.js が aws-sdk をフロントエンドのJavaScriptにバンドルしまった

Nuxt.js の webpackか、vue-loaderかどっちの問題まだ深く見てないが（爆速で作るわけ）、nuxt plugin で迂回することはできる。

plguins フォルダ下に getData.server.tsを作ります、

サーバー関数をhandlerにして、Vue でもいいし、context でもいいし SFC でアクセスできるグローバル関数であればOK。

import Vue from 'vue';
import { response } from '@/api/functions/currency';
import { Context } from '@nuxt/types';

Vue.$serverGetCurrency = (context: Context) => {
  return response(context.req);
};

SFCでさっきのところでこの関数を使う

if (process.server && context) {
  currencyData = await Vue.$serverGetCurrency(
    context
  );
}

TypeScriptの型定義なら、その関数の隣で declare すればどこでも問題ないはずです（ソースコード）

レファレンス Nuxt.js Plugins & Vue.js Augumenting Types for Use With Plugins

めっちゃ便利、落とし穴ないの？

Serverless は新しいものではない、Cloud Function、Object Storage、Cloud Database どっちでも2020年から出たものではない。ただそのコンセプトはスタートアップ企業のサービスのラウンチスピードをすごく手助けしました。彼達にとって、サーバーさえもないし、エンジニアもわずか数人もしくは一人だけかもしれませんが、そんな状況の企業にはとてもふさわしいも過言ではない。時間とコスト両方省けられる選択です。

でもね…

ローカルで開発、そらでデバッグ

「あら、ローカルでちゃんと動いてるのに、アップロードしたらエラーが出ちゃった！」それはなぜですか？AWS を例としてCloud Native はどう node_modules を処理してるのは見てみましょう。

Node.js の AWS Lambda デプロイパッケージ

その答えは、コードと一緒にアップロードします。

つまり、node_modulesにnode-gypなど native を依存してるかつ aws のハードウェア適してない場合は必ずエラーが出るのではないか、しかもローカルでは検知できない。

ほら npm install with AWS Lambda - Stack Overflow

コスト

さっきまだコストを省けると言ったのに、それなぜまた問題と視されますか？

クラウドサービスプラットフォーム、ベーシックサービスを提供しながら、インフラ、自動スケーリング、フレンドリーインターフェイスも提供し、そんなにいいこと無料のわけがない。最初に一年無料、従量制課金の後ろは、他のサービスを同梱して一緒に課金しちゃうと、価格に対して敏感ではない人を「騙す」

Serverless と従来のサーバーを直接で比較することはできない、ただ、AWS の API Gateway 百万回 $3.5の料金は高くない？DDNSを受けたら、お家飛んできそうよ。

$5では vultr 買えます、しかも無限トラフィック、安定してるリソース、サービスがでかくなったらコスト的には絶対勝つと思います。

クラウドサービスプラットフォームに対しての依存性

AWS でサービスを立ったが、後日 AWS と揉めたら、また Amazon と利益上で対立して他のクラウドサービスに行きたい、もしくは自分のサーバーがありまして自分のサーバーに移行しようとすると、コードをもう一度書かなきゃし、設定とか見直さないとも行けないし…

でもそのいいところを忘れないで

もしでかい会社のであれば、自分がそのインフラ持ってて、Serverless みたいのものを作ったら、適当に簡単なものをフロントエンド側に任せたら効率的にはすごく早いのではないかと考えられますね。

以上

ご閲覧ありがとうございました、この記事の考え、コード、あなたにアイデアまたはインスピレーションをもたらしたら嬉しいです。

記事について質問、またはこの小学生も作れるウェブサイトについて意見があれば大歓迎です。

Google I/O 2019 Web 前端内容总结

Fri, 17 May 2019 16:55:59 GMT

Web 新产品 / 新技术

web.dev
- https://web.dev
- 一个可以用来学习框架、性能、各种 Web 技术的地方
- 还有实战 Codelab
- 正在进行多国翻译
Lighthouse Performance Budgets
- https://developers.google.com/web/tools/lighthouse/audits/budgets
- 在Lighthouse中设定性能预算，让Lighthouse在测试性能时使用并打分
PWA Desktop
- PWA现在可以各大桌面平台系统中安装了
Trusted Web Activity
- https://developers.google.com/web/updates/2019/02/using-twa
- Chrome Custom Tab 的升级版，不再显示标题栏
- 一个常见的使用场景是在已有的App中去使用PWA来打包家族应用并打造原生体验
- 在网页中可以使用schema url来与App通信
- App可以在网址后附上参数给网页发送数据
Perception Toolkit
- https://web.dev/perception-toolkit
- 一个工具包使用Shape Detection API去扫描条码或者获取实物信息
- 从网站的 meta 信息展示相关卡片
- 提供了WebAssembly版以向下兼容
Puppeteer with Firefox
- 可以使用Firefox进行自动化了
- npm i puppeteer-firefox

Web 将来可以使用的新功能 / 新Web API / 新 JavaScript API 等

Chrome Only (目前为止，没有写入w3c标准)

Lazy loading
- 在图片和iframe中添加 loading="lazy" 属性来让浏览器自动懒加载
- Chrome 75 启用
Portals
- https://web.dev/hands-on-portals
- 一个新tag，类似iframe，以提供转到网页中嵌入内容的无缝体验
- 可以在Chrome Canary体验
Web Packaging
- https://github.com/WICG/webpackage
- 对网页进行签名打包，在不同服务器上部署，使得浏览器可以不仅在源服务器上获取内容（p2p的感觉）
- 暂时没有任何 demo
Paint Holding
- 同一网站切换页面时将保持之前的绘制不会白屏一次
- Chrome Canary 可预览
Cookie Changes upcoming in Chrome 76
- https://web.dev/samesite-cookies-explained
- 没有添加Same-Site的Cookie将会自动适用Same-Site=LAX

Chrome 正在开发的

关联Session： What’s New with Chrome and the Web (Google I/O ’19)

Web API

开发中
- 分享 -> Web Share API (Shipped) -> Web Share Target (v2) (Working)
- media control on System level -> mediaSession API (Shipped)
- 检测条码与形状 -> Shape Detection API (FaceDetect / BarcodeDetect both shipped in Chrome Canary)
- App Badging (App上的数字) -> window.Badge / window.ExperimentalBadge (Origin Trial 78)
- 唤醒锁 -> (Screen wake lock / System wake lock) -> Wake Lock (In Development)
- 文件操作 -> File Picker -> chooseFileSystemEntries (propse stage / In Development)
- 访问串口设备（例如打印机） -> Serial API (Proposed API)
- HID 设备访问 -> WebHID (Proposed API / In Development)
- 访问通讯录 -> Contacts Picker (Proposed API / Experimenting)
- 访问安装字体列表 -> Proposed / In Development
很快实装
- 剪贴板复制与粘贴图片 Clipboard API
- 基于短信的手机号验证流程
- 基于时间的推送通知API Notification Triggers API

以上内容年内实装

在 Chrome 中可参与试用并参与反馈 https://developers.chrome.com/origintrials

Web API 可在 Project hugu 参阅进度 Project hugu

相关Session： Unlocking New Capabilities for the Web (Google I/O ’19)

JavaScript API / Syntax

类的私有字段 (已实装) - working on privatter method and getters and setters
String.prototype.matchAll (已实装)
数字分隔 (Chrome 75)
BigInt (Chrome 74 与 Firefox nightly 与 node 实装 & transpiler available)
Array.prototype.flat (in chrome firefox safari node)
从 Entries 反转化为 Object (in chrome firefox safari node )
globalThis (in chrome firefox safari node )
正在将数字排序的稳定性写入标准
多国语言相关
- Intl.RelativeTimeFormat -> today yesterday tomorrow (in chrome firefox node)
- Intl.ListFormat -> ex. A, B or C (in chrome node)
- Intl.DateTimeFormat -> ex. May, 5 (in chrome)
- Intl.Locale -> Internal Translation (in chrome node)
Promise.allSettled (in chrome 76 nightly) / Promise.any
WeakRef and finalizers (in chrome with flags) & 写入标准

关联Session： What’s new in JavaScript (Google I/O ’19)

经验分享与性能提升

Chrome 想为各个框架提供一些API这样他们在连续执行分块任务时同时相应用户输入

Scheduling API
- https://github.com/WICG/main-thread-scheduling
- https://github.com/WICG/is-input-pending
- https://github.com/WICG/display-locking

Google 分享了他们在性能上的一些做法和建议

阶段式SSR
捕获JS完全加载前的用户点击
保持初始大小的JS
交互驱动懒加载组件
建立依赖关系图，声明性加载功能，同时获取数据

Google 的性能建议

懒加载
响应式图片（根据设备像素密度等加载不同分辨率图片）
图片CDN
延迟第三方JS
移除代价巨大的库
分离代码
避免Web Font字体闪烁
Prefetch
Preconnect
Preload
首屏关键CSS
gzip -> Brotli
响应式加载JS（适应不同浏览器分别加载不同JS）

以及使用Lighthouse 与设定性能预算 LightWallet

相关Session：
Elevating the Web Platform with the JavaScript Framework Community (Google I/O ’19)
Speed at Scale: Web Performance Tips and Tricks from the Trenches (Google I/O ’19)

其他

更多性能其他案例、How to、以及Web内容可参照 https://www.youtube.com/playlist?list=PLNYkxOF6rcIATmAmz7HcCzongGvQEtx8i

Google I/O 2019 フロントエンドまとめ

Fri, 17 May 2019 16:55:59 GMT

Web 新プロダクト / 新技術

web.dev というサイト
- https://web.dev
- フレームワーク、パフォーマンス、Web各種技術など載っているグーグルが作ったまとめサイト
- 全部無料で学べる
- 今フレームワークはReact.jsだけけど、今後追加予定
- 実践 Codelab、その場で試すことはできます
- 翻訳は今進行中らしい
Lighthouse Performance Budgets
- https://developers.google.com/web/tools/lighthouse/audits/budgets
- Lighthouseにパフォーマンス時間 / ファイル大きさ予算を設定し、Lighthouseが測ってくれる
PWA Desktop
- PWA 今デスクトップOSにインストールできます
Trusted Web Activity
- https://developers.google.com/web/updates/2019/02/using-twa
- Chrome Custom Tab のアップグレード版、タイトルバーがない
- よく見られるユースケースは、現存のアプリの中で、ファミリーアプリのウェブ版を入れて、ネイテイブ感を作る
- ウェブページにはschema urlでアプリにメッセージ送れます
- アプリは URL の後ろにパラメータ付けるならウェブページにメッセージ送れます
Perception Toolkit
- https://web.dev/perception-toolkit
- Shape Detection APIを使ってるツールキット
- バーコード、実物、画像を取得してウェブサイトのmetaから取った情報と比較して、関連カードを出す
- APIまだ使えないブラウザにWeb Assemblyを使う、互換性を保つ
Puppeteer with Firefox
- Firefoxが使えるようになりました
- npm i puppeteer-firefox

Web にもうすぐ使えるもの / 新Web API / 新 JavaScript API など

Chrome Only (w3cにまだ書いてない)

Lazy loading
- 画像とiframeの中 loading="lazy" のアトリビュートを追加すると遅延ロードくれます
- Chrome 75 から
Portals
- https://web.dev/hands-on-portals
- 新たな要素、iframeみたい、埋め込む内容に切り替えるスムーズ体験を提供する
- Chrome Canary 使える
Web Packaging
- https://github.com/WICG/webpackage
- ウェブサイトをサインしてパッケージして、どこでもデプロイして、ブラウザはどこでも同じサイトとみなす（p2pの感じ）
- 例はまだない
Paint Holding
- 同じサイト画面遷移時白い画面は出ない
- Chrome Canary 見れる
Cookie は Chrome 76 からちょっと変わる
- https://web.dev/samesite-cookies-explained
- Same-Site使っていないCookieはSame-Site=LAXを適用する

Chrome今開発中もの

関連Session： What’s New with Chrome and the Web (Google I/O ’19)

独自APIを開発するから海外でも好評得ていないらしい…

Web API

開発中
- ウェブシェア -> Web Share API (Shipped) -> Web Share Target (v2) (Working)
- media control on System level -> mediaSession API (Shipped)
- バーコード、画像、実物探知 -> Shape Detection API (FaceDetect / BarcodeDetect both shipped in Chrome Canary)
- App Badging (アプリアイコンの数字) -> window.Badge / window.ExperimentalBadge (Origin Trial 78)
- Wake Lock -> (Screen wake lock / System wake lock) -> Wake Lock (In Development)
- ファイル -> File Picker -> chooseFileSystemEntries (提案中 / In Development)
- シリアルデバイスサクセス（プリンターなど） -> Serial API (提案済み)
- HID デバイスアクセス -> WebHID (提案済み / In Development)
- 連絡帳サクセス -> Contacts Picker (提案済み / Experimenting)
- インストールしたフォントをアクセス -> 提案済み / In Development
もうすぐ実装します
- Clipboard API with Image （クリップボードAPIに画像も添付できる）
- SMS基づくOTP検証
- Notification Triggers API （時間基づくプッシュ通知）

上記内容年内実装 Chrome で試すまたフィードバックは下記サイトまで https://developers.chrome.com/origintrials

Web API は Project huguで確認できます Project hugu

関連Session： Unlocking New Capabilities for the Web (Google I/O ’19)

JavaScript API / Syntax

Class のプライベート属性 (実装済み) - working on privatter method and getters and setters
String.prototype.matchAll (実装済み)
Number spearater (Chrome 75)
BigInt (Chrome 74 と Firefox nightly と node 実装済み & transpiler available)
Array.prototype.flat (in chrome firefox safari node)
Entries から Object に転換する Object.entriesの逆操作 (in chrome firefox safari node )
globalThis (in chrome firefox safari node )
Array.sortの安定性を標準の中に書くように努力してる
多言語について
- Intl.RelativeTimeFormat -> today yesterday tomorrow (in chrome firefox node)
- Intl.ListFormat -> ex. A, B or C (in chrome node)
- Intl.DateTimeFormat -> ex. May, 5 (in chrome)
- Intl.Locale -> Internal Translation (in chrome node)
Promise.allSettled (in chrome 76 nightly) / Promise.any
WeakRef and finalizers (in chrome with flags) & 標準の中に書くように

関連Session： What’s new in JavaScript (Google I/O ’19)

経験シェアとパフォーマンス

Chrome はフレームワークなどスケジュールAPIを提供したい、連続実行、レンダリングの時もユーザーの操作受けるように。

Scheduling API
- https://github.com/WICG/main-thread-scheduling
- https://github.com/WICG/is-input-pending
- https://github.com/WICG/display-locking

Google はパフォーマンスにやり方とアドバイス

段階的SSR
JS完全ロード前のクリック事件を取るように
一定サイズの初期JS
インタラクション駆動型遅延ロード
依存関係グラフ、宣言型機能ロード、同時にデータを取る

Google のパフォーマンスアドバイス

遅延ロード
レスポンシブ画像（ピクセル密度による画像をロードする）
画像CDN
サードパーティのJSを遅延する
高価なライブラリを削除する
コード分割
Web Fontの白いフラッシュを避ける
Prefetch
Preconnect
Preload
クリティカルCSS（はじめの画面だけ必要のCSSをロードする）
gzip -> Brotli
端末、ブラウザによるJSをロードする

また、Lighthouse を使って、性能予算を設定する

関連Session：
Elevating the Web Platform with the JavaScript Framework Community (Google I/O ’19)
Speed at Scale: Web Performance Tips and Tricks from the Trenches (Google I/O ’19)

その他

他のパフォーマンスユースケース、ノウハウ、Web内容はここへ https://www.youtube.com/playlist?list=PLNYkxOF6rcIATmAmz7HcCzongGvQEtx8i

群晖 NAS 打造自动电视录像服务器

Thu, 16 May 2019 15:47:37 GMT

什么是录像服务器

录像服务器就是指将电脑接上电视天线，把电视节目自动录制下来并保存在硬盘上。在日本许多电视机都会自带录制功能，指定节目之后每周录制相同时间段的节目，或者指定条件，自动录制符合条件的节目。这次我们就要来尝试在NAS上搭建这么一个录制服务器。

为什么我们要搭建这样的服务器

既然电视机已经有了这样的功能，为什么还需要额外搭建这样的服务器呢。电视机确实已经很强大，但我们也有串流需求，在家，在外边，在笔记本上随时随地都想收看录制的电视节目的话，只有一个电视机和收看设备的话很难做到。搭建了这个服务器之后，我们还能实现在手机在电脑实时观看电视直播功能，画质当然与电视台一致。

为什么要放在NAS上

还不是为了拯救我那24小时开机的NAS但却只用来同步文件的电老虎吗

需要准备的东西

你的一台NAS
- 我们需要在上边接上电视天线并运行录制程序
- 需要能够运行Docker与虚拟机（你可以在这里查看兼容机型）
PLEX USB地上波天线 PX-S1UD V2.0
- 一个作为录制电视的初始入门的USB天线
- 不贵，约4530日元
- 一根天线只能录制一个节目，需要录制多个电视节目可以买多个
- 亚马逊购买链接
SCM IC读卡器
- 用来读取 B-CAS 卡、1000日元左右
- 亚马逊购买链接
- 注意这个发货并不一定是同一个品牌同一型号的读卡器，在之后的测试读卡器部分可能会出现一些问题，需要做好强大的心理准备
- 也可以用SoftCAS，不过感觉不是很可靠以及有触犯法律风险，不在本篇讨论范围
大硬盘
- 用来保存你的节目
B-CAS 卡
- 测试你可以从现在的电视上拿下来借用
- 后期你可以从不用的中古电视或者DVD录像机上取下来借用
- 亚马逊上可能有人出品，但买卖B-CAS卡可能触及法律风险需要注意
天线分波器 / 分配器、一根天线连接线
- 把一根天线变成两根天线的东西，或者把地上波与BS/CS波分开的东西，根据个人需要进行购买，并不必须

注意

以下内容仅保证文章撰写时点的有效性，本文并不面向初级用户，请仅有一定动手能力以及自己能够解决途中出现的问题的读者进行搭建，并请自行负担出现的任何问题与责任。电视节目的复制，传播可能触及相关法律，在使用时请十分注意。由于参考了本文进行的操作发生的任何损失，作者不负担任何责任与赔偿。

架构说明

NAS 准备

安装Docker
安装 Virtual Machine Manager
在虚拟机里安装Ubuntu 16或者18.04 或者随便你喜欢的发行版
- 本文将以Ubuntu 18.04作为参考进行，其他发行版本请自行注意路径等
- 但无论如何注意 Linux 内核版本必须高于3.15（原因下述）
- 建议将虚拟机的Ubuntu设置成仅内网访问

准备天线

进入Ubuntu虚拟机，安装天线驱动，具体操作步骤：

$ wget http://plex-net.co.jp/plex/px-s1ud/PX-S1UD_driver_Ver.1.0.1.zip
$ unzip PX-S1UD_driver_Ver.1.0.1.zip
$ sudo cp PX-S1UD_driver_Ver.1.0.1/x64/amd64/isdbt_rio.inp /lib/firmware/

就算完成了

因为天线驱动最低支持3.15的Linux内核，而群晖的内核是3.10，导致没有办法将天线与调用天线驱动的内容放置在主机本体运行，才不得不使用了虚拟机这样的结构。

如果群晖之后升级到了3.15以上的内核，那可以尝试一下使用 https://github.com/Chinachu/docker-mirakurun-chinachu 的 Docker 镜像。

准备读卡器与B-CAS卡

在Ubuntu虚拟机内安装一些工具（之后也会使用到）与读卡器驱动

$ sudo apt-get install build-essential git cmake g++
$ sudo apt-get install pcscd libpcsclite-dev libccid pcsc-tools

安装完毕之后，使用 sudo pcsc_scan 命令，如果出现了 Japanese Chijou Digital B-CAS Card (pay TV) 类似的字样，那么B-CAS卡的安装和驱动就顺利完成了

笔者在这里碰到过两个问题，一个是B-CAS插反了，没读到芯片（汗），另一个是B-CAS卡无效问题。 B-CAS卡如果无效的话，是会顺利出线上述字样的，但是之后无法正常使用录制电视，可以将B-CAS插上电视看一下是否有错误提示。

另外如果使用的不是NEC读头的读卡器，可能会没法扫描出或者没法启动pcscd（参考的原文章作者碰到了这个问题），读者可以自行搜索相关方法或参考下方参考文章链接。

安装B-CAS解码用的相关库

由于日本地上波加密后进行广播，直接录制的话也没法播放和保存。因此我们需要在接收信号的同时使用B-CAS卡进行解码并无视加密。实现这个的是一个叫libarib25的库。

这个库需要编译。

$ wget https://github.com/stz2012/libarib25/archive/master.zip
$ unzip master.zip
$ cd libarib25-master
$ cmake .
$ make
$ sudo make install

完成安装

安装录像指令

我们需要安装recdvb这个录像指令，之后的录像管理都会调用这个指令来进行。源代码是公开的但是没有放在github上，需要编译安装。

$ wget http://www13.plala.or.jp/sat/recdvb/recdvb-1.3.2.tgz
$ tar xvzf recdvb-1.3.2.tgz
$ cd recdvb-1.3.2
$ ./autogen.sh
$ ./configure --enable-b25
$ make 
$ sudo make install

完成安装。

安装之后就可以使用这个指令直接录制电视节目了。比如

$ recdvb --b25 --strip <channel> <seconds> test.m2ts

channel根据地区，放送电波塔不同，数字不同，可以在这里进行确认。

另外，可以使用

$ recdvb --b25 --strip --http <port>

指令，在本地起一个服务器推送流，使用VLC或者IINA可以打开

http://[IPアドレス]:8080/[channel number]

channel number就是上边那个数字。

但，在这之前，需要在Ubuntu虚拟机的/etc/hosts中设定连接者的ip域名（为了保证安全），我的话并没有在外网访问Tuner Server的想法，并不需要这样的设定，因此修改源代码重新编译安装。

参考 https://nyanonon.hatenablog.com/entries/2015/11/17

按下 Ctrl+C 关闭推送流服务器。

安装mirakurun 建立Tuner Server

Mirakurun是一个Node.js编写的系统，具有同时多频道录像，多天线管理，优先度处理功能。以及提供了各种API，以方便对应各种客户端的请求，在外网无法直接访问服务器也可以管理预约录制节目等。

安装Mirakurun可以参照

https://github.com/Chinachu/Mirakurun/blob/master/doc/Platforms.md

以下内容方便参照部分搬运

安装 Node.js 10

请参照 https://github.com/nodesource/distributions/blob/master/README.md#debinstall

安装 PM2

sudo npm install pm2 -g

安装Mirakurun主程序

sudo npm install mirakurun -g --unsafe-perm --production

配置Mirakurun

主要是对Tuner进行配置，

mirakurun config tuners

这里卡了很久，一直没法成功录制，但最终注释掉了一些奇怪的配置就搞定了

- name: PX-S1UD-1
  types:
    - GR
  command: recdev --b25 --strip <channel> - -
  isDisabled: false

mirakurun restart

重启mirakurun之后查看 pm2 log，如果没有错误正常开始Recording，表示搭建成功。

频道的话对Tuner设置成功之后会自己更新频道并更新节目列表，因此无需其他操作，一个天线的情况下耐心等待5分钟到10分钟左右即可。

到这里为止，我们所有服务端的设置基本就完成了，Mirakurun本身已经提供了API，可以通过API进行调用获得节目信息或者录制，也提供了Http流推送，来方便其他客户端进行录制。

API使用等可以参阅

https://github.com/Chinachu/Mirakurun

安装Chinachu以及ffmpeg等软件

我们需要一个可视化客户端来帮助我们管理预约，对Mirakurun进行下达命令。于是我们需要安装Chinachu。

由于这里开始，我们可以在Docker中也能完成这样的任务，搭建过程就省略，取而代之大家可以到

https://github.com/xingoxu/docker-chinachu-vaapi-ffmpeg

查看DockerFile，或者参照DockerFile自行编写自己需要的脚本来进行搭建Chinachu。

如果读者按照我的镜像进行搭建，需要注意如下（自己编写Docker脚本时也需注意一些Docker问题）

时区问题
- 需要挂载 /etc/localtime:/etc/localtime:ro
Chinachu 的预约/设置数据
- 挂载如下文件与目录以防止容器重建丢失数据、
- ./chinachu/data:/chinachu/data
- ./chinachu/rules.json:/chinachu/rules.json
- ./chinachu/config.json:/chinachu/config.json
日志问题
- Chinachu和pm2已经自带日志，就不需要Docker再帮我们兜一层日志了
- 编写启动脚本并设置入口点

#!/bin/bash

npm install
pm2-runtime processes.json > /dev/null

不要忘记挂载录像目录
- /volume2/TVRecorded:/chinachu/recorded
不要忘记暴露端口

配置Chinachu设置

Chinachu的官方配置文档在这里

https://github.com/Chinachu/Chinachu/wiki/Gamma-Configuration

基本没有什么太多需要注意的，将预设内容拷贝一份挂载进Docker就可以。

需要注意vaapi相关内容，下述。

之后就启动Docker容器吧，启动脚本就请各位自行挂载并启动了也可以使用docker-compose来启动，docker-compose up

搭建成功

输入 NAS 地址和端口号后进入Chinachu界面并能看到节目表基本就算成功了。

添加录制后转码脚本

录制后是m2ts的TS文件，我们可以利用 NAS 闲暇 CPU （x86架构的 nas 基本都具有硬件加速）将 TS 文件转换成 mp4，缩小文件体积保存等。

需要注意的是，如果我们需要使用vaapi（Intel CPU的硬件加速解码），那么我们在启动Docker时需要使用root权限，否则无法访问 /dev/dri/renderD128硬件。

但是录制后的文件的所有者就会变成root，其他应用程序读取或修改的时候会有一些问题，因此我推荐在录制后，转码后，可以自己编写脚本来重新设置权限。

$ chown <uid>:<gid> </path/to/file>

ffmpeg的相关参数我在这里贴出自己的进行共享，你当然也可以参照官方文档进行调整。

$ ffmpeg \
  -init_hw_device vaapi=intel:/dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device intel -filter_hw_device intel \
  -i /path/to/recorded/file \
  -analyzeduration 30M -probesize 30M \
  -vf 'format=nv12|vaapi,hwupload,deinterlace_vaapi' \
  -c:v h264_vaapi  \
  -threads 4 \
  /path/to/output/file

注：这里的环境PATH比较微妙，请一定使用绝对路径。

我写了一个 shell 脚本，将脚本命名成你喜欢的名称，假设 afterRecord ，不要忘记赋予执行权限，在 config.json 中修改

  "recordedCommand": "./userScripts/afterRecord",

你可以根据自己需求修改转码设置，或者添加LINE通知等功能，打造属于自己的录像服务器。

另外一些配置

给WebGUI设置访问权限

直接把 WebGUI 暴露在公网上还是很危险的，我们给界面添加一个密码输入，保证录像服务器只能自己用。

由于我用了 docker-compose ，可以很方便的添加 nginx 并设置反代

生成密码

$ sudo htpasswd -c /path/to/.htpasswd <username>

拷贝至服务器

在服务器上直接生成的可以跳过

修改nginx 配置重启 docker

......
location / {
    proxy_pass   http://localhost:5601;
    auth_basic " Basic Authentication ";      
    auth_basic_user_file "/etc/nginx/.htpasswd";       
}
.....

$ docker-compose restart

刷新界面，此时应该被要求输入密码

添加索引

通过自己的脚本来创建的文件群晖是无法增加索引的，以至于在DLNA广播中无法显示我们转码或者录制的文件

假设我们的录像文件直接存储在/path/to/record/folder下面，我们可以编写脚本

#!/bin/bash

cd /path/to/record/folder

for mediafile in $(find /path/to/record/folder -maxdepth 1 -type f -mmin -<minutes> -not -name .DS_Store)
	do
		synoindex -a $mediafile
	done

其中第三行 cd 不可漏去，否则群晖不会在此文件夹中执行 find 。

保存脚本，假设 reindexTVRecorded，在 控制面板 - 任务计划 - 新增 - 计划任务 - 用户脚本，输入计划，输入任务运行脚本保存即可

存在的问题（没有实现的需求）

字幕
- 有部分电视台同时放送字幕，录制的TS是有字幕的，可以在VLC确认到
- 但没有办法使用网上的通用方法比如assdumper提取出来，提取出来是空的
- 暂时没有尝试使用 Caption2Ass.exe等windows程序
多国声道
- 存在两个问题
1. 使用双声道在单声道中分别放送两个国家的音源（多存在于NHK新闻）
2. 使用多个流推送多国声道
- 无论哪种情况，使用了网上的无论哪种包括 -filter_complex channelsplit 或者 -dual_mono_mode main 都无法成功解决

对以上问题如果有办法解决的读者请联系我 m__m

结束

在手中有NAS的情况下1w不到搭建一个这样的录像服务器还是性价比很高的，之后就可以随时随地观看一些并不那么需要大屏幕观看的内容。

文章中还是充满了自己自身的需求，另外文章编写的时候已经间隔搭建完差不多有一个月左右的时间，有些细节可能没有办法很到位描写清楚，如果你有什么问题，可以在评论区留言。

参考

Raspberry Pi 3+Chinachuで地デジ録画サーバー構築 Linuxの自宅サーバをテレビ化して家中どこでもテレビが見れる環境を作ろう(2) 通过Nginx反向代理配置Basic Authentication实现kibana的访问安全 2017/01/30 時点での録画サーバ構築手順

Synology NASに自宅で録画サーバーを立てました

Thu, 16 May 2019 15:47:37 GMT

なぜNASに

NASを持ってる方多いと思いますし、NASは24時間起動してるので、新しいデバイス買わなく節電できて録画サービスを任せろう。

使うもの

Synology NAS 一台
- アンテナを接続してリコードする
- DockerとVirtual Machine Manager対応機種（機種一覧）
PLEX USB地上波アンテナ PX-S1UD V2.0
- 初心者に優しい地デジアンテナ
- 高くない、4530円
- 1チャンネルのみの視聴、録画が可能、買い足して同時受信チャンネルが増やせる
- 買う
SCM IC读卡器
- B-CASカードの読み取り用、1000円ぐらい
- 買う
- 型番は同じではないかも、SCMじゃないやつ届けられたら自己調整必要
- SoftCASも使えるらしいが、私は使わない
HDD
- 録画した映像保存用
B-CAS カード
- テストはテレビから借りるのはいいと思います
- アマゾンにも誰が売ってるらしいが、自己責任でお願いします
アンテナ分波器 / 分配器、接続線
- TVと同時視聴するため。必須ではない。

注意

記事書く時点だけの有効性を保証します、エンドユーザー、コンピュータ初心者向けではない。以下の手順は全て自己責任で、何かしらの問題が発生しても自力で対処できる方のみ実行してください。テレビ番組のコピー、配信は違法となる場合があります。使用についても十分注意して下さい。この記事を参考にしたことにより生じたあらゆる損害について、著者は一切の責任を負いません。

構造

大体こういう感じでやっていきたいと思います。

NAS の準備

Dockerをインストール
Virtual Machine Manager　をインストール
VMM に Ubuntu 16.04/18.04をインストール
- 他のLinux Distrubtionもできるかも、本記事はUbuntu 18.04で説明します
- Linuxのカーネルは3.15を越えないといけない（理由あと説明）
- LANのみアクセスできるように設定するのはおすすめ

アンテナ設置

VMにアンテナのドライバをインストールします

$ wget http://plex-net.co.jp/plex/px-s1ud/PX-S1UD_driver_Ver.1.0.1.zip
$ unzip PX-S1UD_driver_Ver.1.0.1.zip
$ sudo cp PX-S1UD_driver_Ver.1.0.1/x64/amd64/isdbt_rio.inp /lib/firmware/

完了。

アンテナドライバ最低3.15のLinux カーネル必要なので、Synology NASのLinuxカーネルは3.10なのでVMを立って使います。

もし今後 NAS のカーネルが3.15以上になったら、次回 https://github.com/Chinachu/docker-mirakurun-chinachu の Docker イメージを使ってみたいと思います。

カードリーダーとB-CASの準備

カードリーダーソフトとビルドツールのパッケージをインストールします。

$ sudo apt-get install build-essential git cmake g++
$ sudo apt-get install pcscd libpcsclite-dev libccid pcsc-tools

完了後、sudo pcsc_scan を実行して、Japanese Chijou Digital B-CAS Card (pay TV)みたいものでたら完成です。

しかし、私はここ２つ問題遭った、１つ目は入れ間違えたww、２つ目はB-CASカード無効問題、B-CASカードを最初にテレビに入れて見てみたら多分分かると思います。

型番も問題になるかもしれない、参考した記事の作家さんは遭ったのでそちらの記事をお越しいただければと思います。

B-CASのデコード用ライブラリのインストール

日本の地デジ放送は暗号化された状態で配信されているため、そのまま受信して保存すると再生や複製の際に問題が起こる。そこで、B-CASカードの情報を使って受信と同時に復号するのが望ましい。これを実現するライブラリがlibarib25だ。

コンパイル必要です

$ wget https://github.com/stz2012/libarib25/archive/master.zip
$ unzip master.zip
$ cd libarib25-master
$ cmake .
$ make
$ sudo make install

インストール完了です。

録画用コマンドのインストール

録画ソフトはこれを使って録画しますので、recdvbをインストールします。ソースコードあるんけど、Githubに載っていない。

$ wget http://www13.plala.or.jp/sat/recdvb/recdvb-1.3.2.tgz
$ tar xvzf recdvb-1.3.2.tgz
$ cd recdvb-1.3.2
$ ./autogen.sh
$ ./configure --enable-b25
$ make 
$ sudo make install

インストール完了。

この時点で、コマンドでの録画が可能になった。例えば、

$ recdvb --b25 --strip <channel> <seconds> test.m2ts

チャンネルは受信タワーによる違いますので、こちらから確認できます。

また、

$ recdvb --b25 --strip --http <port>

を使ったらリアルタイムストリーミングを配信します。

Windows / MacのVLCかMacのIINAからURLを開いたら直接見れます。

http://[IPアドレス]:8080/[channel number]

チャンネルは上と同じです。

だが、その前に、 VMの/etc/hostsを設定しなければいけない（安全保障かな）、でも私のチューナーサーバーはWANに公開するつもりはないので下のリンクを参考して解除しました。

https://nyanonon.hatenablog.com/entries/2015/11/17

Ctrl+C を押して終了させます。

Mirakurunをインストールしてチューナーサーバーを立ちます

チューナーサーバーMirakurunではWeb APIを提供して、録画コマンドの並列処理や、複数チューナーの管理、優先度処理など様々な機能が利用できます。 Mirakurunのクライエントを通じて外でも番組を予約もできる。

Mirakurunのインストールはこちらへ参考していただければと思います。

https://github.com/Chinachu/Mirakurun/blob/master/doc/Platforms.md

ざっくりここで書きます

Node.js 10 をインストール

请参照 https://github.com/nodesource/distributions/blob/master/README.md#debinstall

PM2をインストール

sudo npm install pm2 -g

Mirakurun メインプログラムインストール

sudo npm install mirakurun -g --unsafe-perm --production

Mirakurun を設定

Tuner設定

mirakurun config tuners

ここで半日間かかった！わけわからんパラメーターを抜いたら使えました！

- name: PX-S1UD-1
  types:
    - GR
  command: recdev --b25 --strip <channel> - -
  isDisabled: false

Mirakurun再起動します。

mirakurun restart

pm2 log で状況を見てみましょう、特になんのエラーが出てなく、Recording が出たら多分大丈夫です。

チャンネルの設定は Mirakurun は自分が取得しますので、5-10分ぐらい待てばいい。

ここまでチューナーサーバーの設定は完了しました。 MirakurunはAPIとHttp Streamingも提供してるので、 APIの使用はここへ

https://github.com/Chinachu/Mirakurun

Chinachu / ffmpeg をインストールする

でもGUIクライエントがないとめんどくさい、Chinachuをインストールします。

Dockerのイメージを作りましたので、DockerFile参照して使うか、自分がカストマイズするもよい。

https://github.com/xingoxu/docker-chinachu-vaapi-ffmpeg

もし私のDockerFileを参照して立ているなら、下記を注意してください。（Dockerを利用する方も見るといい）

タイムゾーン問題
- /etc/localtime:/etc/localtime:roをマウント
Chinachu の予約、設定データ
- 下記のファイルとフォルダをマウントしてデータを保存しましょう
- ./chinachu/data:/chinachu/data
- ./chinachu/rules.json:/chinachu/rules.json
- ./chinachu/config.json:/chinachu/config.json
膨大ログ問題
- Chinachuとpm2はログ入ってるから、Dockerのログはいらない、エラーだけを出力させろう
- 下記スクリプトを書いて保存して入り口を設定します。

#!/bin/bash

npm install
pm2-runtime processes.json > /dev/null

録画ファルダのマウントをお忘れなく
- /volume2/TVRecorded:/chinachu/recorded
ポートの公開

Chinachu 設定

公式ドキュメント

https://github.com/Chinachu/Chinachu/wiki/Gamma-Configuration

基本、コピーしてちょっとカストマイズすれば大丈夫。

VAAPIについてはあとトランスコードの部分で説明します。

それで、Dockerを起動して、 docker-composeも利用可能ですので、自分のニーズをあわせてChinachuを起動します。

できましたか

NASのURLとポート番号をブラウザに入力して下の画面見れると成功です。

録画後のトランスコード

録画したファイルは大きな生TS、大体 x86 アーキテクチャの NAS はハードウェアアクセラレーションついてるので、速いスピードでmp4にトランスコードして、どこでも見れるコーデックにしながら、ファイルサイズも小さくさせる。

注意するべきのはDockerにvaapi（Intel CPUのハードウェアアクセラレーション）を使うと、rootの権限でアプリを走らないと行けない（/dev/dri/renderD128をアクセスために）

だがこうすると、録画したファイルはrootが所有者になって、他のアプリの編集は出来ないので、録画後、トランスコードした後、chownを走らせましょう。

$ chown <uid>:<gid> </path/to/file>

ffmpegのパラメーターも共有しますが、自分のニーズをあわせて公式ドキュメントを参照して調整できます。

$ ffmpeg \
  -init_hw_device vaapi=intel:/dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device intel -filter_hw_device intel \
  -i /path/to/recorded/file \
  -analyzeduration 30M -probesize 30M \
  -vf 'format=nv12|vaapi,hwupload,deinterlace_vaapi' \
  -c:v h264_vaapi  \
  -threads 4 \
  /path/to/output/file

注意：ここのPATHは絶対にフルパスを指定してください、そうじゃないと妙なところに行っちゃいますよ。

名前をつけて、afterRecordとし、 config.json に

{
  ...
  "recordedCommand": "./userScripts/afterRecord",
  ...
}

を編集して。

自分のニーズ合わせてスクリプトをカストマイズして自分唯一無二のサーバーを作りましょう！僕はLINE通知を入ってて録画したら通知がLINEに来ますね。

NASでやるべきのこと

WebGUI パスワードをつける

WebGUIそのままWANに公開するとちょっと危ない、入るときパスワード機能を入れましょう、自分だけ入ることを確保しましょう。

僕docker-compose を使ったから、すぐ nginx を追加できます。

パスワードを生成する

$ sudo htpasswd -c /path/to/.htpasswd <username>

サーバーにコピーして

サーバーで生成する方はスキップー

nginx を設定して docker-compose 再起動

...
location / {
    proxy_pass   http://localhost:5601;
    auth_basic " Basic Authentication ";      
    auth_basic_user_file "/etc/nginx/.htpasswd";       
}
...

$ docker-compose restart

ブラウザをリフレッシュして、ここでパスワードが求められてるはずです。

NAS 再インデックス

自分のスクリプトで作ったファイルは NAS は知らないので、DLNAとかで出てこない。そこで再インデックスする必要があります。

仮にすべて録画したファイルは/path/to/record/folderの第一層でいる、このようなスクリプトを書いて

#!/bin/bash

cd /path/to/record/folder

for mediafile in $(find /path/to/record/folder -maxdepth 1 -type f -mmin -<minutes> -not -name .DS_Store)
	do
		synoindex -a $mediafile
	done

reindexTVRecordedを名前を付けて、 Control Panel - Task - New - Scheduled - User Script、時間とか選択して、スクリプトのパス入れて「はい」を押したら完了。

残りの問題と課題

字幕
- 録画したTSはVLCで字幕見れますけど、どうすればsrtを抽出できる
- assdumper使ったけど、何も出てこない
- Caption2Ass.exeなどwindowsプログラムは使ってない
多国音声
- ２つの問題があって
1. ステレオで一つずつモノラル音声で２つ国の音声放送された（NHKニュースよくある）
2. 多ストリーミングで多国音声放送された
- -filter_complex channelsplit か -dual_mono_mode main ネットによく見たパラメーターどっちを使ってもエラーが出ちゃう

心当たりがある方教えていただければ幸いです！ m__m

最後

NASがある場合は5000ぐらいで立てるのはいいと思います、今後どこでもテレビを見れると嬉しい。

記事の中は自分自身の特集のニーズいっぱい詰まってるし、記事を書くときも立てたから一ヶ月ぐらいがあって、抜けている箇所があるかもしれないし、変な日本語もあるかも、もし何が不明点があればコメントで書いてくださいー

参考

Raspberry Pi 3+Chinachuで地デジ録画サーバー構築 Linuxの自宅サーバをテレビ化して家中どこでもテレビが見れる環境を作ろう(2) 通过Nginx反向代理配置Basic Authentication实现kibana的访问安全 2017/01/30 時点での録画サーバ構築手順

最後まで読んでいただきありがとうございました！

心灵盟友 Buddy Complex 圣地巡礼

Sun, 13 May 2018 18:13:03 GMT

黄金周里因为自己喜欢的画手太太画了渡瀬青葉，所以又把一年前抛弃的 Buddy Complex 捡起来看了一下，意外的发现还挺好看的。全部看完后昨天圣地巡礼了一下。

这个动画也只有第一集是现实中出现的场景，后边都是未来在天上在船上并没有日本的景色。

千葉県習志野市

通学路のカーブ

非常遗憾自行车店好像在翻新，去年在Google Map上貌似还有的样子

滑り台の公園

小高商店信号機

小高商店

小高商店 2013 年的时候好像因为车站周围改造所以关店了，好遗憾

津田沼駅5番線

非常遗憾的是，没有07:12往三鷹的电车与7:15的中野非始发电车，样式也并不是动画的样子。

津田沼駅4番線

刚才还在5番線的但事实上这里的镜头确实是4番線向5番線方向的景色，但是左边的广告牌却是5番線的广告牌

津田沼駅5番線の広告

東京都笹塚

接下来就是男主被追的场景，这里大多都一模一样。

富士見丘高校前

電気屋前

松屋前

みのん歯科医院前

お茶屋前

TDK 变成了 alba，也是很久以前就变了的貌似

栄湯の脇

国道20号不動産屋前

国道20号

笹塚交差点 DARUMA前

だるま 2013 年关店的，不过其他的地方都能对上

笹塚交差点

高架下

从这里开始难度就变得好高，大家凑合看吧

高架下

高架电车没有地方能拍，就跑的稍微远了一点，不过还是没能拍好

高架の鉄道

高架下

正在制作 valiancer 的中◯屋工厂

高架下

大山交差点这里并没有完全按照现实世界的布景画

大山交差点

到这里就全部结束啦，顺带一提主人公的家是真实存在的，不过因为私人房屋的原因不会上传到SNS等地方，如果有兴趣的访问的话也请一定不要给对方带来困扰。

Google Maps：https://drive.google.com/open?id=1fTiF9I8exv6jFB-86H49elu6EntfaA1q&usp=sharing

バディ・コンプレックス聖地巡礼

Sun, 13 May 2018 18:13:03 GMT

GWなか好きな絵描きさんが渡瀬青葉を描きましたので、一年前見放したバディ・コンプレックスをまた見ていて、意外といい作品と思っています。全部見ました昨日聖地巡礼しました。

1話ラストで未来へ行ってしまって以来、完結編の最後に至っても2014年の東京、千葉の景色が再度登場することはありませんでしたなお本作品の舞台には高校や閑静な住宅街を含みます。もし訪問される際は現地の方へ最大限配慮して行動されるようお願いしたく思います。

千葉県習志野市

通学路のカーブ

津田沼サイクルなくなった、リニューアル中みたいです、グーグルマップによる去年まだあるらしい、残念

滑り台の公園

小高商店信号機

小高商店

小高商店もなくなった、調べたら2013年の時駅周辺改造のため、本当残念

津田沼駅5番線

07:12の三鷹行き電車と07:15の中野行き非津田沼駅始発電車はない、仕様もアニメのものではない。

津田沼駅4番線

作中では5番線になっているが実際描かれていたのは4番線からの景色。でも左端に写っているユザワヤの広告は５番線の広告。

津田沼駅5番線の広告

東京都笹塚

これからは主人公追われた景色。大体一緒です。

富士見丘高校前

電気屋前

松屋前

みのん歯科医院前

お茶屋前

TDKからalbaになっちゃった、多分も大昔の事

栄湯の脇

国道20号不動産屋前

国道20号

笹塚交差点 DARUMA前

だるま 2013 年閉店ですが、他の施設ちゃんと合った。

笹塚交差点

高架下

難易度高くなった

高架下

高架の電車はどこでも取れないから、ちょっと遠いから取ったけど、良くないね

高架の鉄道

高架下

ヴァリアンサーを生産している中◯屋工場です

高架下

大山交差点周りは今までと違ってあまり実際の景色に忠実ではない様子。看板や窓の形など、細かいパーツが一致する程度でしかありませんでした。

大山交差点

ここまで全部終わりました、ちなみに主人公の家は本当に存在している、個人宅なので掲載はしません、興味があれば訪れる時絶対迷惑かけないように

最後までご閲覧いただきありがとうございました。

Google Maps：https://drive.google.com/open?id=1fTiF9I8exv6jFB-86H49elu6EntfaA1q&usp=sharing

推特 Account Activity API 使用体验

Mon, 30 Apr 2018 20:59:43 GMT

前几天使用了一下推特的 Account Activity API，这个 API 支持注册一个 webhook，用于接受授权账户的实时活动（推特文，事件，设置）。

包括以下内容：

推特内容
at 提醒
回复
转发
带评论转发
点赞
发出的私信和接收到的私信
关注
拉黑
屏蔽
阅读回执

在试用的过程中，碰到了一些问题，做一个整理。

应用中心创建应用

首先需要到 https://apps.twitter.com/ 在这里按提示创建应用，获得应用的 key 与 Secret。

申请 Account Activity API 试用权限

https://developer.twitter.com/en/apply 到这里按照提示申请API权限，并附上 app ID（app ID相关解释：https://developer.twitter.com/en/docs/accounts-and-users/subscribe-account-activity/overview ）

申请完成后会收到邮件

注册 webhook

CRC 测试

webhook 的地址要求通过 CRC 测试，详细要求可以查看 https://developer.twitter.com/en/docs/accounts-and-users/subscribe-account-activity/guides/securing-webhooks

写了一个自己的demo，关于CRC测试的代码： https://github.com/xingoxu/twitter-like-downloader/blob/master/routes/twitter.js#L13-L23

通过 postman 发送请求注册 webhook

POST:
https://api.twitter.com/1.1/account_activity/all/env-beta/webhooks.json?url=${你的webhook地址}

Header:
Authorization: Bearer TOKEN

Bearer TOKEN 可以通过https://api.twitter.com/oauth2/token接口获得

注意

webhook 地址需要https，且只能使用443端口（https://twittercommunity.com/t/how-to-register-a-webhook-url-in-twitter/86096/36 ）

通过 postman 发送请求在 subscription 里注册 webhook

GET:
https://api.twitter.com/1.1/account_activity/all/env-beta/webhooks.json

Header:
Authorization: Bearer TOKEN

获取到刚才的 webhook id

之后

POST:
https://api.twitter.com/1.1/account_activity/all/env-beta/subscriptions.json

Header:
Authorization: OAuth 1.0

Body:
webhook_id: 刚才的 webhook id

注意这里需要用OAuth 1.0（用于识别注册的user id）

注册完成后不会有任何返回，HTTP Code: 204 No Conent

注册完成后可以通过

GET：https://api.twitter.com/1.1/account_activity/all/env-beta/subscriptions/list.json

Header:
Authorization: Bearer TOKEN

可以收到

{
    "environment": "env-beta",
    "application_id": "12345678",
    "subscriptions": [
        {
            "user_id": "12345678"  // <- 自己的user_id
        }
    ]
}

测试

随便对一条推特点赞

可以收到推特来的 webhook object。

自己用这个写了一个推特的bot，可以作为参考。 https://github.com/xingoxu/twitter-like-downloader

ツイッターの Account Activity API 使ってみた

Mon, 30 Apr 2018 20:59:43 GMT

前日ツイッターのAccount Activity APIを使ってみました、この API が一つ webhook 登録が可能です、アカウントのリアル活動（ツィート、通知、設定）を受信します。

以下のものが含まれます：

ツィート
at 通知
リプライ
リツイート
引用リツイート
いいね
ダイレクトメッセージとその受信
フォロー
ブロック
ミュート

使う時実際起こった問題を書きました。

アプリを作ります

まずここで https://apps.twitter.com/ チュートリアルに従ってアプリを作って、アプリの key と secret を取得します。

Account Activity API を申請します

https://developer.twitter.com/en/apply ここで権限を申請します，app ID の添付を忘れずに（app ID について：https://developer.twitter.com/en/docs/accounts-and-users/subscribe-account-activity/overview ）

申請成功したらメールが来ます

webhook URL を登録

CRC テスト

webhook は CRC テストを合格しなければ登録できない、具体的な要望はここに書いている -> https://developer.twitter.com/en/docs/accounts-and-users/subscribe-account-activity/guides/securing-webhooks

自分もNode.jsのdemoを書きました、一応参考になれば： https://github.com/xingoxu/twitter-like-downloader/blob/master/routes/twitter.js#L13-L23

postman でリクエストを送って webhook URL を登録します

POST:
https://api.twitter.com/1.1/account_activity/all/env-beta/webhooks.json?url=${あなたのwebhook URL}

Header:
Authorization: Bearer TOKEN

Bearer TOKEN はhttps://api.twitter.com/oauth2/tokenで取得できます。

注意

webhook URL は https と 443 ポートのみサポートします（https://twittercommunity.com/t/how-to-register-a-webhook-url-in-twitter/86096/36 ）

postman でリクエストを送って subscription に webhook を登録します

GET:
https://api.twitter.com/1.1/account_activity/all/env-beta/webhooks.json

Header:
Authorization: Bearer TOKEN

さっきの webhook の id を取って

POST:
https://api.twitter.com/1.1/account_activity/all/env-beta/subscriptions.json

Header:
Authorization: OAuth 1.0

Body:
webhook_id: さっきの webhook の id

注意すべきところ：ここAuthorization は OAuth 1.0（user id 認識ため）

リスポンス内容はない、HTTP Code: 204 No Conent

登録したらここに見えます

GET：https://api.twitter.com/1.1/account_activity/all/env-beta/subscriptions/list.json

Header:
Authorization: Bearer TOKEN

これを受けれます

{
    "environment": "env-beta",
    "application_id": "12345678",
    "subscriptions": [
        {
            "user_id": "12345678"  // <- 自分のuser_id
        }
    ]
}

テスト

好きなツイートをいいねすると

ツイッターサーバーから webhook object 受けれます。

最後、Account Activity API使ってる自家用ツイッターBotです、参考になればぜひ https://github.com/xingoxu/twitter-like-downloader

最後まで閲覧いただきありがとうございました。

再见 2017

Tue, 10 Apr 2018 12:15:49 GMT

忙完这一阵，回过神来已经是2018年的4月了，才有空开始补一些之前没有干完的事情，比如写这一篇2017年的总结。

仔细想想还真的是2017年经历了太多太多事情，很多事情甚至自己都没有想到，感觉自己非常幸运，总的来说是一个很开心的一年。

按时间顺序

跳槽到饿了妈

怎么说，年前就有想跳槽的想法，其实在萌购干着也挺好的，老板也承诺说毕业之后的工资多少多少，价格嘛也不低（跟饿了妈差不多），但始终是有那么点没有安全感，终于逮到个机会去了饿了妈面试，虽然自己是个菜鸡，不过面试的问题还算是都自我感觉挺好的答了下来，于是就很顺利的跳槽到了饿了妈。

也算走到了算是一个不太容易倒闭的公司，体验了各种大公司的流程，效率也挺高的，时间嘛也还行自己手脚比较快所以基本会有一定的空闲时间，不算很多，但可以。

去日本玩

刚进饿了妈不久，就要收拾东西准备攻略自己一个人出去玩啦。半年前的既定安排跟跳槽也无关，不过当时想着4月底5月初的时间段怎么说也得三方啊毕业的准备都差不多了吧，那又是谁知道这个点了我自己居然还会跳槽，真是。。。

嘛操着自己零零碎碎平假名和片假名，也没跟太多人说话，现在想起来我当时到底是怎么旅游的都完全不怎么会说日语，顺顺利利的玩了10天，肥肠快乐，嘛钱也用了不少，差不多一共两万左右吧？

Google Photo

毕业

一霎眼毕业了，当时好像没有什么感觉，取了毕业证书，学位证书，回家就往公司的系统上传表示7.1日起就可以拿正式工资了，只有这点才让我感觉到了毕业。不过现在想想，我居然已经是个社会人了，而且已经实习+上班上了一年了，时间的力量还真是强大，把自己给塑造成了什么样只有回头看的时候才能知道。

我对学校没什么好感，对周围同学也没什么太多好感，4年自己也不知道自己干了什么，只是埋头学了很多东西，所以这4年，嘛也就这样。

N2合格

旅游回来之后发现自己只有一个月时间就要考N2于是工作之余还不停的去做之前买来没做的练习再去查字典，最后考前一星期还买了一本书再做练习，直接就上了考场。考完回来感觉应该能过吧，虽然有一半的语法题我是瞎蒙的，有一篇阅读没有时间看。这种没有范围的考试真的非常吓人，又或者说因为是第一次正正经经考一个完全自学的语言所以会如此害怕。

复习非常累，考试也很累，幸好最后顺利通过，还是很开心的（分数不高啦）

跳槽去了LINE

这算是下半年一直在做的一件事情吧，从9月初开始试试的心态投了一封简历，结果到最后面试走完被发了offer真的非常非常开心又意外，一个是LINE是日本的企业之中应该是我心中最想去的一个企业，Google也好Twitter也好也很想去，但那些真的水平太高，自己99%是不太可能的，不过LINE的话最初我觉得自己可能70%不太可能，不过最后居然能进是非常意外的，另一个意外就是自己其实日语也就是三脚猫水准，也不要说三脚猫了，一脚猫吧，顶多也就看看小学生向的普通动画，在这之前都没跟日本人说过话，推特也只是在去日本玩送东西给太太的时候结下的太太聊天，聊的也不多还不需要太注重细节，就这么烂的水平，居然最后被采用了。

然后就是递签证，返签证，去日本找地方睡觉，上班这样的过程，签证只花了一周不过递签证跟返签证还真是艰辛前前后后块花了一个半月，嘛只能算是好事多磨。期间当然是在饿了妈当没事人一样刷KPI，我觉得如果我不走的话我KPI至少有B吧，A能不能有就不太清楚了。

第一次离开自己家自己一个人住，唔太幸福了，小黄本放题啊~~

要说原因的话，也不太那么好明着说吧，嘛自己来日本的时候的确也是觉得哇这里真好真舒服，想来这里上班呢，另一个是2017下半年也的确发生了很多事，让自己对周围的环境有了一些看法吧。

2018年的计划？

天呐看看去年的计划，什么rxJs，什么后端，什么可视化前端，什么游戏开发，完全没有学嘛。 2018年的话，先把欠账还清吧，下的动画啥的赶紧看完，不过游戏啥的基本都完成了还算是，摸鱼上手（笑）

Bangumi 2017

Vue + TypeScript 尝鲜体验

Wed, 18 Oct 2017 15:04:23 GMT

适用 Vue.version < 2.5 && Vue.version >= 2.2

其实我个人一开始很讨厌 TypeScript 这个东西，就是因为讨厌 Java 的啰里巴嗦，突然在我眼前出现了 Javascript，便爱上了这门语言。

但现在的我稍稍又觉得这样的东西其实还行，只使用类型系统也并没有完全限制 Javascript 本身的灵活性，并且他帮助我不会犯一些低级错误，而且还能配合 Visual Studio Code 的提示，我觉得这个还是很不错的，最近忙起来的时候，甚至经常把两个输入框的 value 直接进行比较了，于是就想尝试一下 TypeScript。

官方做法

Vue 2.2 以上之后，官方给 Vue已经添加了很多类型声明，那么我们就来实践一下在单文件 Vue 中使用 TypeScript。

webpack rules 中添加 ts-loader 相关（这里使用 webpack 2）

{
  test: /\.ts$/,
  exclude: /node_modules|vue\/src/,
  loader: 'ts-loader',
  options: {
    appendTsSuffixTo: [/\.vue$/]
  }
}

表示对 .ts 文件编译时使用 ts-loader 进行读取，appendTsSuffixTo 是为了让 tsc 对 vue 文件能够当成一个 module 进行处理，以解决 moudle not found 的问题（tsc 本身不认识 vue 结尾的文件）

添加 .d.ts文件

declare module "*.vue" {
  import Vue from 'vue'
  export default Vue
}

也是为了让 vscode 在 ts 文件中识别 vue 结尾文件

项目根目录下添加 tsconfig.json

{
  "compilerOptions": {
    "allowSyntheticDefaultImports": true,
    "lib": [
      "dom",
      "es5",
      "es2015.promise"
    ],
    "module": "es2015",
    "moduleResolution": "node",
    "isolatedModules": false,
    "target": "es5"
  },
  "include": [
    "./src/**/*.ts"
  ]
}

allowSyntheticDefaultImports 是为了能够用 es6 形式的 import，其他就参照 Vue 和官网的弄了个最小化的 json。

万事俱备，让我们 `npm run dev` 跑起来！

在这里，我们假设使用 Vue 官方的 webpack boilerplate，对 Hello.vue 进行一下改造。

在模板的 msg 下新增一行

<h2>Say Hello Times: {{ count }}</h2>

并将 script 部分修改成

<script lang="ts">
  import Vue, { ComponentOptions } from 'vue'
  // Declare the component's type
  interface HelloInterface extends Vue {
    msg: string,
    count: number,
    sayHello(): number
  }
  
  export {
    HelloInterface as interface
  }
  export default {
    data() {
      return {
        msg: 'Welcome to Your Vue.js App',
        count: 0
      }
    },
    methods: {
      sayHello() {
        this.count++;
        return this.count;
      }
    }
    // We need to explicitly annotate the exported options object
    // with the Hello type
  } as ComponentOptions<HelloInterface>;
</script>

这段代码没有什么太大的问题

接着我们改造一下 App.vue

<img src="./assets/logo.png" @click="sayHello">

<script lang="ts">
  import Vue, { ComponentOptions } from 'vue';
  import { interface as helloInterface, default as Hello } from './components/Hello.vue';
  interface App extends Vue {
    $refs: {
      // 对 helloComponent 进行声明，可以使用 helloComponent 上的方法和属性
      helloComponent: helloInterface
    }
  }
  export default {
    methods: {
      sayHello() {
        this.$refs.helloComponent.count++;
        this.$refs.helloComponent.sayHello();
      }
    },
    components: {
      Hello
    }
  } as ComponentOptions<App>;
</script>

也就是说，像 refs 这种动态的在运行时才能确定的东西，如果需要在 coding 过程中静态化，则需要在 interface 中对其进行声明，写的 code 稍微有点多，不过可以接受。

注： App.vue 修改成 lang=ts 后，顶层的 main.js 需要换成 main.ts 并修改 webpack 入口点，否则发生 file not found 错误

vue-class-component

官方的另一种推荐做法是 vue-class-component，不过 demo 和 readme 有点小问题，可把我这个 TypeScript 新手给难到啦，提了 pr 希望快快通过。

让我们看看使用 vue-class-component 之后的 Hello.vue

<script lang="ts">
  import Vue from 'vue'
  import Component from 'vue-class-component'

  @Component
  export default class Hello extends Vue {
    msg: string = 'Welcome to Your Vue.js App'
    count: number = 0
    sayHello(): number {
      this.count++;
      return this.count;
    }
  }
</script>

再让我们看看 App.vue

<script lang="ts">
  import Vue from 'vue'
  import Component from 'vue-class-component'
  import Hello from './components/Hello.vue';
  
  @Component({
    components: {
      Hello
    }
  })
  export default class App extends Vue {
    $refs: {
      helloComponent: Hello
    }
    
    sayHello() {
      this.$refs.helloComponent.count++;
      this.$refs.helloComponent.sayHello();
    }
  }
</script>

非常 Cool，非常精炼，暂时没有想到可能会发生的没法解决的因为 vue 或者 vue 组件和 TypeScript 水土不服的编译错误，而且都有了类型和提示。

总结

尤大佬说在接下来的 Vue 2.5 还会加强一系列的 TypeScript 支持（链接），不知道是怎样的支持呢。另外，欢迎大家在评论区发表 Vue + TypeScript 的使用场景以及你遇到的错误。

Vue + TypeScript 早期体験

Tue, 10 Oct 2017 17:33:23 GMT

Vue.version < 2.5 && Vue.version >= 2.2　適用される

公式ドキュメントによるやり方

Vue 2.2 から、Vue にいろんな公式型宣言を提供しており、さっそく、単一ファイルコンポーネントに TypeScript を試してみましょう。

webpack rules に ts-loader 相関を添付しましょう

こっちは webpack2

module: {
  rules: [
+   {
+     test: /\.ts$/,
+     exclude: /node_modules|vue\/src/,
+     loader: 'ts-loader',
+     options: {
+       appendTsSuffixTo: [/\.vue$/]
+     }
+   },
    ...

.ts のファイルを ts-loader で読み込む appendTsSuffixToは vue を module として tsc でプロセスして、module not found の問題を解決する（tsc は .vue ファイルが知らない）

.d.ts ファイルを作成する

どんな名前もいい、どこでもいい、tsconfig.json の include PATH にいればいい、必ず .d.ts を名前の終わりします。

declare module "*.vue" {
  import Vue from 'vue'
  export default Vue
}

vscode の .ts ファイルに .vueファイルも知らせます。

tsconfig.json を作成する

{
  "compilerOptions": {
    "allowSyntheticDefaultImports": true,
    "lib": [
      "dom",
      "es5",
      "es2015.promise"
    ],
    "module": "es2015",
    "moduleResolution": "node",
    "isolatedModules": false,
    "target": "es5"
  },
  "include": [
    "./src/**/*.ts"
  ]
}

allowSyntheticDefaultImports は es6 の import を直接使えるの option

準備万端、`npm run dev` いきましょう！

こっちは vue-cli の webpack boilerplate を例として、Hello.vue を改造しましょう。

html template の msg の下に

  <h1>{{ msg }}</h1>
+ <h2>Say Hello Times: {{ count }}</h2>
  <h2>Essential Links</h2>

script の部分を

<script lang="ts">
  import Vue, { ComponentOptions } from 'vue'
  // Declare the component's type
  interface HelloInterface extends Vue {
    msg: string,
    count: number,
    sayHello(): number
  }
  
  export {
    HelloInterface as interface
  }
  export default {
    data() {
      return {
        msg: 'Welcome to Your Vue.js App',
        count: 0
      }
    },
    methods: {
      sayHello() {
        this.count++;
        return this.count;
      }
    }
    // We need to explicitly annotate the exported options object
    // with the Hello type
  } as ComponentOptions<HelloInterface>;
</script>

こうして改造します

親としての App.vue を改造してみて

  <div id="app">
-   <img src="./assets/logo.png">
+   <img src="./assets/logo.png" @click="sayHello">
-   <hello></hello>
+   <hello ref="helloComponent"></hello>
  </div>

<script lang="ts">
  import Vue, { ComponentOptions } from 'vue';
  import { interface as helloInterface, default as Hello } from './components/Hello.vue';
  interface App extends Vue {
    $refs: {
      // helloComponent を宣言する、helloComponent のメソッドとプロパティを使えようになるました
      helloComponent: helloInterface
    }
  }
  export default {
    methods: {
      sayHello() {
        this.$refs.helloComponent.count++;
        this.$refs.helloComponent.sayHello();
      }
    },
    components: {
      Hello
    }
  } as ComponentOptions<App>;
</script>

refsといった動的なもの、interface に宣言して、typescript にオートコンプリートを使えます。

App.vue の script を lang=ts 変更すると、main.js を main.ts に変更する必要があります、webpack の entry も忘れないでください，そうしないと file not found のエラーが発生する可能性がある。

コードはちょっと多いね、公式サイトによるの vue-class-component を使ってみますか？

vue-class-component

vue-class-componentの demo と readme はちょっと問題がある、TypeScript の新入りの私が困った、pr を提出した、速くマージされて欲しい。

vue-class-component を使っている Hello.vue の script 部分

  import Vue from 'vue';
  import Component from 'vue-class-component';
  　
  @Component
  export default class Hello extends Vue {
    msg: string = 'Welcome to Your Vue.js App'
    count: number = 0
    sayHello(): number {
      this.count++;
      return this.count;
    }
  };

で、App.vue

  import Vue from 'vue';
  import Component from 'vue-class-component';
  import Hello from './components/Hello.vue';
  　
  @Component({
    components: {
      Hello
    }
  })
  export default class App extends Vue {
    $refs: {
      helloComponent: Hello
    }
  　
    sayHello() {
      this.$refs.helloComponent.count++;
      this.$refs.helloComponent.sayHello();
    }
  };

随分清潔になりました、オートコンプリートもバッチリ！他の vue コンポーネントと TypeScript の不具合は一時的に考え出来ません。

終わりに

Vue 2.5から TypeScript のサポートはどんどん増えますと言います、どんなサポートですね〜

日本語まだ下手ですから、変なところいっぱいと思います、コメントエリアに指摘すれば幸いです。

最後まで閲覧いただきありがとうございました。

いくつのユーザー状態の記録方法

Thu, 28 Sep 2017 18:03:55 GMT

Cookie

昔のやり方は、Cookie に直接保存する。サーバーストレージはまだそんな安いの状況下で、たくさんのウェブサイトはユーザーの登録そういうインフォメーションを変化してサインして Cookie に保存する。

変化やサインは、md5+salt、または secret を使って双方向の暗号化するとかの方法。

ウェブサイトに二回アクセスとしたら、Cookieに指定のkeyのvalueを検証する、それはただしかどうか。

こうやっていいところは：サーバーストレージ占有なし、Cookie はユーザーの情報です

こうやって悪いところは：ユーザー情報盗むはやすい、特にhttpsなし、中間者攻撃されたら、悪い人にログインされたことはできる。また、別々に保存するのデータを改ざんされるはやすい。

Session

計算力とストレージの速い発展、問題は次々に現れた。保存希望のユーザー情報はますます多くなる、Cookie のサイズ制限は少ない。

原理的には、Session は Cookie です。

サイトにアクセスとき、サーバーから唯一の Session ID を配ってCookie に保存する。ログインのとき、この Session ID による、サーバーに Session Object を作る、このオブジェクトにuser idとか、状態というユーザーの情報を保存している。

Session ID は Session Object を作るのときに配れも可能です、Session IDの作る方法は時間によるに限らない、sidの唯一を保証すればいい。

Session Object のストレージ場所も選べる。Sessionはとても大事ですと思われなら、mysql に保存するは可能です、そうではない場合は、redis に、メモリにも可能です。

だから、Sessionはとてもフレキシブル。

Session は過去の技術ではない、今はたくさんのウェブサイトに使われている。その原因は、httpしか問題いません。Internet Explorer >= 10 の場合も CORS に Cookie の伝送が可能ですから、問題ない。

いいところ：クライエントサイド sid しか見えない

悪いところ：情報を取得する、一つ query 必要です。盗むも可能ですが、Session / Cookie の問題ではない、http の問題です、httpで何も見える。

いいと悪いは時代に応じるです、Cookie に保存するときは、サーバーの計算力は低い、memcacheやredisもない、Sessionの時間はかかる、今はこれは決して悪いところじゃない。

Session と Cookie はフロントエンドにとって何をする必要はない、サーバーは Set-Cookie の http header で sid と Cookie の更新を完成することはできる。

Token Based

上記２つの方法は、２つの異なるアイデアを表しています。一つは情報をクライエントサイドに保存する、一つはサーバーにする。

フロントエンドとバックエンドを分けるときは、上記の２つアイデアも Cookie なしに進化する。

一つは Session Token を取って、JSON、または他のhttp header に伝送する

一つは JWT（JSON Web Token）情報をクライエントサイドに保存するというアイデアを表す。Cookie とちょっと似ているけど，情報を base64 に変化して、secretでサインして、一緒に token になる。

クライエントサイドに保存するのいいところは：情報はクライエントに保存しているから、コードに直接処理はできる、ロードバランスとかの心配いらない。また、Session の期限切れば、データベースに delete の必要がある。

悪いところは：情報多くなるとき、Token は長くなる、http request は大きいになる、伝送の時間がかかる。

JWT の payload は base64 コーディングする、誰か標準に通じれば、内容を見られます。

Token Based 認証はフロントエンドに保存して、コーディングは必要です、一般はlocalStorageで。だから、Token Based 認証は XSS に攻撃される可能性はある、Cookie Based 認証は CSRF に攻撃される可能性はある。

結論

いくつかの単語をすべての場合に要約することはできません、Token と Cookie また情報をクライエントサイドに保存するとサーバーにするの場合を想像する、どんな方法を採用しようか、現業務を基にして、ちょっと長いのビジョンで選択を考える。

用户登录状态验证权限的时代变迁

Thu, 28 Sep 2017 17:57:15 GMT

Cookie

直接在Cookie中存信息可谓是上古时代的操作了，在服务器还没有那么便宜的情况下，好多网站选择将用户的登录信息存在cookie中，他们把用户名或者用户id转换并签名之后，直接存入Cookie，如果有其他需要的信息，也是如此操作

转换或签名可以是加盐md5，也可以是使用secret的双向加密

用户第二次访问网站的时候，代码中对这段信息进行验证，看看是否是正确的签名的

这样做的好处是：不会再占用服务器资源，直接就在cookie中读取数据，获得结果

坏处是：登录凭据容易被窃取，尤其是那个年代还没有流行https，如果被中间人了，或者以另一种方式拿到了cookie，那就会被窃取登录，另外，每个数据还可能是分开存储的，因此容易被篡改

当然那时的互联网也并没有那么发达，cookie也就存存用户名什么的用于显示

Session

后来网速变快了，web 应用高速发展，大家意识到了很多问题，cookie 大小不够啊，cookie 每个 key 都这么搞一下暴露太多了等等

从原理上来说，Session 就是 Cookie

客户端进入网站后，服务器分配一个 Session ID 给客户端种入 Cookie，用户登录时，在服务器查询 Session ID，在服务器写入 Session Object，这个对象里存了用户的登录数据，比如 id 啦，用户名啦，登录状态 / 角色等等

另外分配 Session ID 也可以是懒分配，也就是等到在服务器存 Session Object 的时候再分配也没有关系，Session ID 的分配可以是用 UserID 来进行加密分配，也可以用毫不相关的时间等信息进行加密分配，只需要保证这个 sid 唯一，不容易被伪造即可

Session 的存放也是可重可轻，如果觉得 Session 很重要，那么可以放入 mysql，如果觉得 Session 不怎么重要，甚至可以放入内存，重启丢失

Session 到至今还是非常非常多的网站在用，原因就是在于其实除了 https 以外的问题，并没有什么问题，IE >= 10 之后，Cookie 也可以跨域，那么 Session 就没有什么问题

好处是：在客户端除了 sid 以外，看不到任何信息，当然不太容易篡改

坏处是：取 Session 的时候，是会需要再 query 一次的也容易被窃取，当然这并不是 Session / Cookie 的锅，http 下，啥都是一清二楚的

另外，优缺点都是相对于时代来说的，存 Cookie 的时代服务器的性能不高，也没有 memcache 或者 redis 这种东西，存入 mysql 就需要再 query 一次，负载均衡当然不能同步内存中的 Session，Cookie 成为了首选，那么现在呢，这点算力恐怕算不了什么，那么 Session 的那个坏处，就应该被划掉，Session 理所当然成为了流行的会话管理方式

Session 和 Cookie 都不需要前端介入，服务端通过 Set-Cookie http 头就可以完成 sid 和 Cookie 的更新

Token Based

上边两种方法代表了两种存登录凭据的思想，一种是把凭据存客户端，一种是把凭据存服务端

那么随着前后端分离的运动，上边两种的登录凭据的思想也发展出了两种不使用 Cookie 的方法

把凭据存服务端的 Session，把他的Token，单拿出来，在JSON中传递，或者在 http 头里传递或者其他方式传递

JWT（JSON Web Token）代表了把凭据存客户端的思想，和当时的 Cookie 有点像，登录的时候把那些需要的信息 base64 编码作为一段，然后再对这些字段用 secret 进行签名，连起来这么一段 Token 去发给客户端作为凭据

凭据存在客户端的好处是：因为登录状态都是跟着客户端跑的，时效信息都存在客户端，Session 如果过期了，要对 Session 数据库进行垃圾清理，那么凭据存在客户端就不需要，而且因为都是跟着客户端跑的，在服务器扩大搞集群，搞异地多活，就不需要考虑读数据库这种事情，因为都是客户端请求为 based ，随便哪个服务器来 handle 请求都没有问题

凭据存客户端坏处是：当凭据内容越来越多，Token 也会越来越长，每一次请求都会携带这么大这么长的内容，显然不是非常合适

JWT 还有个问题就是中间那部分是 base64 编码的，如果熟悉标准的话，等于就是明文存储凭据了，虽然不能改，当然还是能看到

Token 类的鉴权需要前端参与并存储，存储一般会放在 localStorage等地方，因此其实是比较容易受到 XSS 的影响 Cookie 类的鉴权容易受到 CSRF 的影响

总结

其实只言片语还是没法概括到所有的情况，只能大体的对Token 或者 Cookie 以及凭据存服务端或者客户端的优缺点进行想象，究竟去使用哪一种鉴权方式，还是应该基于业务，对业务有非常深入的理解，以及稍带一些长远的思考

日本語ブログ始動

Sat, 26 Aug 2017 16:55:10 GMT

こんにちわ、はじめまして、こちらは xingo さんの日本語ブログ！

日本語まだ下手です、どうぞ、お気軽いに指導します、よろしくお願いします！

さて、このブログですが、まずはどのようなものかご説明したいと思います。

xingo さんの技術相関
xingo さんの作品
xingo さんの日常生活
xingo さんの旅行

このような感じで本番までお付き合いいただけたら幸いです

では、また次回

2017 你的名字东京圣地巡礼

Sat, 26 Aug 2017 13:02:06 GMT

BD 出了一个月，略忙再加上 VCB 也没有出 rip，前天 rip 刚出于是赶紧下载了来做整理啦

靠着仅有的印象和网上的一些经验攻略，把东京几乎所有的场景都拍到了吧（大概）

新宿站

新宿站前路

新宿站全景（可在天桥上拍）

西新宿新宿警察署夜晚

西新宿新宿警察署白天

这里非常丢人的拍错了角度，因为完全没看图😂

新宿站南口与中央东口之间的铁路桥下白天

新宿站南口与中央东口之间的铁路桥下夜晚

涉谷站东急电铁入口 TATSUYA

四谷站外

四谷站前广场

jr 信濃町站前天桥

桥上的这个路标牌实地并木有，但是却在六本木找到了一模一样的路牌，不是很清楚怎么回事

jr 信濃町站前天桥上

jr 信濃町站对面

全图是这样的：

刚才天桥的后边

这里角度非常刁钻不是很好拍到，只能这样拍一下，全图如下：

明治神宫前

jr 代々木站

赤坂見附駅至四谷站路上

赤坂見附駅地铁出口

赤坂見附駅至四谷站（靠近四谷）野球场旁边小路

涉谷站旁天桥

新宿中央东口前过天桥南口过天桥广场星巴克门口

四谷三丁目站四谷站中间的新宿通路往须贺神社方向

这里标注一下三个标志在哪 😂 间隔非常远

四谷四丁目路口

jr新宿站南口

jr 信濃町站对面

新宿通路去须贺神社的小路

须贺神社前

完结~

探索 Service Worker “生命周期”

Fri, 11 Aug 2017 15:05:42 GMT

最近讨论 PWA 的好多啊，PWA 中有个非常重要的角色是 Service Worker 。刚写这篇文章的时候粗心一看，把现在发的 Working Draft 的发布时间以为就是 Service Worker 的发布时间，被棕神挑刺啦。spec 仓库的第一个 commit 是 2013 年 2 月 7 日，W3C 发第一个 Service Worker 的 public working draft 是 2014 年 5 月 8 日，第一个实现 Service Worker 的是 Chrome 40 （2015 年 1 月 21 日）

以下将Service Worker简称为SW

SW的功能略有耳闻，在MDN上它被描述为，“对资源缓存和自定义的网络请求进行控制的一个好的统筹机制”，同时他还具有“访问推送通知和后台同步API”

听起来很神奇，事实上看起来也很神奇，Twitter上个月更新了样式，大家都看到了推特变成了圆头像圆角，然而推特还使用了新的 SW，在允许推特使用Notification的情况下，推特可以在你Chrome开启的时候而没有打开网页的时候给你推送你所关注的内容（传送门），有一种javascript在关闭网页后，甚至没有打开网页的情况下，就能在后台运行的感觉。

但事实上并非如此

编写一个最简单的 SW

从零创建 Service Worker，只需四步

第一步：我们需要一张 index.html

<html>
  <head>
    <title>My first Service Worker test</title>
  </head>
  <body>
    Hello, Service Worker!
  </body>
</html>

第二步：我们需要一个 sw.js，他就是我们的service worker

console.log('When you see this, we have successfully registered the SW!');

第三步：我们需要在刚才的网页上注册，我们可以在网页中的js引入注册，在这里我直接写在了index.html的script标签

<script>
  if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('/sw.js', { scope: '/' }).then(function(reg) {
      // registration worked
      console.log('Registration succeeded. Scope is ' + reg.scope);
    }).catch(function(error) {
      // registration failed
      console.log('Registration failed with ' + error);
    });
  }
</script>

最后一步：将上边的两个文件放在一个文件夹里，从这个文件夹起个服务器

打开浏览器，访问localhost，让我们看看控制台

至此，我们的第一个 SW 就成功完成了

SW 的 Debug

在chrome中，我们可以通过 chrome://serviceworker-internals/ 查看浏览器注册的所有SW

可以在 chrome://inspect/#service-workers 查看到当前正在运行的所有 SW

点击inspect，可以在Console中看到SW在控制台中输出的内容，在Source中，对SW进行断点调试

如果你还保留着刚才的那个localhost，你可以发现，在inspect service-worker页面中，我们刚才的sw.js还一直在运行着

Service Worker 的“生命周期”

SW 的生命周期与事件可以在MDN上找到，也不再重复贴出，SW的缓存与推送通知就是靠着他的生命周期所发出的这些event来驱动的。

我想说的是另一个生命周期，我刚才说到，如果我们第一次进入localhost，并一直保留在那个页面，在inspect service-worker还可以看到service worker还一直运行着

我们可以将 sw.js 改写成如下

setInterval(() => {
  console.log('test');
}, 5 * 1000);

在 chrome://serviceworker-internals/ 取消注册 SW ，并强制刷新 localhost（ mac下 ⌘+shift+R，windows 下 ctrl+shift+R ），我们会发现控制台中，每五秒就打印了一次 test，这也正是说明，SW在第一次进入的时候没有关闭页面的时候，一直在运行，我们也可以在刚才的 chrome://serviceworker-internals/ 看到这个 SW 正在运行。

然而当我们关闭localhost页面，稍等十几秒后，在两个调试页面上，sw.js都会消失/停止了运行

我们再直接打开localhost，打开控制台，发现只有Registration succeeded.，而没有了test，再看两个调试页面，发现sw.js依然没有运行

让我们关闭这个localhost，将 sw.js 改写如下

console.log('Yet Another sw.js');

保存后，打开localhost

我们刚才对 SW 完成了一次更新，发现他注册 handler 只会注册一次，接下来我们对 SW 的生命周期与运行周期进行探索，看看他在打开网页时，会不会触发生命周期。

然后我们再对 sw.js 进行重写

self.addEventListener('install', function (event) {
  console.log('install');
});

self.addEventListener('activate', function (event) {
  console.log('activate');
});

关闭localhost，等待sw停止运行或者deactivate它后再打开localhost，控制台显示出了install和activate

再次关闭 localhost ，等待 sw 停止运行再打开 localhost ，控制台上只有 registration succeeded

很明显，SW 的生命周期的事件也只会触发一次，只是相对于他第一次下载后。

更新SW的机制可以在MDN上的 #更新你的Service Worker 这章看到，但这仅仅几行文字，而且比较绕口，我认为这其实是SW自身的工作周期，或者说是运行机制

于是在W3C Working Draft找到了Service Worker的Lifetime定义

The lifetime of a service worker is tied to the execution lifetime of events and not references held by service worker clients to the ServiceWorker object.

A user agent may terminate service workers at any time it:

- Has no event to handle.
- Detects abnormal operation: such as infinite loops and tasks exceeding imposed time limits (if any) while handling the events.

于是我觉得SW的工作周期结合上边的表现可以由下边的图来表示

其实图里有一点不对的是，sw 的第一次运行并不一定是网页关闭才结束的，根据标准来的话，只要 sw 没有 event 需要 handle ，sw 的工作进程都可以结束，只是 Chrome 下是如此运行的。

另外需要一提的是因为工作线程结束了，因此在外边的变量不一定还保持着之前结束前的状态，所以不要写出如下的代码

let count = 0;
self.addEventListener('fetch', function (event) {
  count++;
  console.log(count);
});

可能为1，也可能是2

最后

SW 是一个事件驱动型Worker，本质上，它是个Worker，工作在 worker context，所以没有访问 DOM 的权限

如果他要和window进行一些操作的话，与web worker类似，需要使用postMessage这样的方法来传递信息，在window里才能进行DOM操作

SW 是个Event bus，他的几个运行周期的事件，是专门为缓存与推送量身打造的（install事件和push事件），因此他的扩展性也非常好，以后如果有更多需求只需添加事件即可（比如chrome实现了sync事件是为了弥补离线时从本地到服务器post的不好体验），它将我们对资源拉的需求（对服务器的请求资源，对服务器的轮询），隐形转换为了推（本地缓存资源代码控制缓存，统一服务器推送）

交叉编译原版某不可描述程序为梅林某停更插件续命

Mon, 07 Aug 2017 14:41:43 GMT

Forked from 原文 and 非自审查版

准备环境

ubuntu 16.04
原版梅林源码
ss-libev 源码

原理说明

解包梅林 SS 插件发现，基本都是脚本，核心都是调用 ss-redir ，因此猜测 ss-redir 为原版 SS ，只需要更新原版 SS ，并在前端进行相应修改，便能对其续命

ubuntu 16.04

不是很了解 linux，但是应该只要能够运行 arm-linux-gcc 的 linux 发行版都可以，但我在 ubuntu 16.04 下实验成功，因此这里写 ubuntu 16.04，当然 docker 是可以的（因为我就是在 macos 下用的 docker）

原版梅林源码

虽然是 koolshare 改版固件，但其还是合并了梅林的代码，因此可以使用梅林的交叉编译工具链

下载时，注意对应相对的梅林版本号，可以看一下固件发布时的说明

梅林的交叉编译工具链在梅林源码 release/src-rt-6.x.4708/toolchains/hndtools-arm-linux-2.6.36-uclibc-4.5.3，release 下应该是固件版本的不同，但几个固件版本下的 toolchains 均指向这个文件夹，应该是 toolchains 没有改变过

ss-libev 源码

不解释

炼丹编译

镜像准备与 arm-linux-gcc

ubuntu 首先需要安装一些编译工具，如果对系统有洁癖的，推荐使用docker，我使用了别人写好的 DockerFile 的镜像

Asuswrt Merlin 固件交叉编译环境

启动并挂载源码，运行 docker exec -it container-name zsh

进入容器后尝试运行 arm-linux-gcc

如果出现 arm-linux-gcc: no input files 说明正常，进行下一步

如果出现其他，请检查路径，权限，否则等下编译出来的可能是 ubuntu 的 ss （我之前编译时，解压后arm-linux-gcc没有运行权限，于是没法编译，给了权限就可以了）

编译 SS 依赖与 SS

编译 SS 还有一些依赖需要安装，以下过程参阅

交叉编译SS-libev

需要编译 mbedTLS、pcre、libsodium、libev、libudns

按照原博文的编译后，最后编译 SS 时死活没有检测到编译了libudns，怕是编译后文件夹没有添加到 PATH 中，当然刚才的博文里还提供了一键编译脚本，但那个一键编译脚本中判断参数的部分在ubuntu里报错，于是我就去了，直接写死环境 arm-linux 即可

fork了一下

编译过程大约需要持续 5-10 分钟

使用一键脚本编译的话，在 dists/ss-libev/bin 中拿到 ss-redir，将他scp到路由器上，执行 ss-redir -v

出现以上则为成功

替换原插件并自行打包

Fork原插件repo

base=shadowsocks

./ss/ssconfig.sh 中将地址更换成自己的repo可以使用自动更新

./version 第一行是版本号第二行是 tar.gz 的 hash值

./bin SS 的各种二进制执行文件，可以将刚才编译出来的东西都覆盖进来

./webs/Main_Ss_Content.asp 前端界面，加加密方式都在这里添加

2017 野良神圣地巡礼

Sun, 04 Jun 2017 13:28:41 GMT

上个月人生的第一次出国以及第一次赴日去了东京，巡了君名和野良神还有一些四月的圣地，回来后一直在忙（忙着玩塞尔达和p5），当然工作也是挺多的挺烦的，于是今天稍稍有那么点空闲时间整理一下

时间还算比较充裕，就把第一季和ARAGOTO那些印象比较深的巡了，另外野良神和其他几个动画搞了个圣地巡礼的app，大多数地点在那个上边也有标注，app的名字叫「舞台めぐり」

西新宿

这边正好在修路，没法搞到很好的角度

刚才那张的对面

新宿駅南改札口后边的通道

湯島天満宮

東京メトロ湯島駅

湯島天満宮入口

湯島天満宮入口近距离

上野公园科技馆门口

上野公园

至此，东京市中心结束

大泉学園駅

大泉学園駅ホーム

練馬梨の花公園附近的通路

練馬梨の花公園

石神井公園内的一家店小福家的店

因为这家店不让拍照，只能远远拍一张表示来过了

石神井公園去駅的散步小路

还有君名的，等七月bd发售了再截图整理吧

寿屋李小狼 1/7

Sun, 16 Apr 2017 14:57:56 GMT

bgm 人物介绍

MyFigureCollection.net

Amazon.co.jp

コトブキヤ ARTFX J カードキャプターさくら李小狼 1/7 スケール PVC 製塗装済み完成品フィギュア

壽屋

「見つけた。『クロウカード』の気配だ。」

壽屋『カードキャプターさくら』フィギュアシリーズ第二弾! 今でも絶大な人気を誇る名作『カードキャプターさくら』より、「李小狼」が ARTFX J シリーズで登場!

男性、女性共に幅広い支持を持つ人気キャラクター「李小狼」を立体化。 CLAMP のイラストを元に、戦闘用の装束を身にまとった姿を再現致しました。凛々しさの中に年相応のあどけなさが垣間見える表情や、装束を翻した大胆なポージングに加え、小狼の羅針盤をモチーフにしたベースが作品の世界観をより一層引き立てます。

コトブキヤ ARTFX J「カードキャプターさくら」シリーズ第二弾。圧倒的なクオリティを是非お手に取ってお確かめください。

售价： ¥11,000

总览

细节

最喜欢的是脖子下方的白色里边的衣服，也是做得非常的精细

总结

非常精致的手办，很棒

UC 厂百夜优一郎

Sun, 16 Apr 2017 00:03:42 GMT

bgm 人物介绍

MyFigureCollection.net

Amazon.co.jp

mensHdge technical statue No.21 終わりのセラフ百夜優一郎ノンスケール ATBC-PVC 製塗装済みフィギュア

ユニオンクリエイティブ

「その人間の醜さに怯えながら死ね吸血鬼」

『終わりのセラフ』より百夜優一郎が立体化! ・マントは着脱可能!

[セット内容] ・本体・台座

附赠一张与手办姿势一致的相卡

售价 ¥9,074

三角底座

总览

披风可脱

脱下披风

细节展示

小优的腿非常细长，还原的特别棒

剑的颜色很棒，细节还是比较到位的

脸的还原度还是比较高的，也不错，虽然头发在有些角度看上去有些奇怪，总体还是不错

身上，衣服上的细节均或多或少有所变形有一种崩坏的感觉，最明显的比如腰带，但每个细节还是有做，勉强过得去吧

腰带下方的衣服颜色有很奇怪的痕迹

披风的固定不牢固，容易松动，图上就是松动了的披风

总结

还是一个可以入的手办，只是这个性价比略低，史老师做工感觉要比小优好很多，只比小优贵1000

谈一谈 surface pro 4 和 macbook pro 2016

Thu, 13 Apr 2017 17:11:22 GMT

前年12月入手的surface pro 4，去年11月入手的mbp，都是第一时间下单的，所以其实很早就想做一个对比，或者说在拿到sp4之后就想写一个感受，只是一直没有时间去想这些事情

此文结论先写在前面：

web开发，请选择 macOS与macbook pro

上两张购买图

谈一谈sp4的感受

性能不错，总体比普通笔记本好一点

下面细讲

优点

外观

很潮
很好看
很薄
很轻便

性能

六代低压i7很快，个人感觉比我的三代i5快很多
屏幕颜色很棒
炉石可以在小屏幕上直接玩，非常少的时候会掉帧，其他60帧运行
ow试过，低画质1920*1080 30-40帧左右
windows hello 识别进系统很好用！

我觉得他并不是一台游戏机，所以我没有看中它的显卡，所以3 4我只是非常偶然的用过一次，就不再用了，还是不要指望显卡太多比较好

缺点

背后支架键盘盖

听说这是拿过专利的，但是当你把它当普通笔记本想在地铁上，公交车上，想在腿上写点什么，sp4就嘲笑你的大腿短，我是要保持一个如何的姿势才能看到屏幕

还有

我想在桌上用sp4画画，然后非常尴尬，sp4最大角度听说是150度左右，但是在桌上画画，你想要的角度正好是150-180度之间，于是你就怎么都觉得手很不爽，还不如wacom，后边带翅膀的键盘🙄

笔

延迟很大
在玻璃上写字不准

延迟很大，我用onenote都有感觉慢，用ps就更明显了，下笔经常停顿，用画图则没有这种感觉，当然也没有了笔压

不准，因为我从来没写过这么丑的字，要写好字花很长时间，没有真笔写得好，再加上延迟，科科

还有一些老生常谈的问题，大家都知道

散热
续航
系统
休眠

散热

不要说使用很激烈了，莫名其妙的转风扇，莫名其妙的又不转风扇，不是很懂，开个音乐开个ps就转了，热倒也就算了，就是太吵了

续航

最多4小时，别听微软xjb吹了

系统

win10小问题非常多，且不说开发环境的问题，开机键盘完全不能用，要等实足两分钟，有时莫名其妙卡住（冻住），得等一会又突然好了

高分屏支持又很差，很多软件外接显示器的字体大小和你单独在surface上看的大小又不一样，每次得设置，又或者是根本没法设置

没有键盘盖基本不能打字，什么屏幕键盘啊，难用的一笔

休眠

有问题非常大的问题，几次说修好了，几次触发了我内心的阴影，合盖风扇不停转最后电池用光了，正确的休眠方式，把键盘盖拿掉按电源键休眠，基本没有问题

总结

所以综上所述我觉得他比普通笔记本来说并没有提升什么太多，而且屏幕也不怎么大够用，微软画的饼还没有实现，so what，不如把这点钱拿去炒股（笑）

也千万别想着什么边走边画，这种场景，不存在的，你可能需要的，就只是一台笔记本

谈一谈mbp的感受

开发很棒

下面细讲

优点

外观

手感很好，包括键盘，触摸板是广受好评，老生常谈，非常棒新的几个特性touchbar 指纹解锁什么的，虽说touchbar用的不多，但是也还算中规中矩，不差

性能

其实也算是低压i5，但也没有慢到哪里去，总之开发很棒
屏幕很好

系统

我觉得mbp最好的就是macOS在搭建开发环境上的便利，brew，命令行什么的，在windows下你要在各种窗口里切换，怎么地，打开一个bash最快也要右键点git bash，都是模拟环境，macOS上就是自己设定了快捷键之后一按就可以敲命令了

安装环境也是非常的快，基本不会看到windows的那种莫名其妙的错误提示，出错了，看着提示就能知道发生了什么，一般也就是sudo 的事情

更可贵的是，我在macOS下成功make了，我在centos里从来就没有make成功过东西

缺点

很多好用的软件都要买
外接显示器是灾难，需要设置一番，会有一些不便利（我这里插拔显示器需要重新关闭打开一次显示器）
系统还是有一些小问题的，但无伤大雅，没有微软那么严重，碰到过几次五国，碰到过花屏，但都是茶余饭后的消遣罢了，真的，比较少看见

对比

没有对比就没有伤害

续航

sp4 4小时 mbp 5小时吧

重量

sp4更轻如果mbp有sp4的重量就好了，mbp两块铁皮实在是重（也没有那么重，就是对比起来那个轻的比较多）

接口

sp4 一个usb 一个dp 一个磁吸口 mbp 四个type-c

很多人喷mbp的接口都是type-c的，太激进

事实上mbp 除非单输出外接显示器，否则你是不需要鼠标的，然后现在基本也不用u盘传文件了，那么基本来说，这些口其实对你来说根本没有什么关系

于是我现在四个口都在干嘛呢

一个接显示器，usb-c to dp，一定记住买显示器千万不要买hdmi的，很坑，当然我既然已经用了surface过了，当然就不会再用hdmi显示器了

一个接外置网卡和3个usb的hub，有时会连手机充电，主要是网卡，内网传文件会比较快（家里有NAS），正常来说用5Ghz的无线就非常足够了

一个接电源

在这个接口问题上，每个人都有每个人的想法用途，我就罗列一下自己的需求

综合对比

最后一个综合对比就是网上大家经常说的生产力

一个是office，office在mac上也有，现在也是office 365，mac上也是更新很快，touchbar一出微软也跟进，设计上和win也是基本同一，要说不方便，可能刚上手会有一些问题，但是就一个码农的角度来说，我用的office的功能区别不大，稍微熟悉一下还是马上就能get到的

另一个是QQ问题，QQ虽然没有win上功能那么多，基本功能也都满足了，还没有win的那么臃肿，特别是包括5.4.1版本之前都没有撤回功能哦，个人觉得并不烂

总结

从我个人的需求来说，感觉mbp要比surface好用很多，我觉得系统上的便利比surface那些硬件上的便利要好很多很多很多，而且surface非常不稳定

最后上一张图表示一下自己的工作环境

探究/使用webpack的AMD

Sun, 22 Jan 2017 17:13:19 GMT

什么？webpack出2了？

刚用了小半年的webpack就又要重头学过了？

那么试试吧？先试试改造一下blog？

我擦？怎么用requirejs？

前情提要

也不算熟悉webpack吧，1的时候用vue-cli bootstrap了萌购的几个手机页面，虽说其实完全不用关心构建这一块，只需要改改路径就可以了，但闲下来的时候好奇心也是会驱动自己看看别人是怎么写的构建文件的，不过看别人写的构建文件，又稍微看了点其他网站的webpack的有关教程，自己倒也是没有想到AMD这件事情，也对webpack并不怎么熟悉，而且1的文档也实在是狗屎的可以，就停留在会用，会模仿着套路写

前两天2出了，看看这新的文档站，手边又正好不怎么忙，那么看看

官方风格不错，也有很好的introduction和concept的解释，重新学习了一下官方对loaders的定义，不过2刚出，文档站里也有很多问题，比如loaders现在叫rules但文档里还是loaders等这样的小问题

不过这些字眼看多了，小困难轻松克服，再看看migrate，貌似并没有什么大改动，想给公司项目试试，不过看vue-cli官方生成的构建文件里的loaders是动态生成的，于是先暂时放一放。那先试试自己的blog，改造一下，打开主题的main.js，马上反应过来一个问题，靠，我以前用AMD写的

import requirejs from 'requirejs';

前情提要结束，回到正题，webpack里怎么用上AMD？

直觉告诉我，import requirejs from 'requirejs';

好吧，在写下这行代码前，我去requirejs的官网看了文档看了，也没讲到构建工具，但就写法来说，都是一样的，那么试试

哦对了，忘记贴我的构建文件了，不过也没东西，就指定了入口和出口

然后 npm install webpack --save-dev && npm install requirejs --save

然后入口点app.js

import requirejs from 'requirejs';

console.log('passed', "I'm in app.js");

requirejs(['./async.js'], function (asyncModule) {
  asyncModule.init();
});

async.js

define([],function(){
  return {
    init(){
      console.log("I'm in async.js");
    }
  }
})

好的，无情报错，unexpected character，打开看了一下这个r.js，第一行显示是注释，但在webpack却报错了，看来是姿势不对

搜索一下

那么在webpack中怎么用上AMD呢，搜了webpack 1的文档

哦？原来直接就能写？试试，去掉import，直接require看看？async.js不变，app.js

console.log('passed', "I'm in app.js");

require(['./async.js'], function (asyncModule) {
  asyncModule.init();
});

此时出现

发现我们的async被打包成了0.bundle.js

让我们打开浏览器看看

看Network和源文件，的确是异步

require.ensure

在2的文档中，并没有找到这个require的异步用法，倒是找到了migrating from v1的require.ensure，通过这个找到了2的一个文档，疑似发现了webpack的AMD文档

webpack 2把这个api单独拿出来讲了一整页是有它的道理一个是，webpack2把这个现在这样的引用也看成引用一个chunk，只不过是异步引用另一个是，没有了以前1的require AMD用法，可能将来会弃用？

从文档上也得知了，用这样的api，可以对chunkname进行指定，那我们来试试，app.js改成

console.log('passed', "I'm in app.js");

require.ensure(['./async.js'], function (require) {
  var asyncModule = require('./async.js');
  console.log(asyncModule); //等下再说
  asyncModule.init();
},'async');

浏览器控制台还是正常输出了

但我们输出的文件还是0.bundle.js啊

眉头一紧，觉得事情有蹊跷

赶紧搜索一下2的文档，找到filename

Note this options does not affect output files for on-demand-loaded chunks. For these files the output.chunkFilename option is used. It also doesn't affect files created by loaders. For these files see loader options.

好的，去看chunkFileName

原来如此，给config加上这么一条chunkFilename: '[name].js'

现在再构建一次试试

AMD模块的写法

es6的exports写法

让我们改变一下AMD模块的写法，之前我们是用标准的AMD define，那么ES6的exports写法会怎么样呢？

app.js

console.log('passed', "I'm in app.js");

require.ensure(['./async.src.js'], function (require) {
  var asyncModule = require('./async.js');
  console.log(asyncModule);
  asyncModule.init();
},'async');

async.src.js （刚才不当心取名async覆盖掉了原来的async.js）

export default {
  init() {
    console.log("I'm in async.js");
  }
}

浏览器报错

这个问题webpack没有给我们答案，不过我在 stackoverflow 的解释中看到了答案

自动检测的写法

有很多插件是这种写法

(function (root, factory) {
    if (typeof define === 'function' && define.amd) {
        define(['jquery'], factory);
    } else {
        factory(root['jQuery']);
    }
}(this, function ($) {

    console.log($);
    console.log("I'm in async.js !");
    //$.fn.anything = funciton(){...}

}));

ok，webpack也能帮你amd使用amd，cmd使用cmd，不过cmd也不会走下面那条factory的路哦

总结

使用require.ensure进行AMD获取模块对于AMD模块，最好使用AMD模块标准编写，因为还能在define时写好前置模块，让webpack自动帮我们处理打包

~~2的文档写的仍然非常有水准~~ 黑科技满满

Why AMD？

有同学说用了webpack，就不需要用AMD了啊，确实，一个页面只有一个css，一个js，依赖由webpack处理了，script要炸也是一起炸，不存在一个模块加载了另一个模块没有加载的情况，也不存在AMD的应用场景了啊

确实，在处理模块之间的关系，webpack已经全部处理了，那么业务呢？

业务总有扭曲的时候，老大如果今天跟你说：“前端同学们，我们手机和电脑要做两套逻辑”，那么我们现在，除了让 nginx/后端语言根据userAgent返回两套网页，有了新的选择

2017 いやほい

Tue, 03 Jan 2017 19:55:45 GMT

时间匆匆流逝，告别2016年，回看2015年，这一年也算是小有成就感

技术

狂点技术点的一年

年初还在学习Android的我，抵不住朋友的誘う，决定学习一下JavaScript，把红书看完之后觉得找到了真爱语言，非常喜欢JavaScript的开放与灵活，于是放弃Android转前端

2月~3月决定对blog现有主题进行修改来上手对HTML/CSS/JS的学习

3月底~6月初帮助学校完成简单的学生管理与成绩抓取

6月底开始萌购实习

7月协助完成萌购任你购前台页面

8月上完成简单活动页面螺旋警戒线

8月下完成日系剁手网站价格综合对比工具微博获得9333转发，2446个赞，阅读量273.3万

9月完成单页面活动页面轻文轻小说

10月~12月独立完成萌购App内所有内嵌网页

12月上为登录页添加Canvas2D动画

从技术上，感觉自己是进步非常大，然而技术日新月异，长远的看，可能也只是从0到1的过程，并没有到100，所以还要接着加油！

娱乐上

5月帝都玩 Google Photos

6月陪肉排玩了一天

7月和监督一起去了独立游戏大会

12月和监督一起cp19 Google Photos

bangumi 2016

新的一年

顺利完成4月底的旅行

顺利毕业

至少考出N3，希望能考出N2

希望在技术上能有新的进步 rxJs，后端也好，可视化前端也好，游戏开发也好

改进多说

Tue, 27 Dec 2016 15:34:24 GMT

增加用户尾巴
头像/表情转换成https

多说现有问题

稳定版不能切换表情
dev版不能收起表情框
新浪头像/QQ头像/新浪表情国内已经支持https了，多说没有及时跟进

另外多说记录了ua，在用户返回的数据里也给到了发评论的ua，想利用这个ua，展现我们睾贵的操作系统/浏览器/硬件等

相比不能切换表情，不能收起表情框稍微好那么一点，于是我决定将多说替换成开发版，而且对标准版增加UA以及https的教程网上也有很多，我也进行了参考，我自修改的0.32版improve-duoshuo就是使用标准版的多说进行了显示UA，只是没有替换https，如果你需要对标准版进行动手术，欢迎你参考我的这份，也欢迎你参考本篇blog的Reference

以下内容使用多说dev版进行

首先格式化多说，使其稍微好看一点

添加https

用户头像https

参考多说插件支持站点 https，在第2634行替换a字符串

替换表情https

点击表情后，Network中出现

格式化后发现

证明前缀写死在js中，搜索一下http://，发现和新浪有关的只有第3333行，修改成https后，问题解决

增加ua

dev版多说格式化后找到ds-comment-header ds-user-name 附近，发现全部改成了react风格的绑定

尝试旧逻辑不变，直接插入{ userTail.showAdmin(author) }和 { userTail.showUA(comment) }

userTail是之前0.32的全局helper

发现逻辑正常，证明模板可以读取全局变量，但输出字符被escape了

那就只能老老实实的改成模板形式了

代码参见旧2869行/新2847行，没啥技术含量

Reference

多说插件支持站点 https

多说回复后显示浏览器及操作系统信息（Useragent）

吐槽

多说这几个礼拜天天炸，时不时500，看来是要跑路啊，赶紧趁跑路前上一波https装个逼（雾

也欢迎对我的improve-duoshuo提issue提pr

使用Travis Ci使hexo自动生成并部署

Fri, 23 Dec 2016 15:51:13 GMT

前两天偶然看见v2ex上有人说使用travis ci做hexo的持续集成，想起对哦，何必需要每次写完博客再进行手动的hexo clean && hexo g && hexo d呢

为什么选择travis ci

因为他和github配合的很好，如果是github的开源项目，travis ci 永久免费

言下之意，如果你是使用github pages来托管你的博客的话，那travis ci简直就是最好的搭档

注册travis ci

什么鬼，没有注册，travis-ci.org也只支持使用github登录

开启travis ci对项目的trigger

没什么难的，进右上角头像里的accounts，按照出现的提示打开repo的开关就可以了

撰写.travis.yml

官方的nodejs的specific doc

Getting Started

如果你想再加hook，那么自己看官方文档去，这里对我自己的travis.yml稍作解释

Hosted on GitHub

language: node_js
node_js:
  - '6'
before_install:
  - export TZ='Asia/Shanghai'
  - npm install hexo-cli -g
install:
  - npm install
script:
  - hexo clean && hexo g
after_script:
  - git config --global user.name "xingoxu"
  - git config --global user.email "xingoxu@gmail.com"
  - git clone https://${GH_REF} .deploy_git
  - cd .deploy_git
  - git checkout master
  - cd ../
  - sed -i'' "s~${GH_REF}~${GH_TOKEN}:x-oauth-basic@${GH_REF}~" _config.yml
  - hexo d > log.txt 2>&1
  - cat log.txt | sed "s~${GH_TOKEN}~TOKEN~g"
branches:
  only:
  - source
env:
  global:
  - GH_REF: github.com/xingoxu/xingoxu.github.io.git

前面的不用多说，需要关注的是部署的问题

解决git push的证书问题

普通的push肯定是需要ssh的key的，或者https的话需要输入用户名和密码

然鹅，这里是持续化环境中，也就是虚拟机环境中，那根本没法询问用户啊

所以我们要给我们的部署施加一些小魔法

那就是，github的开发者api。使用github的api，使用personal access token与push链接的拼接以达到不登陆的效果

进入Settings -> Personal access tokens

新建一个token，我给他命名为travis

然后勾上repo的相应权限

然后，要注意的是，这样的密钥是不能写在.travis.yml中的，那坏人看到了，肯定能拿去干坏坏的事情

于是，可以放在travis ci的repo的settings的环境变量中

可以在文件中以${变量名}来引用

文件中的env global，和在这里设置的效果相同

所以

sed -i'' "s~${GH_REF}~${GH_TOKEN}:x-oauth-basic@${GH_REF}~" _config.yml

就会变成

sed -i'' "s~github.com/xingoxu/xingoxu.github.io.git~这里是密钥:x-oauth-basic@github.com/xingoxu/xingoxu.github.io.git~"

以将config.yml中的deploy的地址改成这样的一个拼接地址，就不需要密钥啦

解决master commit树被清空

如果仅解决push问题，那么你会发现，你部署分支的commit树被清空了

其实也不是什么很大的问题，但感觉看起来很丑，每次更新都像是一个新站点，没有历史更新记录，虽然这样以后你可以用source的commit来记录和回溯，但，总觉得怪怪的

使用下面的git命令来解决问题

git clone https://${GH_REF} .deploy_git
cd .deploy_git
git checkout master
cd ../

其实是很简单的git操作，就是需要注意一下

最后注意下主题文件夹如果是git文件夹的问题，不过这个应该不算是持续集成的问题

解决hexo d显示出私钥的问题

travis ci的build log是可以被大家看到的，但是，在添加变量那边关掉后就不会显示出来了，然而，这也仅限于使用${}来引用他的地方，git push时，会把此地址再显示一遍，这样你的私人密钥又会被显示了

于是乎我把hexo d的命令改成了这两行

hexo d > log.txt 2>&1
cat log.txt | sed "s~${GH_TOKEN}~TOKEN~g"

将hexo d的输出，包括标准与非标准，全部输入到log.txt，再cat出来的时候，使用sed对里边含有GH_TOKEN统统替换成TOKEN字符串

我对linux命令不怎么样熟悉，只能写成这样，如果您有更好的，不输出到log.txt的方法，可以在评论里指点一下

当然这样也有“缺点”，其实这个缺点在这里不成立，缺点就是把错误吞了，但不成立的原因是，after script的错误不错误不会影响到ci的过程

好处

写完文章后不再需要手动hexo clean && hexo g && hexo d了

坏处

也算不上什么坏处吧，非script部分出错了不会有提示，当然放在script里也没啥关系

还有一个就是毕竟是云端操作，时间会比性能强劲的本地电脑长

References

Travis CI 自动部署 Hexo 博客到 Github

新MacBook Pro连接U2715H并使用SwitchResX开启2K HiDPI

Sun, 18 Dec 2016 21:57:37 GMT

非Apple显示器字体模糊的终极方案

OSX的渲染和输出是分成两部分的，因此，我们可以利用这个机制在普通2K显示器上开启2K HiDPI

前言

等了一年半，很早就想入macbook的坑了，然而呢厨师貌似忘记了mbp这条产品线了，当然了，英特尔也是有一部分责任的，因此一年前的这个时候，我买了微软的surface pro 4。

结果这玩意非常不好使啊，开发者这边各种吃屎啊，各种没有快捷键啊，起个bash非常烦啊（最快也要右键），终于一个月前入手了macbook，但入手之后的那段时间，非常非常忙，各种事情吧，所以直到最近才有时间去配置各种开发环境。

当然我也不是果粉，os x这个破系统也是💊，各种问题，也有很吃屎的地方（有空整理），所以，surface pro 4还不能扔掉233

初次连接显示器

连上u2715h之后，我以为会展现一个比windows更好看更漂亮的，结果没想到，连上之后的字是这样的：

好好的東京のイケメン男子就被这个长满粉刺的字体给毁了，尤其是这个g，非常难看，感觉糊在一起了，整个人都不好了，怎么会这样

google一下？

80%教你开启LCD字体平滑，但开启之后，并没有任何卵用

20%教你使用一个ruby脚本，将Television变成显示器，然而，还是没有任何卵用

上面那张图就是干完那两件事情之后的截图，还是那样，粉刺字体，像狗啃过

试试hidpi？

在surface上装过虚拟机的黑果，当时用过一个软件叫RDM，为高分屏而准备的（也就是变成Retina的渲染效果），打开发现，有HiDPI的选项，选择1280x800，开启了hidpi，字体平滑了，结果因为显示器是16:9，选择的是16:10，旁边有两条黑边，想选择1280x720，结果点了无反应，唉，无奈回到原来的分辨率

所以通过这个事情知道了，并不是显示器的问题，只是苹果在1:1的显示下已经放弃了治疗（同时在思考macbook air朋友的心理阴影）

探索新可能

既然知道了hidpi是字体平滑的关键所在，那我就试试往这个方向搜索看看，由这贴和这贴和这贴得知，osx的渲染和输出是两个步骤，得知了一款SwitchResX的软件，可以修改自定义分辨率，那就尝试一下

按照此贴得票最高做法，安装SwitchResX，关闭SIP，重启，添加Custom Resolution，保存，重启

结果tm是 "Not active - invalid?" ，握日折腾了一晚上，还是不行吗？心灰意冷之时，拉到下方看到 Sierra 做法，只是比上方多新建一个账户，感觉很奇怪，新建一个账户又能改变什么呢，抱着并不怎么会成功的心态尝试了一下，新建了账户，删除了原有的分辨率，填入了1080px2的分辨率 3840x2160，重启，进入新建的这个账户，尝试一下，居然成功了！

于是更大胆的思考了一下，既然是渲染与输出两部分，那也就是说，我可以使用5k分辨率HiDPI到2k，进行输出咯？于是我就尝试添加了一个5120x2880，重启，点击切换，哇！成了！字体变得顺滑了！

后遗症

折腾了这么多的方法后，这些方法给我留下了后遗症，我并不能确定是SwitchResX这个软件留下的，还是因为这些个方法一起作用，导致了下面的后遗症

合盖的时候外接显示器必须不能是hidpi

正常外接显示器的情况下，合盖之后，外接显示器黑屏，再亮屏

如果合盖之前外接显示器是hidpi，合盖之后，外接显示器一定黑屏毫无显示，此时其实有信号，有鼠标，但就是黑屏，打开盖子又正常了。尝试之后发现是合盖的时候外接显示器不能为hidpi，这并不意味着你开盖的时候外接显示器不能是hidpi，也并不意味着你合盖之后外接显示器不能变成hidpi，只是如果你要合盖，那外接显示器请不要是hidpi

开盖莫名其妙注销了

真的是莫名其妙至极，插电插外显示器的情况下，开盖后要求输入密码，结果输入之后原有程序统统重新打开，黑人问号！

我尝试过把系统设置里取消勾掉再重新勾上，也尝试过把SwitchResX中的Sleep monitors after disabling给取消勾掉，更尝试过删除switchresx，并没有任何效果，所以这个后遗症需要十分注意！

当然我自己也找到了一个变通的方法，那就是，拔掉线，再开盖，就不会注销了，虽然麻烦了点，但我希望把我电脑搞出这个设定的人去吃屎

小问题

这个问题应该不是由软件引起的，没错，这个问题就是卡

思考一下，你的显示器是2k的，显示效果完全都由显卡渲染，mac输出5k分辨率，再缩到2k，虽然是新款的macbook pro，系统的动画也不卡，但用chrome的时候，就会很明显的发现一些css3的效果非常明显的掉帧，大概降到了20帧/s吧，safari好一点，但也就比chrome好大概10帧左右

这个问题说大不大，说小不小，不大的原因是，chrome这种调显卡渲染的程序不要开太多，对于我这样拿mbp写代码的人，基本没有什么影响，也就是开一个chrome，开一个编辑器，编辑器基本无视，也就是chrome，chrome也就是看看文档，和显示的效果而已

不小的原因是，我今天中午下了个720p的新番全屏来看，结果看到一半，开始掉帧卡了，一摸macbook，贼热（我的macbook放在床上，因为天气很冷，所以也不怎么在意温度，不看视频的时候摸了下只是温的），马上放到了桌子上，让他散热，很快macbook的温度就降下来了（也让我看到了这么牛逼的散热，这surface简直是落后几个世纪），愉快的继续看视频

所以结论是

保持散热
别开太多浏览器

当然如果你很在乎性能，不在乎这点渲染效果，那还是还原成2k普通分辨率吧，我之前的switchresx应该也不是完全卸载，完全卸载官方的做法是在顶部菜单里uninstall，不过官方说会删除所有switchresx做过的修改，那估计自定义的分辨率也会被删除

Android 非常奇怪的字体偏移

上图（左iphone 6/ios 10.0，右Nexus 6p/Android 7.0/Chrome 53.0）

仔细对比

（上边标题没有划出来的地方貌似是 ios -webkit-box 的问题）

几乎所有用 px 单位设置过 line-height 的地方， android 都会不由自主的字会向上偏移大概 2px 左右，然而看看隔壁苹果，我去可真是正常的不能再正常了，全部按照我想要的来，真漂亮。

生气，我大谷歌桌面端的浏览器这么fashion，手机吃瘪了？

然而偶尔调试一下，发现设置成line-height: normal;便全部都正常了

上图（左右均 Android ，使用 Chrome inspect 调试）

完全没有道理啊，可以看到蓝色部分，字根本没有按照极限走，反而全部都贴顶，甚至还有超出蓝色部分的

想不明白的我用同事的Nexus 6测试，结果发现，握日，他的手机居然是正常的

仔细一看，发现是渲染字体的问题

我的Nexus 6p使用的是日文语言，渲染的时候用的是Noto Sans CJK JP Regular

而他的是中文，渲染就用普通Noto Sans

想了想，日文字体中的很多中文字体是不存在的，发现了不存在的中文字体可能去借用了其他字体库，日文的中文字体和普通的中文字体混在了一起，系统没有处理好出了问题，一个猜想，不一定对

当我把iphone 6改成日文再测试，发现，还是很棒的渲染效果（辣鸡Google

IOS -webkit-box 奇怪的字体偏移

用-webkit-box在做一个省略的两行标题的时候，碰到的一个非常奇怪的问题

上图（iphone 6/ios 10.0）

同样的一个组件，css应该完全一样，没有继承，也试过了line-height重置成normal，然而并没有什么卵用

试试去除-webkit-box，发现成了，猜测是-webkit-box在safari的某种条件下的特殊bug，Android正常

反正这块地方高度定死，不如直接脱离文档流，float: left，解决了

虽然解决了，然而并不知道原因

不过box也已经废弃了，flex已经替代box（标准不一样）。后来搜了一下，做多行省略号倒是有很多tricks，当时也是纠结于这一个事情，实在是太傻了233，还是不要闷声写代码啊，多谷歌一下，说不定有其他套路233

linear-gradient 小笔记

很久以前便知道了他的大名，然而很久都没有使用过它，因为他远看厉害，去看他的标准，却总是被搞得一头雾水这两天做一个timeline的效果，以前不怎么用linear-gradient，一般用:before,:after进行拼接，然而这次觉得，巨麻烦，用上了linear-gradient 第一次用，做类似于--o- 这样的效果，稍微瞄了几眼标准，随手写

background: linear-gradient(to right,black 70%,white 30%);

看了效果，不错

结果今天过去做- o 这样的效果，写下了

background: linear-gradient(to right,black 30%,white 70%);

结果变成了黑白渐变

只好乖乖去仔细看文档

 linear-gradient( 
  [ <angle> | to <side-or-corner> ,]? <color-stop> [, <color-stop>]+ )
  \---------------------------------/ \----------------------------/
    Definition of the gradient line        List of color stops  

where <side-or-corner> = [left | right] || [top | bottom]
  and <color-stop>     = <color> [ <percentage> | <length> ]?

注意这个color-stop

<color-stop>

This value is comprised of a value, followed by an optional stop position (either a percentage or a along the gradient's axis). Rendering of color stops in CSS gradients follows the same rules as color stops in SVG gradients.

followed by an optional stop position ← 原来是停止位置。。。

所以应该这么写

background: linear-gradient(to right,black 1%,white 1%) no-repeat;

当然啦，要注意多个颜色（>3）的情况下，两个颜色之间的距离如果大于0就是产生渐变（废话，这是人家本来的用处啊233）

所以如果要做无渐变的多个颜色的混合，应该这么写

background: linear-gradient(to right,black 1%,white 1%,white 3%,#0c0119 3%) no-repeat;
                                     \------/ \------/ \------/ \------/
                                     颜色0结束 颜色1开始 颜色1结束 颜色2开始

晒游戏晒游戏233

最近在玩怪物猎人物语！超喜欢リュート，田村睦心这季配了好多男主，都超可爱！隔壁bs的约克也是！

感觉这个游戏就是卡普空简化战斗的怪物猎人啊，果然从小培养信仰吗（然而我并不吃这套哼

还差一些材料，现在在刷塔，刷完塔做出装备后就马上能全委托通关啦【并不打算再刷其他东西了】

晒个现在的银火龙套

快说帅233

近况

Sun, 18 Sep 2016 16:53:27 GMT

即使是找到了实习，然而还是没能闲下来啊_(:з」∠)_

浏览器的dom操作合并

刚学js的时候，明白js单线程时间线的模型，知道dom操作是缓慢的，因此明白要做动画最好应该在css中书写，修改dom只修改他的class，在不同的状态间切换，刚开始做一些动画成功了，然而做一个input[type=text]的错误闪烁框，写了animation，想在两个状态间交换，然而点了却没有反应，无论是用jQ写，还是用原生dom写，在控制台中根本没有变换过，当时很是疑问，最后我~~异想天开~~，试了一下setTimeout，把两个状态间的一个放入其中，结果就顺利的展现出想要的效果了。　　当时没有仔细想过，后来当看到优化dom操作，减少重流重绘博文的时候，猛然想起，浏览器对dom树的操作都是有优化的，同一个时间线中操作dom的操作会被合并成一个，到你下一次读取的时候才会产生变化

var domElem; //假设这是dom节点
console.log(domElem.className);
//<- 'c'
domElem.className = 'a';
domElem.className = 'b';
domElem.className = 'a';

/*
实际上浏览器只干了一件事情
domElem.className = 'a';
*/

console.log(domElem.className);
//<- 'a'
domElem.className = 'b';
console.log(domElem.className);
//<-'b'
domElem.className = 'c';
console.log(domElem.className);
//<-'c'

React的学习

~~工作量不够~~趁着空闲的时间，学习了React【，感受是React其实是单向版的Vue，但React最重要的是它带给我们的Components的概念，React其他的东西非常小，不依赖组件，什么都没有，可以说是Virtual Dom版的Mustache，正因为其他都很小，他的Components就变成了他想传达给我们的理念~~（大概是这样）~~。看了getting started，手痒痒，写了一个一直很想做的一个东西，感觉用React来写这个真是太合适了

日系剁手网站价格综合对比工具

其实我最想对比的是亚马逊直邮和代购之间的价格差，但是亚马逊这个计费规则实在是太奇葩了，而且，真结算的时候貌似并不是他的那个计费规则，所以只好暂时搁置

因为之前有MVVM框架的概念，在学习Vue和React就显得简单了很多，作为在实际使用的人来说，三种框架（Angularjs, React, Vue）我感觉写的最顺手的，最符合顺下来的思路的，还是Vue

利用Performance追踪运营商广告

这几天，智障的上海电信又给我插入了丰富的广告内容，以前插的是什么jd啦，taobao啦，tmall啦，一号店啦，现在他们都上https了，丧心病狂的电信就开始插cnbeta，csdn，s1，卧槽，excuse me，你这样挑衅技术真的好吗？　好吧，你赢了，我承认当我看到和感受到被插了，我打开chrome面板只能看到当前的html的结构，network部分是空空的，只能从html结构里查插入的广告服务器地址。然而前几天在@EtherDream 微博上看到的这条语句，就可以快速的筛出非本域的加载的资源了。

performance.getEntries().forEach(v=> console.log(v.name));

然而我们狗日的上海电信是tcp劫持给你插包，把正常网页插在iframe中返回，真几把酷炫，希望电信原地爆炸，全家上天，并求大佬给点流量到他们的广告服务器上【。

近期游戏与番

8月买了胧村正，卧槽，这游戏真好玩！三个礼拜本篇白金！现在正在努力DLC全奖杯中~

番的话，最近看了《异邦人无皇刃谭》，超好看，推荐！

近况

Thu, 16 Jun 2016 20:47:18 GMT

突然发现今天是个轴对称的日期233是个写博客的好日子（？），离上一次写博客有两个月，然而这两个月中真是经历了许多许多，不过接下来感觉可以稍微放轻松一点了

还是按时间顺序留一下近况吧：

肉排的上海之行

（听说）肉排来上海看演唱会，也很想不上课，于是主动请缨，开了张事假单陪他一起去疯了一天，爽死了。早上在家一起玩了一会看了集magi ~~（然后入了坑）~~ （虽然是为了阿里巴巴入了坑，结果却喜欢上了白龙233），中午一起去吃了面之后下午唱了一下午的歌呢，超高兴的是纯K居然有野良神的ed，而且画面有好多雪音呢 ~~（痴汉脸）~~ 　　和肉排出去玩的照片可以在 Google Photos 上看见 ~~（其实大多都是雪音）~~

软考

得知有软考这个东西的时候，是上个学期的快期末，当时还以为这考试有多了不得，也是在微博上看了许多认识了原来这个国家并不认识的一面吧，而且一看那个清一色的题集，教程什么的，都是一个出版社出的，还有再看里面的内容的话，跟这个时代的许多也是格格不入，大概就知道是怎么回事了。　　不过里面考的技术的东西是非常简单基础的，也就不那么在意。把一整本书刷了之后也没有留下什么遗憾，什么买了书不做啊浪费钱这样的遗憾。不如说还是略微有点收获的，认识了函数指针呢233感觉是肯定能过，希望不要给自己乱插什么flag（

百度面试

3月中旬投的前端简历，3月底考完的在线笔试，考完笔试我以为基本也是没有可能了，因为简答题也没编出很多，选择题也不一定完全对（有PHP），最后算法题三道总共300%也只做出120%貌似，因此我觉得是木有可能了。结果5月中旬的时候打了个电话来直接来面试我了，完全没有准备，就这么战战兢兢的在阳台上说了和面试官聊了一个多小时，自己明白自己说的有很多还是有那么点问题的，聊的也是最近基本都没怎么用的css（一直在写angularjs业务逻辑），不过还是过了。　　第二个礼拜又打了个电话过来面试，面完之后让我去一次张江百度面试一次，我投的是前端，上来问我你还会其他后端语言吗，我笑着说只会nodejs（心中黑人问号233），然后问了比较多的nodejs和express的使用吧，最近是一直在用，感觉自己回答的还挺好的，然而问到方法里填的参数，有些方法实在是记不住，因为我二次封装了他们，似乎是这些影响了一些吧，最后面试官问我有什么要问的，我问我怎么样，他说还有一些细节没有掌握好，我又问你觉得我能过吗，他笑着说　不好说，会尽快通知你的。　　这尽快一等就是两个礼拜多，看到网页上状态是“筛选未通过”，于是我就去寻找其他家了。结果到了考试周，我都快入职其他家了，百度电话打了过来，问我有没有找到暑期实习，我说找到了，他问我入职了吗，我说还没有，他说　如果我给你offer，你能来吗，我惊讶了挺久的，脑子一片空白，回答了一句，能让我再想想不（智障的我），他说好吧我了解了，然后就挂了。　　唉其实挂了电话后心里就有了谱，早就答应了人家，我觉得我也不太敢爽约别人，不过我当时说让我再想想实在是太智障了233。虽然我知道如果去百度肯定也是个备胎。　　上张图，表示并木有撒谎（？：　　

帝都再临

3月的时候知道自己5月份又能去北京玩，别提有多高兴了，还是公费不用自己出钱，爽死了。虽然本来过去是为了竞赛，然而我本来就没想在算法和数据结构上要有多大的造诣，能过学校的考试拿个优就好，能稍微拿个一般的奖就好，因为并不想往ACM方向发展嘛，根本就没认真在这上面花过时间，所以只要被我逮到空，就是各种约啊！哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈好开心啊那几天！　　27号下午到的北京，晚上就跟肉排和监督聚在一起啦！一起吃了饭！　　28号下午考试，上午稍微练了手做了道算法题，晚上和微博另一个好友面了基。　　29号上午去北大溜达了一下，拿了个纪念品，然后马上就赶往监督家闹腾了哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈！！！监督家真好玩！！！！！！！！好软的床！好多抱的！好多手办！好多漫画！好多海报！啊啊啊啊啊啊啊！うーらーやーまーしーいー！！！！！不我们还是先吃了中饭！然后在监督家各种玩啊！最后又一起吃了晚饭！すっごく楽しい！　　30号睡了个懒觉，下午就回家啦　　　　唉每次和监督面基，总能聊好多好多，总觉得不管聊什么，监督总是很懂，真的就是很懂，很厉害很厉害，厉害的深不可测，崇拜啊~ 　　第二次去北京的照片可以在 Google Photos 上可以看见。

学生事务中心网上平台

经过一个月搭建框架，一个月填充功能，一个月重读重写，终于基本能用啦，我还会加功能的，一是要完成到毕业，二是要做到毕设的程度，我会加油的！　　在自己服务器上的就会关掉啦，如果有公共内容的话，我会把它的文档填充完整的！

萌购实习

在等待百度面试的时候，投了简历给萌购，当晚就收到了笔试的题目，迅速完成后第二天便收到了面试的通知，考虑过后，还是决定去萌购。　　感谢监督君和肉排桑在这半年来帮我出谋划策制定学习路线，真的非常感谢！

大四课程的免听

总绩点达到3.0，通过英语四级六级，且有单位实习的话，可以免听大四的课程，唉去找了一圈老师，扭扭捏捏不太肯告诉我，特别有个丑老师，又不好说话，一定要我按程序走，问到程序，他又说不清楚，跑到教务去，发现有这条，就心定了，唉为了忙活个短学期的免听和迟上课以及下学期的免听，真是操碎了心啊。

接下来的计划

近来的话会学习Vue.js，学习git的内容，实习的话我一定要在实习中学习到更多的经验！因此只是暂时的歇息，要为接下来的成为社会人做好扎实的过渡咯！　　长期的话肯定是赚钱买买买咯，最近一堆很想买的东西，啊好心痒痒呢！　　还有的话有空会把博客再调整一下，感觉不管是js部分还是css部分都写的不怎么好。。。

近期学习小结

Tue, 19 Apr 2016 00:48:42 GMT

又是好久没有写博客啦，最近一段时间学习了Angularjs，Bootstrap，Promise，nodejs，express，其实本来就想学这些，正巧学校老师拜托我帮忙搞个迷你的项目来帮助他们管理一些事务，技术又不限，又考虑到这些事务其实是很简单的最基础的增删改查，就搭着这个顺风车学习了这些，还能实践

nodejs

nodejs的学习我是跟着《了不起的Node.js》这本书来入门的，其中书后面的connect，express等部分可能有点过时了（api之类的），但是其实这些框架学习了前面的知识后，稍微看一下这本书讲的理念，完全可以去看文档便能灵活掌握使用方法了，就nodejs这一块我感觉坑其实不多不深。另外我觉得这本书不错~~（我不是书商啊大家不要随便轻信我的话）~~，是因为他让我对现在web后端的一些新的概念，新的理念，一些实际应用中的是如何实现有了一点概念，比如session（之前我还读season233），mongodb这些的，总算是感觉自己离这些看起来很高大上的东西其实只有几行代码的距离。在nodejs中，如果需要处理一些复杂的逻辑，回调函数用的多的话，那么Promise就有了用武之地，包括维护代码整洁，代码分层（？）这个样子是非常有帮助的，而且nodejs稳步实现ES6嘛所以Promise是原生对象（奇怪WebStorm为什么没有提示）。

Promise

JavaScript Promise迷你书

AngularJS

整个Angularjs的学习过程我觉得是非常陡峭的，学的时候我并没有买书看，我先去看的视频，视频其实没有多少，然而反复看了三个礼拜（老忘），上手写了几段，而且视频看到最后说是声明式ui，恍然大悟（？），才算是感觉好像入门了。。。。~~（唉我说google的文档啊你能不能好好写啊，找着看真累）~~

双向绑定的'$scope'

用Angularjs来实现的前端的web应用（？），在其ngApp下的作用域的每一个DOM节点上都会有$scope，$scope是双向绑定的灵魂所在。这个$scope是以原型链的方式来继承上一级节点的$scope的，因此在实现逻辑复用的时候，是不应该将函数啊什么的全部都往scope上来附，感觉就相当于全局变量污染（？），可读性和扩展性会比较差。

controller与directive

刚学习Angularjs的时候我对controller和directive很懊恼，玛德，怎么前面这个东西是个controller，后面这个东西怎么也有controller，后面这个东西还能依赖啊，那么多config项，什么compile啊什么link啊，然后当写了一点，体验了一些过后，controller这个东西，就是mvc中的controller，你可以在controller范围内的节点上声明ngClick调用controller，那就是mvc的结构咯，v->c,c->m,m->v，而directive这个东西其实是angularjs最后偏向的mvw的what，因为他什么都可以当，我现在比较喜欢拿directive当presenter，当我一直在考虑如何将代码的逻辑理顺，把代码结构分清，而且各司其职，我发现原来我更倾向于mvp这个模式。

按需加载 AngularJS 的 Controller
http://www.cnblogs.com/zhrj000/p/3383898.html
http://beginor.github.io/2014/12/20/angularjs-controller-load-on-demand.html

angularjs controller之间如何通信
https://segmentfault.com/a/1190000000639592

angularjs手动触发dirty check
https://segmentfault.com/q/1010000003796580

angularjs的一些坑（？）

在angularjs 中 jquery on是bind？我似乎在link中用jquery绑定的on并没有live的效果，最后还是用了directive来绑定link，感觉是不是小题大做了？

还发现了 input[type=text] 设置display:block的时候，发现其并没有像个div占满一整行，反而像inline-block，觉得比较奇怪。。。

近期做的nodejs+express+AngularJS+BootStrap+Promise的实现

一个简单的实现，用户的增删改查，用户权限对模块的自由控制 https://dev点xingoxu.cn 用户名与密码都是12345678901，增加的用户学号是11位的，错误没有做太多的处理只是在主界面上禁用了所有交互并显示错误（没有花特别特别多的时间在这个上面）

不要玩坏了噻，总感觉自己做出来的东西特别容易塌。。。。。

前端： https://github.com/xingoxu/dashboard-with-angularjs

后端： https://github.com/xingoxu/crud-with-nodejs-mysql

改进点有很多了吧：

password

因为没有实际对它的处理经验，我感觉有两种处理方式，1是上https，随便怎么传（x），2是把密码用客户端一个会变的东西来进行加密，然后把这个会变的东西固定处理后发送到服务器，再进行解密，感觉2似乎还是有点不可靠？

合并http请求

现在的add,delete,update操作完成后还需要再refresh一次，其实可以把他们都合并到一个http请求里

异常处理

界面可以完善的更好

后端还有很多逻辑可以复用

最后

angularjs到此放一放，包括provider，包括实现原理等，可能需要等很以后有需要才能继续拾起来啦，接下来会细看一下html5+css3，js忍者秘籍和ES6

感谢肉排桑和监督桑在这一年来学习上的督促与教导，感谢他们我才能系统学习了这么多知识！真是非常感谢！

另外一些其他的存档：

gitlab vhost配置 502 centos7配置邮件服务器 z-index不生效

gulp.js初体验 - 自动编译/刷新/Release

Fri, 25 Mar 2016 20:34:33 GMT

Intro:

gulp能做什么
利用gulp编译stylus，本地预览，自动刷新，自动提升版本并Release
心得

gulp能做什么

半个月前朋友提醒我说可以开始学习构建了，学习grunt，gulp，当时我对这些一无所知，对于构建的理解，只是处于minify html/css/js，uglify js等，想想这些不都已经有了很多现成的工具吗，然后又去grunt,gulp主页逛了，完全看不懂主页上的getting started要干什么

然而最近在尝试使用bootstrap与学习angularjs，想要试试自己搞一个小型的CRUD的app，我发现，我需要一个工具，能帮我处理这些框架中的sass，less，需要一个工具能帮我自动从framework文件夹编译成result并放入dist，而且我也根本无法脱离stylus的语法了（汗），单独编译以及手动整理真是太花费人的时间了，完全不能专注于写代码

于是诞生了以下需求：

编译sass,less,stylus
帮我把编译好的内容自动替换掉旧的dist
灵活的http-server，最好能在我修改源文件的时候自动编译好自动刷新

打开搜索引擎，发现gulp似乎在一阵之前很火热啊，于是稍稍学习了一下gulp

gulp的官方入门，我感觉不是很好，因为他只告诉了你如何安装插件233（误，好吧，看了一圈又一圈的博客，终于理解了gulp想让我们用它干什么了

编写构建任务
执行构建任务

其实核心就这两样

然后在任务中我们能干什么呢，gulp给我们了一些api

从文档中读取流（.src）
将流传到某个插件中让他读取（.pipe）
最后把插件中输出的流我们把它变回文件（gulp.pipe(gulp.dest())）

怪不得叫流式自动化构建，玛德，就不能说正常人的语言吗！

gulp还给我们提供了一个watch api，用来在任务中挂起并监视文件变动

利用gulp的任务

gulp-stylus gulp-sourcemap gulp-browserSync 利用gulp提升版本号并自动发布将任务分不同文件存放 - 我最喜欢的特性

哈哈以上都是官方的api文档，其实了解了gulp怎么运作之后，编写属于自己的任务还是挺简单的

抄写仿照官方的编译stylus与sourcemap，写了个自己的compile任务

var gulp = require('gulp'),
	stylus = require('gulp-stylus'),
	sourceMaps = require('gulp-sourcemaps'),
	runSequence = require('run-sequence');

gulp.task('compile-stylus', function() {
	//non-minified用作查看是否是编译问题而不是compress问题
	gulp
		.src('src/stylus/*.styl')
		.pipe(stylus({
			'include css': true
		}))
		.pipe(gulp.dest('src/debuggable/css/'));
	var taskReturn =
		gulp
		.src('src/stylus/*.styl')
		.pipe(sourceMaps.init())
		.pipe(stylus({
			'include css': true,
			'compress': true
		}))
		.pipe(sourceMaps.write('../../debug-maps'))//cwd:src/dist/css/
		.pipe(gulp.dest('src/dist/css/'));
	return taskReturn;
});

gulp.task('compile', function(callback) {
	runSequence(
		'compile-stylus',
		function(error) {
			if (error) {
				console.log(error.message);
			} else {
				console.log('compile finished!');
			}
			callback(error);
		});
});

然而我发现其实生成了sourcemap，chrome的调试工具就很棒的帮我们自动对应到了stylus上了，所以好像输出一下那个编译后文件并没有什么卵用了。。。

心得

注意！ gulp有个坑就是在相对路径时，不要加'./'，以及注意调用路径，第一次写任务的时候被坑惨了，还以为是自己哪里写错了or getting started过时了

gulp的运行时路径就是你cmd/gitbash的路径，不是相对于js的路径（使用require-dir的小伙伴们要注意了）

还有个坑就是自动更新版本并提交的那个中文文档有问题，插件被换掉了，所以按照中文文档写的任务是跑不起来会提示错（好像是fs.end不是一个function）

用了gulp之后，感觉真是爽爆了233

近期学习小结

Sun, 20 Mar 2016 23:36:32 GMT

Intro:

重拾HTML/CSS
jQuery与Firefox的一个坑
心得

很久没有写博客啦，其实最近一直都在学习，寒假刚开始的时候在学习Android，学着学着感觉Google给我们埋的坑实在是又多又深，关键是，你根本不知道这些是什么情况，原理是什么，去查，只会告诉你，换兼容包兄弟，太坑了吧！而且我一直认为，既然你推广MD设计，那么至少得给开发一些造好的轮子，好多实现都必须自己去实现，MD设计的一些Button什么的，仅仅是更换个背景颜色，就得自己重头造轮子，是不是要把人往悬崖上推？？？于是，在意识到这坑有点吓人的情况下，又对Android其实并没有特别大的兴趣的情况下，立刻停止了学习。

重拾HTML/CSS

大一的时候跟着Codecademy在线课程学习过基础HTML/CSS，其实当时是为了玩bilibili的空间的自定义CSS，话说回来，入门真的非常简单。然而这次重新审视自己，想想自己到底喜欢什么，看完了JavaScript的入门后，决定转前端。

重新学习HTML/CSS，更多的是在一些理论上的查缺补漏：

文档流模型（块级元素，行级元素），定位的层模型（relative/absolute/fixed）
css属性的继承性，css的选择器（+ 空格 > : []），以及属性权重（继承权重0.1 标签权重1 class权重10 id权重100 可叠加），相同情况下后覆盖前，!important大于一切（也有说权重为1000的）
三个单位：em px %各自所对应衡量的标准

其实学习HTML/CSS入门很快，但我经常发处女病（这边怎么会多1px？/这边怎么看上去不像是10px？/这边间距是不是多了4px？），但幸好不是坏事，了解了许多许多之前并没有了解的事情。

好多都有了现有的文章啦，也就不再多阐述了。

transform的matrix
CSS 外边距合并
 垂直外边距合并问题
 a img 高度多4px
position属性
 宽高成比例《- 没想到padding的height百分比是以width作参照的
inline-block 4px（间距）问题
 box-sizing
clearfix
block inline inline-block
line-height
vertical align line-height
内联元素对齐与基线对齐，块级元素与边框对齐
行高是整行的高度，并不是盒子的高度，你可以理解为盒子浮在行上，行拉开了，但是盒子还是那么高

jQuery与Firefox的一个坑

在写本博客主题的时候，碰到了一个玛德超奇怪的一个问题，为某个按钮添加了mousedown与mouseup事件，然后再给这个按钮添加了click事件，结果呢，IE都反应正常，firefox居然不发生click事件！嘿你敢信？虽然我的mouseup事件是停止了冒泡，然而关click事件奶子事情？事件冒泡不应该只是对于文档层次而言的吗？不是很懂你们Firefox，暂时先把click事件变成mouseup事件

其他关于js的一些小坑~

label触发两次click事件 label与input关系 sync script jQuery现在已经官方支持了live-query，方法名是on off js的模块化加载框架 - requireJS ejs貌似对switch语句不识别

心得

前端这边入门门槛很低，得益于完备的各大网站的html/css的完整的文档（翻译自w3school，以及各大前辈的博客），以及jquery的文档做的也很棒，学习起来真的特别方便！话说在学习jQuery的时候感觉把css所有的选择器重新复习了233

GSC-535 风来的西林

Sun, 20 Mar 2016 23:11:17 GMT

终于买了又帅又可爱的西林困，嘻嘻，稍微照几张~

Hexo主题Paper White

Sat, 12 Mar 2016 03:44:46 GMT

欢迎有爱自取啦

最后更新： 2016.01.09

Paper White - A Hexo Theme

================

ReadMe 请移步

此处将集中显示各种奇奇怪怪 demo

embed code

	//载入分享模块
	if (paperWhiteConfig.canShare) {
		require(['/js/share.js'], function(share) {
			share.init();
			share.shareLinks.push({
				id: 'download', //暂时都能下载，如有不能下载的需求移动至init进行克隆数组等操作
				label: '下载',
				url:'{{raw_image_url}}', 
				download: true 
			});
			photoSwipeOption.shareEl = true;
			photoSwipeOption.shareButtons = share.shareLinks;
		});
	}

embed gist

jsfiddle

table

项目	价格	数量
计算机	$1600	5
手机	$12	12
管线	$1	234

写一些最近Android学习中遇到的坑以及心得

Fri, 22 Jan 2016 02:05:18 GMT

Intro:

Android Studio Library的导入与导出
Java的Exception再复习
Handler的内存泄漏问题与其相关的Looper坑
AppCompat v7的Toolbar与Contextual ActionBar
心得

最近Loop：シュガーソングとビターステップ

Android Studio 库相关的正确使用姿势

Android Studio 1.5.x 更新后很多网上找到的其他教程包括回答基本都是旧版本的，直接lib下添加，然而在编译时总是遇到这样那样的问题，原因在于Gradle会把jar compile了，然而module本身的package(感觉相当于命名空间？)却没有导入，当你导入后，两行命令相互打架编译时能通过却无法生成apk提示错误。提示的错误五花八门，一会是java虚拟机非0退出，一会是Class文件重名。

引用其他人的jar/aar Lib

Library在Android Studio中相当于一个Module，在Project中如果想要导入其他人的库，则选择File->New Module...

选择Import .JAR/.AAR Package，之后简单，就不细说了，请不要忘了如果Lib作者有要求提示在Gradle中加入脚本的不要忘记加入

新建Library Project

还是新建普通的Project，然后New Module选择Android Library，在新模块下工作，写demo的话就到app下进行工作就ok了

导出Library

对整个Module Build后就可以在模块路径下，build->outputs->aar中找到aar包了

Java Exception

异常分类

所有的异常都派生于Throwable类

但所有的异常在Throwable下将分为两类:Error,Exception

Error是Java运行时系统的内部错误和资源耗尽错误，应用程序不应该抛出这样的错误。这一类不用管

Exception层则又分为两层，Runtime Exception和其他异常(Checked Exception)

Runtime Exception是运行时错误，是由于编写程序时的疏忽导致的，比如：

错误的类型转换
数组访问越界
访问空指针

其他异常包括：

打开不存在的文件
在EOF后尝试读取数据
根据字符串查找Class对象，然而该字符串表示的类并不存在

"如果出现了RuntimeException异常，那么就一定是你的问题" 去理解这句话与两类Exception，应该这么理解：

RuntimeException是指这样的问题能够在编写程序时完全避免，是逻辑异常！ 因此！ 程序运行时也不需要去针对发生这样的异常而去采取相应的解决措施。 而且！ 不应在方法上对RuntimeException进行声明

而其他异常，也就是Checked Exception，是指在书写这一方法时，对那些格式正确，命令逻辑无错但却并不存在，命令无法执行，而且并不能知道如何去解决这些问题的时候所抛出的异常对于这样的Exception，书写方法的人与调用方法的人都对这样的格式正确，逻辑无错的命令事先并不知情，对代码已检查过后抛出因此他叫已经检查过了的错误，所以这样的异常需要进行捕获，而不是事先便能排除。但Java中并没有这样一类叫做Checked Exception，这是语言规范。

事实上我觉得已检查异常这个名字真的很容易误解。~~已检查了的异常还用抛出咩233~~

请注意，所有的异常都发生在运行时，而不仅仅是RuntimeException

两类异常如何选择？

使用方法时：

当遇到RuntimeException时，应该是事先检查而避免发生异常，不是发生异常后进行捕捉处理当遇到其他异常（已检查异常）时，则应try&catch，当发生异常时，如果能够解决，则处理，不能解决，则继续向上抛出

编写方法时：

当遇到RuntimeException时，大多数情况下不必手动抛出，也不应在方法上声明，例如越界访问，一般来说，这样的运行时错误会被自动抛出，如若想自己对参数进行校正检验抛出可以继承RuntimeException类创建一个自定义运行时异常对象或者new RuntimeException对象当遇到CheckedException时，直接抛出即可

如何考虑异常的捕获

“底层抛出，顶层记录解决”，是一句比较正确程序观的话。

Handler的内存泄露问题

这个问题的引发是由于在实践Handler时使用匿名内部类/非静态内部类重写handleMessage方法，Android Studio的深色提示会显示：

这个问题的解决很多文章很多回答都有，贴两个： http://blog.csdn.net/lincyang/article/details/46875157 http://www.jianshu.com/p/cb9b4b71a820

在看这些回答前，应该先了解，在Java中的引用与垃圾回收的机制，以及强弱引用 http://blog.csdn.net/matrix_xu/article/details/8424038

对于这些回答中的一些小疏漏就是，对于任何外界（生命周期比Handler短）的引用，都应该用WeakReference

深层次想法

对于内存泄漏，就是该释放的时候，系统的垃圾回收器没办法释放掉，原因是有强引用正在引用着这个对象，如果说两个对象的生命周期一致，则没有这个问题，如果说生命周期比我生成的对象要短，而且，我不一定需要这个对象一定是保存到我的对象结束为止的话，就应该使用弱引用而不是强引用

Looper

Looper这个坑真是深的不行，所有的学习过程中，包括看视频啊，看书啊，看博客啊，都没有提到。对于线程之间的通信，使用的是Handler/Message Queue进行相互交流，对于自行new 的线程，我们需要执行以下两步来初始化Looper以保证Handler能处理消息


@Override
public void run() {
	//do anything
	Looper.prepare();
	//prepare your Handler here and do anything
	Looper.loop();
}

然而当我们的Handler处理完消息，我们的消息只需要处理一次，想要把线程终结了的时候，没有视频，没有书会告诉你，要记得把Looper关掉，源码是说Looper.loop()是死循环，因此Thread永远不会停止，Handler永远会接受消息，没错Handler的职责就是一直负责处理消息，然而如果没有消息再进来了，这时我们不需要这条线程这个Handler这个Looper了，如果一直不停的创建Looper，则会引发Android的Assert! Assert的提示是：

Abort message: 'Could not create wake pipe.  errno=24'

或者是

Looper: Could not create epoll instance.  errno=24

有时会提示

/A art/runtime/indirect_reference_table.cc:77] Check failed: table_mem_map_.get() != nullptr ashmem_create_region failed for 'indirect ref table': Too many open files

真是千奇百怪的错误提示，google搜了一大圈都没搜到，也从来没有往Looper这个方向想，尽管loop是死循环，但对他死循环没有卡系统也就没有想太多

根本原因Looper的实现是用pipe//待探究

最后解决是如果我处理完了信息不需要Looper了，对Looper对象进行quit()就可以了：looper.quit();，这样线程也就随之而结束了

Looper对象如何获取：在prepare后 Looper looper = Looper.myLooper(); 就可以了

当然啦，如果处理异步，规范的做法应该是两条线程，主线程交给后台线程进行处理耗时操作，而不是每次新开的一个线程里直接发送返回处理

~~（我不会说我在写这段话的时候才想起来应该这么做，这个问题可困扰我好长时间了）~~

对于有兴趣想知道为什么我会找到这样问题的可以来看：

pixivImageCacheHelper

想法是新开一个线程发送请求后就在当前线程处理返回的请求，应该做法是在新开的线程中定义Handler，将这个handler作为主线程发送的请求的参数

AppCompat v7的Toolbar与Contextual ActionBar的坑

Google 在v7兼容包发布后对于Contextual ActionMode感觉上来说不太支持，所有的文档也并不鼓励使用Contextual ActionMode，然后在使用的过程中就感受到了满满的恶意

来自谷歌官方的提示： Note: The contextual action bar is not necessarily associated with the app bar. They operate independently, even though the contextual action bar visually overtakes the app bar position.

Toolbar and Contextual ActionBar with AppCompat-v7

https://stackoverflow.com/questions/26443403/toolbar-and-contextual-actionbar-with-appcompat-v7 http://stackoverflow.com/questions/27663853/how-to-make-the-contextual-actionmode-bar-overlay-the-appcompat-v7-toolbar-but-n

http://stackoverflow.com/questions/32318563/appcompat-v7-v23-0-0-statusbar-color-black-when-in-actionmode

最后对于ActionMode的status bar变黑问题上，我选择了： http://stackoverflow.com/questions/30180091/when-using-actionmode-the-status-bar-turns-black-on-lollipop 的处理方法，虽然不够完美，有精力的话是会想重新自己造轮子的

心得

感谢你看到这里！

对Java/Android的设计模式感受到了前所未有的累，虽然知道他用的这个模式，自己在写的时候虽然只是模仿就已经是非常艰难了，因为是在学习，虽然是以作品驱动的学习动力，也不敢乱用第三方的库啊什么的，嘛，希望自己能够加油！ ~~自己选的坑含着泪也要跳下去~~

IDEA/Android Studio的一些自用快捷键：

Ctrl+P 方法参数提示
Ctrl+Space 补全提示
Ctrl+B 快速跳转定义/实现
Ctrl+Q 文档显示

References：

都是已经填平了的坑的文章，感谢这些作者的付出！

API Demos Source Code From Git at Google Why do variable names often start with the letter 'm'? imageView src与background关于alpha的两三事 RecyclerView的使用为RecyclerView 添加ChoiceMode

大量图片异步加载 http://blog.csdn.net/chdjj/article/details/20455791 https://developer.android.com/training/displaying-bitmaps/cache-bitmap.html

SwipeRefreshLayout RecyclerView的下拉刷新与上拉加载 http://51up.club/2015/10/13/SwipeRefreshLayout-RecyclerView-%E5%AE%9E%E7%8E%B0%E4%B8%8B%E6%8B%89%E5%88%B7%E6%96%B0%E5%92%8C%E4%B8%8A%E6%8B%89%E5%8A%A0%E8%BD%BD%E6%9B%B4%E5%A4%9A/ https://www.easydone.cn/2015/10/26/

Stepping Further - 2016

Fri, 01 Jan 2016 00:00:00 GMT

Time flies very fast. 一年之中的种种似乎仿佛还在眼前，然而却也是回不去的昨天。

blog的诞生

域名是2015年年初购买的，购买的原因我似乎自己也快忘了，好像是当时测试用的Azure还没有过期，自己就买了个域名搭着服务器玩玩apache与wordpress，然而才用了一两个月好想Azure就开始关闭测试账户了，真是意想不到，因为这项开支，自己却无意中学习了那么多有趣的知识，比如域名记录A AAAA CNAME NS，比如静态博客生成Hexo框架，比如CSS in YAML Aint Markup Language，认识了很多网页的调试工具。其实自己去年刚学习HTML+CSS的时候感觉非常有趣就有想当前端的想法，然而却又太胆小，不敢去学，那时什么都不知道，今年虽然下定决心要当个dev，~~但想学js的心仍然没有停止（待我会玩Android就学）~~ 另外到现在也其实没整明白博客有啥意思，像我这样连高考作文800字憋不出来的人，能憋出这么多字的博客已经是精一杯了，明明自己微博活的更精彩。

第一篇来自hexo的博客

20岁

我仍然不敢相信自己居然已经跨入20岁，我似乎一直觉得自己还是15，16，似乎昨天还是高三学生，似乎今天还要背诵默写古诗词，但身边一切的一切都早已变了。20岁的这一年，有了人生许多的第一次，20岁的这一年，明天似乎触手可得。傍晚时分，我给自己买了一块跟去年一样的蛋糕，希望能够重新背起包袱，向人生的最有活力的时段进发。

成绩

当大家都不怎么学习的时候，你只需稍稍的努力，便能取得一个很不错的成绩。第一次尝到认真学习的甜头，只用了半个学期，就把上半学年不怎么地的绩点拉了上来还能拿奖，但综合这一年，感觉不怎么合算，第二学期还好，大三上的这一个学期，写了很多，做了很多，然而并没有什么卵用，虽然还没出成绩，但感觉得分不会很高。你很认真的在做一个东西，你把他当一个产品来看待，用了很多课外的知识，但老师只看你课内努力的这一部分，那为什么不早点告诉我我随便写点玩具代码就交给你呢？而且想要发展的方向也并不是C#方向，老师连基本的面向对象的概念也不讲，这个年纪，真是耽误人啊！下半年把java核心技术这本书好好的读了一遍，还是写的不错，话说几个好友给我推荐的几本书都很好很容易上手也由浅入深，很喜欢很经典，嘛，就是没有时间去实践，虽然在写算法题的时候会用java来写，但还是感觉熟练度啊，熟悉程度啊，完全是比不上连书都没看过的C#，这完全得益于winform/wpf的框架和自动提示，太智能，不得不感叹上手容易，想搜什么也是很快就能定位到目标。

第一次的独立远行

惭愧的是，这么大了居然才是一个人出门玩（典型的家长的独生乖儿子），出门玩也是各种三叮咛四嘱咐的，到了帝都还时不时打电话来发短消息发QQ发微信给我问我玩的开心不开心，也是醉了！花了小半天做了点有什么好玩的地方的功课就冲动的买下了火车票，也没跟任何人说，然而等我坐上车的时候却被母亲的大嘴巴已经讲的全亲戚朋友都知道了。。。。。也没跟太多人搭过话，所以自认这趟旅行京味还是不够足的，但值回票价就可以啦！逛过巷子，去过景点，吃过包子（跟魔都小笼类似），看过孔夫老爷子，拜过国子监~~（怪不得下半年那么拼原来是上身了）~~，还有什么值得留恋的呢？

测试

作为想要当一名合格的coder的人，深知算法和数据结构是基础内功，然而此内功虽然是万恶之本，但点到即可，不需过多掌握，关键在于应用性技能，但看到身边的一小部分同学有些出没ACM比赛，有些不知道搞起了什么东西胸有成竹，自己的心中总有那么一些不安，想做些什么，另一个自己却总是说“你什么都不会出去丢人？不怕被拒？”，于是自己也报了一些所谓的一个测试标准，成绩下来的时候还是有点意外的，班长说咱学校好久没有300分以上的了，你终于过了，我感觉很莫名其妙，300分算很好嘛。。。。毕竟自己什么练习也没做。。。。稍稍安心了一下，虽然这个测试现在看起来并没有什么卵用。。。。

年末的实习

下定决心年末想找份实习实践一下半年一年所学吧，可以熟练一点，然后也是算是受到了监督前辈的鼓舞吧，再加上自己看着下半年的抢钱计划（长叹一口气），想想自己简历也没什么好写的，斗着胆随便写了点东西就投了，然后有一家要我去面试，感觉还行吧也没问什么特别奇怪的问题，就是数据结构算法和面向对象的问的多了点，关于语言的倒是只问了重载的写法，有点让我意外，却也在情理之中，虽然知道自己大三and一般单位周六周日都不会上班因此基本上是不会被录取的，话也说在前面了，但面试的这个程序员小哥还是把面试面完了，也不知是真是假，他说你要是大四我就要你了（这应该只是安慰吧应该只是安慰吧），反正再学习一下吧，寒假里把安卓再好好学学，写一个算能见人的作品，也通过这次面试知道自己数据结构还有面向对象这些小概念还是不是很清楚需要再深入学习。不算是一个差的结局吧，永远相信努力的人运气不会太差~~（？）~~

动画小结

今年感觉会坑很多连载动画，大多看了一部分便又开始兴致冲冲的追了另一部动画片，前一部便一直搁着，还有就是不愿意在闲暇时间看动画，喜欢把大块时间留给动画，然而大块时间都在写作业导致了看番的时间少得可怜（在写这篇文章时离年末还有一个礼拜，不知道这一个礼拜能不能把坑都补掉，这一周作业都解决了基本没事）

年初：

记录的地平线（一）/2014年而来的四月是你的谎言/战勇/打工吧魔王大人/男子高中生的日常/Hunter X Hunter/流星洛克人 & Tribe/记录的地平线（二）

年中以动画电影为主：

秒速5厘米/情热传说导师的黎明/追逐繁星的孩子/萤火之森/穿越时空的少女/ブレイブストーリー/ 夏日大作战/言叶之庭/幽灵公主/龙猫/风之谷/起风了/星之声

年末：

银之匙（一）（二）/高达创战者（一）/Battle Spirits Season 6(最強銀河究極ゼロ～バトルスピリッツ～) 最后还完整复习了DA01 DA滚球兽的诞生 DA我们的战争游戏

动画小结的最后再甩一下锅，其实也有部分不是我的错！还有汉化组还没出汉化的呢_(:3」∠)_

游戏小结

今年可以说在游戏上，在动漫上还是花了比较多的钱的，无论是旧坑闪十一，还是新坑TOZ，还是年末的新坑BS，花钱花精力，真是辣鸡游戏，毁我钱财，败我身心233，psv，ps4，new 3ds全都有了，大概是真·迈向死宅了（。

PS4

当得知TOZ要出PS4版本时，心中便已按捺不住，偷跑一出便下了单一起把ps4买了，玩了十几个小时，画质实在是太棒了，高清斯雷舔舔舔啊！

3DS

今年游戏玩了很多，坑了也很多，没有一款游戏基本是好好认真的刷刷刷的，上半年把go3 超新星刷了个自觉的算是满意了，给这张盘画上了个算是圆满的句号吧，然而就是把之前刷了130个小时的稍微完善一下也花了30多个小时，全年第二，临近年末玩了火纹if，打算认真刷的，然而在今年结束前是不可能结束掉啦。

PSV

今年购买了太鼓达人V和初音F2，f2其实在上半年的ps3中就已经通过关了，然而感觉歌曲还不错于是便买下来了重新打，太鼓达人作为一款零碎时间的打发游戏，V版的歌曲还是很不错的（一开始还不了解，打了感觉还不错），太鼓达人是好友Fido安利的

音乐

7!!的オレンジ作为四月是你的谎言的ED，从听到这首歌开始，一直loop到了年末，很喜欢钢琴的那一部分，很动人

Stepping Further - 2016

一年回顾的最后，自己给自己煲个鸡汤，无论是2015年喜也好，2015年的悲也好，还是错过的遗憾，还是令人感慨的种种，都已是过去的一页，无论喜忧，要好好面对2016的自己，希望能够在新的一年中找到一份像样的实习工作，希望能够快点学会自己想要学会的东西，打起12分的精神，能够像えんどうさん一样继续充满干劲！

2016年初计划

2015年没有看完的番统统要看完
2015年没有打完的游戏统统要打完
2015年没有看完的书要统统看完
以上内容不准延续到2017

看起来并没有诚意呢233

解决一个OTA后安装Xposed发生No space left on device错误

Thu, 31 Dec 2015 18:22:18 GMT

遇见情况

Android 5.0.1->6.0.1 OTA并root后安装Xposed框架，却提示报错：

cp: write error: No space left on device

第一次看见这样的错误提示，觉得很奇怪，明明手机剩余空间还有一半以上，后来爬贴才发现system分区分开来的，/system/App分区的可用空间居然小于20MB了

好吧，google也是可以的，只能删除一些谷歌的全家桶了

解决方法

使用任意可使用root权限的文件管理器，定位到/system/App下删除不使用的app的文件夹即可，腾出20M以上就可以了

Reference

解决安装 XPOSED 时遇到的cp: write error: No space left on device

重配置WNDR4300手记

Thu, 31 Dec 2015 18:20:58 GMT

给路由器迁移的时候，发现了一个SS的问题，导致自己踩雷又从头配置了一遍。。。（作死小能手前来报到）

缘由

今天是美好的12.31号，也是在学校的最后一个学习日（下周起为考试周），心情异常高兴，自然是要把学校那个很好的路由器带回家咯，虽然曾有过一次不同环境配置的经验，但今天居然掉坑了

环境说明

家庭：上海电信光纤接入，光猫自带路由，不可更改，想要自接无线路由出墙需要无线路由再分配一次DHCP 学校：上海电信光纤接入，光猫不自带路由，自己拨号

到家直接更改接口处的LAN与WAN，分别改成如图所示：

172.168.x.x是很容易想到的除开192的一个地址，虽然属于B类地址，然而现在并没有被卖掉，也被大家广而使用，因此也并没有什么特别的不妥，大不了以后要是有人指向他了，咱就改成192之后的呗

改完之后发现网能上了，也能顺利出去了，但踏马的路由器设置进不去了，诶怎么都进不去，把网断了，踏马的还是进不去，断网前不停地转圈圈，一直waiting For 172.168.1.1...断网后显示Connection Reset，亲你是在逗我吗！这叫个什么事！什么叫网上的去路由器设置上不去，狗带！

仔细想想，想来想去，还是没有想出个啥道理，以为自己哪里设置没改过来，只好重置

重配置

语言的更改

重置完后的第一件事情是要将英语改成中文，虽然咱英文不烂，但网络有些专有名词看起来再过一遍脑子还是挺吃力的，关于为什么要改语言，就要追溯到上一个作死贴WNDR4300救砖（openwrt），15.05官方固件踏马没带中文！话题回来，首先我们要做的是

opkg update

但这个狗带的电信尼玛又作死了！openwrt.org开不开，奇慢无比，而且15.05的openwrt在配置里可以看到是有签名校验的，想了很久，去搜了一下可行性，最后还是用镜像站吧，还是ustc的大学站，不错啊，你们这个镜像站啊，excited！啧啧

将软件包配置改成如下：

原：

dest root /
dest ram /tmp
lists_dir ext /var/opkg-lists
option overlay_root /overlay
src/gz chaos_calmer_base http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/nand/packages/base
src/gz chaos_calmer_luci http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/nand/packages/luci
src/gz chaos_calmer_packages http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/nand/packages/packages
src/gz chaos_calmer_routing http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/nand/packages/routing
src/gz chaos_calmer_telephony http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/nand/packages/telephony
src/gz chaos_calmer_management http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/nand/packages/management
option check_signature 1

改后：

dest root /
dest ram /tmp
lists_dir ext /var/opkg-lists
option overlay_root /overlay
src/gz chaos_calmer_base http://mirrors.ustc.edu.cn/openwrt/chaos_calmer/15.05/ar71xx/nand/packages/base
src/gz chaos_calmer_luci http://mirrors.ustc.edu.cn/openwrt/chaos_calmer/15.05/ar71xx/nand/packages/luci
src/gz chaos_calmer_packages http://mirrors.ustc.edu.cn/openwrt/chaos_calmer/15.05/ar71xx/nand/packages/packages
src/gz chaos_calmer_routing http://mirrors.ustc.edu.cn/openwrt/chaos_calmer/15.05/ar71xx/nand/packages/routing
src/gz chaos_calmer_telephony http://mirrors.ustc.edu.cn/openwrt/chaos_calmer/15.05/ar71xx/nand/packages/telephony
src/gz chaos_calmer_management http://mirrors.ustc.edu.cn/openwrt/chaos_calmer/15.05/ar71xx/nand/packages/management
option check_signature 1

好噜，上网再搜了一下，luci的最新的中文界面语言包的包名叫做luci-i18n-base-zh-cn，got后直接

opkg install luci-i18n-base-zh-cn

就好啦，安装基本包的时候也使用这几个镜像站，等到我们装完ss后再改回来升级安装包吧

打不开172.168.1.1原因的发现

之间一路顺风，安装各种依赖包ss chinadns什么的，这个因为之前 ~~作死过很多次~~ 装过很多次，所以还是比较知道的，待老夫配置好ss后启动试试效果，结果踏马的又开不开我的路由器配置界面啦！情况和开始的一样！哇擦！才想起来，172.168.x.x的地址会不会并没有被排除掉然后被ss接管了直接转发出去了，幸好这个时候putty是连接着的（ssh连接为何不受ip地址影响也是不懂了），赶紧关掉ss，发现路由器设置能进了，内心松下一口气，但我也很奇怪，为什么上次回来的时候路由器也是这样搞得一切正常呢。（后想起：ss openwrt版本呢2.3.1后不再自带ignore.list）

想来想去，好吧，也没有很好的系统层面上的解决方法，ss我也不知道她的实现方法是怎样的，先添加一下排除试试看吧，定位到ss的luci界面，直接在下面添加了排除，重启服务，发现一切正常，可以进入，明白了ss排除有效，因此我需要在ss的ignore.list将172.168.x.x这个域名段全部添加入，排除掉他，这样我内网传输也暂时不会有什么问题了。

putty定位到/etc/ignore.list（我的ignore.list设定在这里，你需要定位到自己设置的位置），vi打开

前面的四位ip地址姑且能理解，后面的16 18 19 24是什么鬼啊！后实验一番，想起计算机网络的内容（x

每个ip数字8位二进制，/后指的是指定到多少位忽略，比如

1.0.1.0/24 -> 00000001.00000000.00000001.00000000的前24位，也就是1.0.1.x会被忽略

所以如果我想要172.168.x.x忽略的话，则可以设定 172.168.0.0/16

重设定之后，重启发现一切正常，问题解决

安全性

咱刚才不是设置了镜像站么，如果镜像站被政要控制了，咱下下来的东西带有恶意脚本监控咋办，只好说，如果到那时，咱只能用能出去的电脑把包包都下下来再scp上传安装，我也试过，然而我并不知道安装顺序，出来了一些错误，什么找不到，那个找不到，唉，这东西对我这个linux门外汉实在是太高深了，只能希望那一天不要到来吧，也希望永远不要再重新配置这个路由器了。。。。我已经看到头大了。。。

结束记

明明下午计划好的是美好的补番行动，然而我却又把青春与生命献给了狗屎的电信，谴责一下万恶之源，拨号/公网ip还给家庭用户，会断你财路？你没AT&T T-Mobile有钱？你踏马想钱想太多了吧！我只想说不义之财不可得！早日飞妈！

闪电十一人GO动画全op&ed音乐专辑整理

Sat, 26 Dec 2015 16:02:54 GMT

和无印相比，go的资源真是好找了许多除GO3 ED外均为320K+APE/FLAC，GO3 ED只有320K且无完整专辑【我看GO3的时候ED从来只看左边正片233，ed3信息少得可怜建议使用Ctrl+F迅速找到所在专辑有BK的尽量附上BK 该单曲要是有单曲专辑会在当前歌曲优先附上单曲专辑（一般来数单曲专辑是完整版歌曲，如果要寻TV版长度一般在原生集中）所有歌曲的专辑皆以动画发布的歌曲专辑优先，歌手自己的专辑将不包括在这次整理中提示输入密码的话，所有密码均为：xingo（只是为了不被各大网盘屏蔽篡改）如果无法下载，又或者是因为疏忽编辑错误，又或者是发现了某资源的无损版本，请立刻在微博上@xingo

专辑来源来自互联网，非常感谢各位署名的不署名的分享！由于整理时头晕眼花恕不能全部加上来源（基本都附在压缩包的注释内），如果在这里找到自己的资源需要注明的话请与我联系我会立刻加上！

主题曲类

op类

GO1

天までとどけっ! （第1话~第18话）（所属专辑：单曲专辑）

T-Pistonz+KMC - 天までとどけっ! 商品番号 PKCF-1055 JAN 4942463623050
メディアマキシシングル CD
組枚数 1 発売日 2011/07/06

アーティスト/ キャスト T-Pistonz + KMC

内容大人気アニメ「イナズマイレブン」の新シリーズ「イナズマイレブンGO」のオープニングテーマ

と、ゲーム「イナズマイレブンストライカーズ」のオープニングテーマを収録! すっかり「イナ

ズマイレブン」の顔となったT-Pistonz+KMCが今回も担当!

収録曲

天までとどけっ!
みんなあつまリーヨ!
天までとどけっ! (オリジナル?カラオケ)
みんなあつまリーヨ! (オリジナル?カラオケ)

320K（无BK）下载地址

(115)http://115.com/lb/5lbafaqmll8j (baidu)http://pan.baidu.com/s/1bnvmT0V (微盘)http://vdisk.weibo.com/s/APlR9kfmR3Hx (360云盘)http://yunpan.cn/Q7JcYmIWuvrC4 提取码 8351

ape下载地址：

(115)http://115.com/lb/5lbdyhc2ot09 (baidu)http://pan.baidu.com/s/1jdCN8 (微盘)http://vdisk.weibo.com/s/APlR9kfmR3A4 (360云盘)http://yunpan.cn/Q7JcLt7HWsIba 提取码 ef28

成せば成るのさ七色卵（第19话~第33话）（所属专辑：单曲专辑）

T-Pistonz+KMC - 成せば成るのさ七色卵商品番号：PKCF 1059 高視聴率を更新中！爆裂超人気アニメ「イナズマイレブンGO」!! Wii用ソフト、ニンテンドー3DS

ソフトも続々発売、映画化も決定し、ますます注目を集める「イナズマイレブン」シリーズ！すっかり「イナズマイレブン」の顔となったT-Pistonz＋KMCが今回こアニメオープニングテーマ

を担当。9月7日放映分より新オープニングテーマがオンエア！今回も熱い楽曲でアニメを更に盛

り上げます！

収録曲

成せば成るのさ七色卵
がってんだっしょ!
成せば成るのさ七色卵 (オリジナル?カラオケ)
がってんだっしょ! (オリジナル?カラオケ)

320K下载地址

(115)http://115.com/lb/5lbcmolp3zz6 (baidu)http://pan.baidu.com/s/1pJ5DMqv (微盘)http://vdisk.weibo.com/s/APlR9kfmR3He (360云盘)http://yunpan.cn/Q7KM3Tzxuvi8x 提取码 8bb7

ape下载地址：

(115)http://115.com/lb/5lbcmogki4k7 (baidu)http://pan.baidu.com/s/1gdd3O4r (微盘)http://vdisk.weibo.com/s/APlR9kfmR3Bc (360云盘)http://yunpan.cn/Q7JcPfwZLRndI 提取码 d6e1

#### おはよう！シャイニング·デイ（第34话~第45话） / 打ち砕ーくっ！（第46话~第47话）（所属专辑：单曲专辑）

T-Pistonz+KMC - おはよう！シャイニングデイ／打ち砕ーくっ！価格 1050円(税込) 発売日 2012/02/15 商品番号 PKCF-1073 JAN 4942463623234 メディアマキシシングル CD 組枚数 1

アーティスト/ キャスト T-Pistonz+KMCT-Pistonz + KMC

内容アニメ『イナズマイレブンGO』オープニングテーマ、3DS用ソフト『イナズマイレブンGO シャイ

ン』オープニングテーマ「おはようシャイニング?デイ」、3DS用ソフト『イナズマイレブンGO ダ

ーク』オープニングマテーマ「打ち砕ーくっ!」を収録! これぞT-Pistonz+KMCの真骨頂、パワフ

ルで超ポジティブなナンバー!! 通常盤は、イナズマイレブンGOカードゲームプロモカード1種封

入。

収録曲

おはよう!シャイニング?デイ
打ち砕ーくっ!
おはよう!シャイニング?デイ (オリジナル?カラオケ)
打ち砕ーくっ! (オリジナル?カラオケ)

320K下载地址

(115)http://115.com/lb/5lbew5obdrur (baidu)http://pan.baidu.com/s/1hqehJ4w (微盘)http://vdisk.weibo.com/s/APlR9kfmR3HT (360云盘)http://yunpan.cn/Q7JcSctEnbhF8 提取码 814c

ape下载地址：

(115)http://115.com/lb/5lbew5k4lh9k (baidu)http://pan.baidu.com/s/1eQpHfTg (微盘)http://vdisk.weibo.com/s/APlR9kfmR3B8 (360云盘)http://yunpan.cn/Q7JHe2rjCkmvC 提取码 a00b

GO2 Chrono Stone

情热で胸アツ！（第1话~第17话(奇话数)）（所属专辑：单曲专辑）

T-Pistonz+KMC - 情热で胸アツ！ CD (2012/6/20) ディスク枚数: 1 フォーマット： Single, Limited Edition, Maxi レーベル: アップフロントワークス収録時間: 17 分 ASIN: B007MDQ2SM EAN： 4942463623272

内容紹介：爆熱大人気「イナズマイレブンGO」新オープニングテーマを歌うのはもちろんT-Pistonz+KMC!! ニューシングルは“イナズマユニフォーム付き!!"

「情熱で胸アツ! 」は4月よりテレビ東京系アニメ「イナズマイレブンGO クロノ·ストーン」OPテ

ーマとしてオンエア! 今回はなんと初回限定盤の特典として、イナズマイレブンGOユニフォームが付いてくる!! 松風天馬·剣城京介·神童拓人各モデルは、それぞれ背番号が異なるデザイン!イナズマイレブンフ

ァンには見逃せないマストアイテム!!

収録曲：

情熱で胸アツ!
心をつなごう!
情熱で胸アツ! (オリジナル·カラオケ)
心をつなごう! (オリジナル·カラオケ)

320K下载地址

(115)http://115.com/lb/5lbewvrsbxfo (baidu)http://pan.baidu.com/s/1hqqYWoG (微盘)http://vdisk.weibo.com/s/APlR9kfmRFvA (360云盘)http://yunpan.cn/Q7JuHDSRpxeHC 提取码 c46e

ape下载地址：

(115)http://115.com/lb/5lbaf61mk6x4 (baidu)http://pan.baidu.com/s/1o64tUh8 (微盘)http://vdisk.weibo.com/s/APlR9kfmRFvF (360云盘)http://yunpan.cn/Q7ZbRVmFjnm5B 提取码 99e2

感动共有！（第2话~第18话(偶话数)）（所属专辑：单曲专辑）

T-Pistonz+KMC - 感动共有！発売日：2012/07/04 商品番号：PKCF-1083

2012年4月より新シリーズとなってますますパワーアップした、テレビ東京系TVアニメ『イナズマ

イレブンGO クロノ?ストーン』のアナザーOPテーマ曲ほかを収めたシングル。表題曲の「感動共有!」は、4月25日よりOPテーマ曲「情熱で胸アツ!」と隔週でオンエア中!

爆発大人気「イナズマイレンGO クロノ?ストーン」アナザーオープニングテーマソング!

収録曲 1 感動共有! 2 突き抜けろっ! 3 感動共有! (オリジナル?カラオケ) 4 突き抜けろっ! (オリジナル?カラオケ)

320K下载地址

(115)http://115.com/lb/5lbcm7fxwejb (baidu)http://pan.baidu.com/s/1i3BVDDr (微盘)http://vdisk.weibo.com/s/APlR9kfmRFvt (360云盘)http://yunpan.cn/Q7VxYkL9rbefQ 提取码 c44c

ape下载地址：

(115)http://115.com/lb/5lbbsqu6j8td (baidu)http://pan.baidu.com/s/1c0xmJDm (微盘)http://vdisk.weibo.com/s/APlR9kfmRFvt (360云盘)http://yunpan.cn/Q7VxP8C7pmdT5 提取码 6ebd

初心をKEEP ON！（第19话~第35话）（所属专辑：单曲专辑）

TVアニメ『イナズマイレブンGO クロノ?ストーン』OP3「初心をKEEP ON!」／T-Pistonz + KMC 発売日：2012/10/31 商品番号：AVCD-55005

テレビ東京系アニメ『イナズマイレブンGO クロノ?ストーン』新オープニング?テーマ。

収録曲

初心をKEEP ON!
手をつなごう
初心をKEEP ON! (オリジナル?カラオケ)
手をつなごう (オリジナル?カラオケ)

320K下载地址

(115)http://115.com/lb/5lbcm7fpynab (baidu)http://pan.baidu.com/s/1eQGL566 (微盘)http://vdisk.weibo.com/s/APlR9kfmRFv_ (360云盘)http://yunpan.cn/Q7VxS48fA88dQ 提取码 2300

ape下载地址：

(115)http://115.com/lb/5lbcm7fpdea0 (baidu)http://pan.baidu.com/s/1kTzauij (微盘)http://vdisk.weibo.com/s/APlR9kfmRF1T (360云盘)http://yunpan.cn/Q7VxBxkpeGzJb 提取码 990a

ライメイ！ブルートレイン（第36话~第51话）（所属专辑：单曲专辑）

T-Pistonz+KMC - ライメイ！ブルートレイン CD (2013/2/13) 光碟数目: 1 フォーマット： Single, Limited Edition, Maxi レーベル: FRAME 収録時間: 32 分 ASIN: B00AI9HHJA EAN： 4988064550197 T-Pistonz+KMCが歌うテレビ東京系アニメ『イナズマイレブンGO クロノ?ストーン』のオープニン

グ?テーマ、ニンテンドー3DS『イナズマイレブンGO クロノ?ストーンライメイ』のテーマ?ソン

グ「ライメイ!ブルートレイン」を収録したシングル。さらに、「ネップウ!ファイヤーバード2号

」はニンテンドー3DS『イナズマイレブンGO クロノ?ストーンネップウ』のテーマ?ソング。

ライメイ!ブルートレイン
ネップウ!ファイヤーバード2号
掌のぬくもり
ライメイ!ブルートレイン (オリジナル?カラオケ)
ネップウ!ファイヤーバード2号 (オリジナル?カラオケ)
掌のぬくもり (オリジナル?カラオケ)

320K下载地址

(115)http://115.com/lb/5lbbsqxtq60h (baidu)http://pan.baidu.com/s/1bnbAgsZ (微盘)http://vdisk.weibo.com/s/APlR9kfmRuYw (360云盘)http://yunpan.cn/Q7Vx67WQfxugT 提取码 8fb3

ape下载地址：

(115)http://115.com/lb/5lbewvlpi6u3 (baidu)http://pan.baidu.com/s/1CjVki (微盘)http://vdisk.weibo.com/s/APlR9kfmRuYo (360云盘)http://yunpan.cn/Q7VnFxwN6xmgH （提取码：ee80）

GO3

ガチで勝とうゼッ!（第1话~第17话）（所属专辑：单曲专辑）

T-Pistonz+KMC - ガチで勝とうゼッ! 艺人 : T-Pistonz+KMC 专辑 (Single) : ガチで勝とうゼッ! (Gachi de Katoze!) 发行日期 : 2013.06.19

内容紹介 :

パフォーマンス?グループT-PistonzとラッパーのKMCによる合体ユニットの16thシングル。「ガチ

で勝とうゼッ!」は、テレビ東京系アニメ『イナズマイレブンGO ギャラクシー』のOPテーマに起

用されたハイ?テンションなナンバーだ。

ガチで勝とうゼッ!
空は知ってる
ガチで勝とうゼッ!(オリジナル?カラオケ)
空は知ってる (オリジナル?カラオケ)

320K（无3、4）下载地址

(115)http://115.com/lb/5lbewvltee1p (baidu)http://pan.baidu.com/s/1gdEbDcR (微盘)http://vdisk.weibo.com/s/APlR9kfmRuYL (360云盘)http://yunpan.cn/Q7ZbBtcfbbncJ 提取码 971a

ape下载地址：

(115)http://115.com/lb/5lbd24923vdg (baidu)http://pan.baidu.com/s/1bnvmTXl (微盘)http://vdisk.weibo.com/s/APlR9kfmRuYs (360云盘)http://yunpan.cn/Q7Vx8JTeNZZzf 提取码 a06d

地球を回せっ！（第18话~第32话）（所属专辑：单曲专辑）

[131120]TVアニメ「イナズマイレブンGO ギャラクシー」新OPテーマ「地球を回せっ!」／T-

Pistonz+KMC 登録情報 CD (2013/10/30) ディスク枚数: 1 フォーマット： Single, Maxi レーベル: FRAME 収録時間: 17 分 ASIN: B00EPD2PLK EAN: 4988064550487

内容紹介【初回特典(封入)】イナズマイレブンシリーズチェンジングジャケット(円堂守、白竜、剣城

京介の3種類中1種ランダム封入)

テレビ東京系アニメ「イナズマイレブン」シリーズのオープニングテーマでおなじみ、T-

Pistonz+KMCのニューシングルがリリース決定。爆熱放送中! テレビ東京系6局ネットアニメ「イナズマイレブンGO ギャラクシー」新オープニン

グテーマ!!!爆熱放送中!

Disc-1 CD

地球を回せっ!
チャンス!!
地球を回せっ! (オリジナル·カラオケ)
チャンス!!(オリジナル·カラオケ)

全2曲4バージョン収録予定メディア掲載レビューほかパフォーマンス·ユニット「T-Pistonz」に、ラッパー「KMC」が合体した、T-Pistonz+KMCのシン

グル。

収録曲:

地球を回せっ!
チャンス!!
地球を回せっ! (オリジナル.カラオケ)
チャンス!!(オリジナル.カラオケ)

320K下载地址

(115)http://115.com/lb/5lbbp19z4tth (baidu)http://pan.baidu.com/s/1eQvMJ7c (微盘)http://vdisk.weibo.com/s/APlR9kfmRsCx (360云盘)http://yunpan.cn/Q7VxEv9ItnHxf 提取码 4759

flac下载地址：

(115)http://115.com/lb/5lbc4i8f22e7 (baidu)http://pan.baidu.com/s/1eQCbOrw (微盘)http://vdisk.weibo.com/s/APlR9kfmRsBV (360云盘)http://yunpan.cn/Q7VxWrzAidGv3 提取码 54a3

这张专辑有PV MV和Live的dvd资源，不过我觉得没有收藏的必要有欲收藏的老爷请点这里->http://bbs.dm123.cn/read-htm-tid-794059.html

スパノバ！（第33话~第43话）（所属专辑：单曲专辑）

T-Pistonz+KMC - スパノバ!／BIGBANG! Disc-1 CD M-1:スパノバ! M-2:BIGBANG! M-3:スパノバ! (カラオケバージョン) M-4:BIGBANG! (カラオケバージョン) 全2曲4ヴァージョン収録予定 ※曲順は変更の可能性がございます。

Disc-2 DVD

スパノバ! (ミュージックビデオ)
スパノバ! (振付レクチャービデオ)

320K下载地址

(115)http://115.com/lb/5lbefc4ee8zk (baidu)http://pan.baidu.com/s/1CPScQ (微盘)http://vdisk.weibo.com/s/APlR9kfmRsCv (360云盘)http://yunpan.cn/Q7ZbMv5VvKniq 提取码 a17c

flac（含MV）下载地址：

(115)http://115.com/lb/5lbd2ab3quio (baidu)http://pan.baidu.com/s/1hqvIFB2 (微盘)http://vdisk.weibo.com/s/APlR9kfmRsCJ (360云盘)http://yunpan.cn/Q7VvGfURLkm5U　提取码 5290

ed类

GO1

やっぱ青春（第1话~第18话）（所属专辑：单曲专辑）

空野葵（北原沙彌香） - やっぱ青春 CD (2011/6/22) ディスク枚数: 1 フォーマット： Single, CD+DVD, Limited Edition, Maxi レーベル: アップフロントワークス収録時間: 16 分 ASIN: B004XES1G4

内容紹介人気アニメ「イナズマイレブン」の新シリーズ「イナズマイレブンGO」のエンディングテーマ！アイドル集団「ハロー！プロジェクト」を卒業した北原沙弥香が「空野葵」役を担当。アニメエ

ンディングを「空野葵」として歌う！

曲目リスト

やっぱ青春
ガムシャラ
やっぱ青春（オリジナル?カラオケ）
ガムシャラ（オリジナル?カラオケ）

320K下载地址

(115)http://115.com/lb/5lbbpzpy9qxl (baidu)http://pan.baidu.com/s/1bnw8PY3 (微盘)http://vdisk.weibo.com/s/APlR9kfmRJDO (360云盘)http://yunpan.cn/Q7c5qbwU8Te4x 提取码 7a60

ape下载地址：

(115)http://115.com/lb/5lbef0ft313s (baidu)http://pan.baidu.com/s/1jG3gnqu (微盘)http://vdisk.weibo.com/s/APlR9kfmRJwP (360云盘)http://yunpan.cn/Q7c5PHNdYVp4i 提取码 bcde

かなり纯情（第19话~第33话）（所属专辑：单曲专辑）

空野葵（北原沙彌香） - かなり纯情内容紹介爆熱超人気アニメ「イナズマイレブンＧＯ」新エンディングテーマ！声優『北原沙弥香』セカンドシングルリリーズ！ ●高視聴率を更新中！爆裂人気アニメ「イナズマイレブンＧＯ」！！Wii用ソフト、ニンテンドー

3DSソフトも続々発売、映画化も決定し、ますます注目を集める「イナズマイレブン」シリーズ！ ●この大人気アニメに「空野葵」声優役として出演中、北原沙弥香がセカンドシングルを発売”9月

7日よりオンエアとなるアニメ新エンディングテーマ「かなり純情」を空野葵(CV:北原沙弥香）として歌います！

【通常盤(初回仕様):CD＋イナズマイレブンGOカードゲームプロモカード1種封入】

曲目リスト

かなり純情
窓側から愛をこめて
かなり純情 (オリジナル?カラオケ)
窓側から愛をこめて (オリジナル?カラオケ)

320K下载地址

(115)http://115.com/lb/5lbc4q49sujb (baidu)http://pan.baidu.com/s/1pJHjj0f (微盘)http://vdisk.weibo.com/s/APlR9kfmRJqm (360云盘)http://yunpan.cn/Q7Vx38dSK35UL 提取码 0356

ape下载地址：

(115)http://115.com/lb/5lbbpzphnr4w (baidu)http://pan.baidu.com/s/1kTxE1yZ (微盘)http://vdisk.weibo.com/s/APlR9kfmRJT2 (360云盘)http://yunpan.cn/Q7c5SyTq8wiSq 提取码 1270

HAJIKE—YO!!（第34话~第45话）（所属专辑：单曲专辑）

空野葵（北原沙彌香） - HAJIKE—YO!! 発売日 2012/02/08 商品番号 PKCF-1066 JAN 4942463623166

内容空野葵(CV: 北原沙弥香)が歌う、アニメ『イナズマイレブンGO』エンディングテーマ、ニンテン

ドー3DS用ソフト『イナズマイレブンGO シャイン』エンディングテーマ! ニンテンドー3DS用ソフ

ト『イナズマイレブンGO ダーク』エンディングテーマ「爱情?情热?热风」、『剧场版イナズマイ

レブンGO 究极の绊グリフォン』挿入歌「梦のかたまり」も収录。初回限定盘は、PV+アニメエン

ディング映像を収录したDVD付き。

【アーティスト/ キャスト】

空野葵(CV.北原沙弥香)

【収录曲目】

1 [Disc 1] HAJIKE-YO!! 2 [Disc 1] 爱情?情热?热风 3 [Disc 1] 梦のかたまり 4 [Disc 1] HAJIKE-YO!! (オリジナル?カラオケ) 5 [Disc 1] 爱情?情热?热风 (オリジナル?カラオケ) 6 [Disc 2] HAJIKE-YO!! (ミュージックビデオ) 7 [Disc 2] HAJIKE-YO!! (アニメエンディング Ver.)

320K下载地址

(115)http://115.com/lb/5lbc4f8k7xm7 (baidu)http://pan.baidu.com/s/1hqvcL1a (微盘)http://vdisk.weibo.com/s/APlR9kfmRo_1 (360云盘)http://yunpan.cn/Q7c5S7yj8AIf8 提取码 b6d6

ape下载地址：

(115)http://115.com/lb/5lbbpyq43qqv (baidu)http://pan.baidu.com/s/1eQ1m1km (微盘)http://vdisk.weibo.com/s/APlR9kfmRokM (360云盘)http://yunpan.cn/Q7HJVygRZDYp3 提取码 af53

DVDISO下载地址

(115)http://115.com/lb/5lbc4f8rn0ab (baidu)http://pan.baidu.com/s/1pJJlbIV (微盘)http://vdisk.weibo.com/s/APlR9kfmRol7 (360云盘)http://yunpan.cn/Q7HJZSQPvJTh2 提取码 0c78

おはょう！ツヤィニング·ディ（第46话~第47话）（所属专辑：go1 op3专辑）

op3的后半部分，点击跳转

GO2 Chrono Stone

夏がやってくる（第1话~第18话）（所属专辑：单曲专辑）

空野葵 (CV: 北原沙弥香) - 夏がやってくる内容绍介テレビ东京系で放映中の大人気アニメ新シリーズ『イナズマイレブンGO クロノ?ストーン』(2012年4月18日放映スタート)でヒロイン空野葵役を务める声优、北原沙弥香

のシングル4枚目。アニメEDテーマ「夏がやってくる」を、空野葵として歌う作品。

収录曲

夏がやってくる
夏が终わっちゃう
夏がやってくる (オリジナル?カラオケ)
夏が终わっちゃう (オリジナル?カラオケ)

320K下载地址

(115)http://115.com/lb/5lbef0f3p5np (baidu)http://pan.baidu.com/s/1gd7qf8B (微盘)http://vdisk.weibo.com/s/APlR9kfmRJSE (360云盘)http://yunpan.cn/Q7c5RDJuUw3PC 提取码 ea4a

ape附dvdiso下载地址：

(115)http://115.com/lb/5lbbpzp85iju (baidu)http://pan.baidu.com/s/1qWEzqC8 (微盘)http://vdisk.weibo.com/s/APlR9kfmRoHz (360云盘)http://yunpan.cn/Q7HJVEniTpUHZ 提取码 4c86

手をつなごう（第19话~第35话）（所属专辑：单曲专辑）

下载地址

此专辑自购无损：https://blog.xingoxu.com/2015/04/self-copy-cd-inazuma-1-html/

仆たちの城（第36话~第39话，第41话、第43话~第46话、第48话~50话） / 青春おでん（第40话、第42话、第47话、第51话）（所属专辑：单曲专辑）

TVアニメイナズマイレブンGO クロノ?ストーン ED3、4 - 僕たちの城、青春おでん (数量限定生産) CD (2013/2/6) ディスク枚数: 1 フォーマット： Single, Limited Edition, Maxi レーベル: FRAME 収録時間: 20 分 ASIN: B00AI9HHPO EAN： 4988064550173

内容紹介爆裂大人気「イナズマイレブンGO クロノ?ストーン」新エンディングテーマ、新春に登場!!

高視聴率を更新中! 爆裂超人気アニメ「イナズマイレブンGO クロノ?ストーン」!! その人気アニメの新エンディングテーマを歌うのは誰か!? 今作も数量限定生産盤として、ここでしか手に入らないフィギュアストラップが付いてくる!!!

メディア掲載レビューほか「イナズマイレブンGOオールスターズ」による、テレビ東京系アニメ『イナズマイレブンGO クロ

ノ?ストーン』のエンディング?テーマを収録したシングル。

曲目リスト

僕たちの城
青春おでん
僕たちの城 (オリジナル?カラオケ)
青春おでん (オリジナル?カラオケ)

320K下载地址

(115)http://115.com/lb/5lbef0krad6v (baidu)http://pan.baidu.com/s/1dDGhCsD (微盘)http://vdisk.weibo.com/s/APlR9kfmRoHM (360云盘)http://yunpan.cn/Q7c5BI6mrpBsG 提取码 4eaf

ape下载地址：

(115)http://115.com/lb/5lbasp7vn9c4 (baidu)http://pan.baidu.com/s/1o6oeV9K (微盘)http://vdisk.weibo.com/s/APlR9kfmRoHK (360云盘)http://yunpan.cn/Q7HJjUQYLesxv 提取码 9fea

go3 Galaxy

胜手にシンデレラ（第1话~第17话）

COLORS - 勝手にシンデレラ発売日：2013/07/03 商品番号：AVCD-55016 JAN：4988064550166 メディア：CD

テレビ東京系アニメ『イナズマイレブンGO ギャラクシー』の新エンディング曲は、空野葵 (CV:

北原沙弥香)と森村好葉 (CV: 悠木碧)。なんとジャンルはヘビメタで、本物にこだわり、作曲と

ギターは世界的に活躍するギタリスト、マーティ?フリードマンが担当!!

収録曲

勝手にシンデレラ
ファンタジーが止まらない
（缺）勝手にシンデレラ (オリジナル?カラオケ)
（缺）ファンタジーが止まらない (オリジナル?カラオケ)

320K下载地址

(115)http://115.com/lb/5lbd23gfcm49 (baidu)http://pan.baidu.com/s/1qWLkQIw (微盘)http://vdisk.weibo.com/s/APlR9kfmRo7d (360云盘)http://yunpan.cn/Q7c56tkPvtbAM 提取码 4acb

ファッション☆宇宙戦士（第18话~第32话）

COLORS - ファッション☆宇宙戦士收录曲：

ファッション☆宇宙戦士
夸り高き我らはここにいる

320K下载地址

(115)http://115.com/lb/5lbasv6jf134 (baidu)http://pan.baidu.com/s/1i35khwT (微盘)http://vdisk.weibo.com/s/APlR9kfmRo72 (360云盘)http://yunpan.cn/Q7c5MLuRV5qF4 提取码 6081

岚?竜巻?ハリケーン（第33话~第42话）

320K下载地址

(115)http://115.com/lb/5lbasv6j0lmm (baidu)http://pan.baidu.com/s/1ntE5wk5 (微盘)http://vdisk.weibo.com/s/APlR9kfmRo7H (360云盘)http://yunpan.cn/Q7c5MbTuV3N5F 提取码 ef2c

完结曲本当にありがとう!（第43话）

是否出过专辑未知，但五周年纪念专辑包含

320K单曲自转上传 (115)http://115.com/lb/5lbbpg3jfztd (baidu)http://pan.baidu.com/s/1jG85S7G (微盘)http://vdisk.weibo.com/s/APlR9kfmRGfi (360云盘)http://yunpan.cn/Q7PxyxLJUDJtc （提取码：50f1）

原声OST

GO1

イナズマイレブンGO テレビアニメ熱血サントラ! 発売日 2012/04/11
商品番号 PKCF-1075 JAN 4942463623258

[内容] 人気アニメ「イナズマイレブンGO」の初となるオリジナルサウンドトラックがリリース! 現アニ

メOPテーマのT-Piston+KMC「おはよう! シャイニング?デイ」から、ヒロイン役声優として出演も

している北原沙弥香が歌うアニメEDテーマ「HAJIKE-YO!!」、そしてイナズマ大好き少年達にはす

っかりお馴染みの前OPテーマ、T-Piston+KMC「成せば成るのさ七色卵」など歴代のテーマソング

、さらにアニメの名場面で使用された代表的な楽曲をぎっしり収録したイナズマファンのマスト

アイテム! DVDには、アニメ映像をたっぷり収録!

【アーティスト/ キャスト】

T-Pistonz+KMC 空野葵(CV:北原沙弥香)

【収録曲目】

1 [Disc 1] 天までとどけっ! (アニメオープニングVer.) T-Pistonz+KMC
2 [Disc 1] やっぱ青春 (アニメエンディングVer.) 空野葵(CV:北原沙弥香)
3 [Disc 1] 成せば成るのさ七色卵 (アニメオープニングVer.) T-Pistonz+KMC
4 [Disc 1] かなり純情 (アニメエンディングVer.) 空野葵(CV:北原沙弥香)
5 [Disc 1] おはよう!シャイニング?デイ (アニメオープニングVer.) T-Pistonz+KMC
6 [Disc 1] HAJIKE-YO!! (アニメエンディングVer.) 空野葵(CV:北原沙弥香)
7 [Disc 1] 木枯らし荘の朝
8 [Disc 1] 雷門サッカー部～天馬と仲間たち～
9 [Disc 1] 友達
10 [Disc 1] 革命を起こせ!
11 [Disc 1] 不屈の闘志
12 [Disc 1] 憎悪の悲哀
13 [Disc 1] オレたちは負けない!
14 [Disc 1] 折れた志
15 [Disc 1] 神童の葛藤
16 [Disc 1] 聖帝
17 [Disc 1] フィフスセクターの猛威
18 [Disc 1] シード
19 [Disc 1] 新生雷門サッカー部
20 [Disc 1] 戦え!雷門サッカー部!!
21 [Disc 1] 消せない寂しさ
22 [Disc 1] 勝利を掴め!
23 [Disc 1] 友情
24 [Disc 1] 立ちはだかる壁
25 [Disc 1] 一触即発
26 [Disc 1] 敗北
27 [Disc 1] ホーリーロードを突き進め!
28 [Disc 1] 化身使い
29 [Disc 1] ゴールへ!
30 [Disc 1] 化身激突!
31 [Disc 1] 少年たちの決意
32 [Disc 1] デスソード
33 [Disc 1] 立ち上がれ!雷門イレブン
34 [Disc 1] 波状攻撃
35 [Disc 1] フィフスセクターの戦士たち
36 [Disc 1] 怒涛の必殺技攻撃
37 [Disc 1] 雷門覚醒
38 [Disc 1] 激突
39 [Disc 1] 千宮路の力

40 [Disc 2] 天までとどけっ! (アニメオープニングVer.) T-Pistonz+KMC
41 [Disc 2] やっぱ青春 (アニメエンディングVer.) 空野葵(CV:北原沙弥香)
42 [Disc 2] 成せば成るのさ七色卵 (アニメオープニングVer.) T-Pistonz+KMC
43 [Disc 2] かなり純情 (アニメエンディングVer.) 空野葵(CV:北原沙弥香)
44 [Disc 2] おはよう!シャイニング?デイ (アニメオープニングVer.) T-Pistonz+KMC
45 [Disc 2] HAJIKE-YO!! (アニメエンディングVer.) 空野葵(CV:北原沙弥香)

320K下载地址

(115)http://115.com/lb/5lbc41ciotj0 (baidu)http://pan.baidu.com/s/1dDhBGBn (微盘)http://vdisk.weibo.com/s/APlR9kfmRo7b (360云盘)http://yunpan.cn/Q7LEMSe7aJFBX （提取码：9e01）

ape下载地址

(115)http://115.com/lb/5lbd28j4mguu (baidu)http://pan.baidu.com/s/1nt3adZV (微盘)http://vdisk.weibo.com/s/APlR9kfmRo7n (360云盘)http://yunpan.cn/Q7LEkyBsv62gN （提取码：9599）

DVDISO已损坏因此不上传

GO2

イナズマイレブンGO クロノ?ストーン時空最強サントラベストセレクション

発売日 2013/03/20 商品番号 AVCD-55037 JAN 4988064550371

内容超人気アニメ「イナズマイレブン」シリーズ最新作「イナズマイレブンGO クロノ?ストーン」の

サウンドトラックが初登場! 超次元サッカーの世界を体験しよう!

【アーティスト/ キャスト】

T-Pistonz+KMC 北原沙弥香光田康典(音楽) 亀岡夏海(音楽)

【収録曲目】

感動共有! (アニメサイズ) T-Pistonz+KMC
初心をKEEP ON! (アニメサイズver.) T-Pistonz+KMC
ライメイ!ブルートレイン (アニメOPバージョン) T-Pistonz+KMC
僕たちの城 (アニメサイズver.) 松風天馬(CV:寺崎裕香)&剣城京介(CV:大原崇)&神童拓人(CV:斎賀みつき)&西園信助(CV:戸松遥)&霧野蘭丸(CV:小林ゆう)
青春おでん (アニメサイズver.) 空野葵(CV:北原沙弥香)&瀬戸水鳥(CV:美名)&山菜茜(CV:ゆりん)&菜花黄名子(CV:悠木碧)
イナズマTMキャラバン
プロトコル?オメガ
天馬の化身
時空の支配者
危機
未来から来た少年
パラレルワールド
未来からの刺客
大敵の弾圧
タクティクスAX3
邪悪なる明晰
尾張の国
合戦!闘志天生
クロノ?ストーン ?伝説のサッカー選手たち?
デッドフューチャートーナメント
幻惑の静笑
信じあえる仲間
少女の重責
エルドラド
正義と勇気の真価
城壁の戦い
テンマーズの攻撃
プロトコル?オメガ2.0
最後のサッカー
ジャンヌダルク
鼓舞の光
化身アームド!
決死の作戦
悪の巨大化身
進軍
テンマーズ結成!
記憶の彼方

320K下载地址

(115)http://115.com/lb/5lbbpt95gfl2 (baidu)http://pan.baidu.com/s/1bn1sAUN (微盘)http://vdisk.weibo.com/s/APlR9kfmRo6k (360云盘)http://yunpan.cn/Q7LEvV4hZ8LN6 （提取码：9b9b）

flac下载地址

(115)http://115.com/lb/5lbd2rb0pnk5 (baidu)http://pan.baidu.com/s/1o6I7he6 (微盘)http://vdisk.weibo.com/s/APlR9kfmRo6E (360云盘)http://yunpan.cn/Q7rjWNdBvJnJw （提取码：1dba）

GO3 OST（无TV长度op ed）

登録情報 CD (2014/2/26) ディスク枚数: 1 レーベル: エイベックス?エンタテインメント収録時間: 56 分 ASIN: B00H6ZCUYG EAN： 4988064550524

イナズマイレブンGO ギャラクシーの激闘の歴史がよみがえるサウンドトラックが発売! ★ポイン

ト★ 1シリーズ最新作のサウンドトラックが登場! テレビ東京系アニメ『イナズマイレブンGO ギャラクシー』のオリジナル?サウンドトラック。ア

ニメの激闘の歴史がよみがえる1枚。

Tracklist

イナズマジャパン代表選手!
キャプテン松風天馬
謎の男ポトムリ
希望のゴールへ向かって!
反転攻勢
心の憂色
消せない傷
ふざけ合うチームメイト
善と悪の抗争
不測の事態
侵略者
逆風下の旋律
決意と葛藤
ギャラクシーノーツ号宇宙へ
オズロックの陰謀
少女カトラ
ダークサイド
限界を超えて
気づかない想い
天馬とチームの絆
不思議な生物ピクシー
謎めいた生物
小さな希望
精霊へんげ
焦燥
ファラム?オービアス
闘いの旋律
勝利は我らに
本当の心意
全ての結末へ

320K下载地址

(115)http://115.com/lb/5lbefg4y5oyk (baidu)http://pan.baidu.com/s/1rRkp4 (微盘)http://vdisk.weibo.com/s/APlR9kfmRo6X (360云盘)http://yunpan.cn/Q7rjt2nbBhaZU （提取码：be14）

flac下载地址

(115)http://115.com/lb/5lbasx8vou36 (baidu)http://pan.baidu.com/s/1hqzM21m (微盘)http://vdisk.weibo.com/s/APlR9kfmRo6D (360云盘)http://yunpan.cn/Q7rjnJYQHNhUG （提取码：9ca8）

角色歌

GO1

イナズマイレブンGO キャラクターソングオリジナルアルバム

◆高視聴率を更新中!!爆裂超人気アニメ「イナズマイレブンGO」!!　Wii用ソフト、ニンテンドー

３DSソフトも続々発売、映畫も公開となり、ますます注目を集める「イナズマイレブン」シリー

ズ!! ２０１１年４月に発売された前作「イナズマイレブン　キャラクターソング　オリジナルアルバ

ム」は３万枚を超える大ヒット！今作も「イナズマイレブン」の中でも特に人気の高いキャラク

ター?聲優陣が結集！！【「イナズマイレブンGO」アニメ情報】毎週水曜日１９：００~熱血放送中!! テレビ東京系６局

ネット（テレビ東京、テレビ北海道、テレビ愛知、テレビ大阪、テレビせとうち、TVQ九州放送

<曲目>

雷門中学校校歌
そよかぜドリーム
放課後ケミストリー
だから絶対大丈夫
同じ夢を見てる
みんなのために
レジスタンス
明日のフィールド
本物の強さ
あの樹の下に集まろう!

320K下载地址

(115)http://115.com/lb/5lbefa1t9b3x (baidu)http://pan.baidu.com/s/1jGh13X8 (微盘)http://vdisk.weibo.com/s/APlR9kfmRo63 (360云盘)http://yunpan.cn/Q7LE8B4NNvgE3 （提取码：4707）

无损下载地址

(115)http://115.com/lb/5lbbpknskt0h (baidu)http://pan.baidu.com/s/1kT3Kkej (微盘)http://vdisk.weibo.com/s/APlR9kfmRq-b (360云盘)http://yunpan.cn/Q7LEEbRCfXVzJ （提取码：24f4）

『イナズマオールスターズ×TPK』キャラクターソングアルバム「マジで感謝!」

※※※※※※初回生产限定※※※※※※ 特典 ■ラジオ电视剧収录「イナズマイレブン」系列の人気角色総势15名によるオリジナルalbum! 松风天马(cv.寺崎裕香)、神童拓人(cv.斎贺みつき)、鬼道有人(cv.吉野裕行)、剣城京介(cv.大原崇)、円堂守(cv.竹内顺子)、豪炎寺修也(cv.野岛裕史)、吹雪士郎(cv.宫野真守

)、染冈竜吾(cv.加瀬康之)、西园信介(cv.戸松遥)、狩屋マサキ(cv.泰勇気)、雾野兰丸(cv.小林ゆう

)、フェイルーン(cv.木村亜希子)、瀬戸水鸟(cv.美名)、山菜茜(cv.ゆりん)、空野葵(cv.北原沙弥香

)、(顺不同です)など「イナズマイレブン」系列の人気角色総势15名によるオリジナルalbum!

初回盘のみ特典トラックとして7月7日にニコファーレで开催された「天の川までとどけ! イナズ

マイレブンGO七夕フェスティバル」で行われた「イナズマイレブンGO2クロノストーン/アナザーストーリー」生アフレコを初回限定

特典として収录!

【脚本:日野晃博出演:寺崎裕香(松风天马), 木村亜希子(フェイルーン), 大原崇(剣城京介), 斎贺みつき(神童拓人), 小林ゆう(雾野兰丸), 佐藤健辅(矢嶋阳介三国太一)

】

====================List====================

01 蒼き魂松風天馬（CV:寺崎裕香）＆神童拓人（CV:斎賀みつき）

02 さよなら過去の俺剣城京介（CV: 大原崇）＆狩屋マサキ（CV: 泰勇気）

03 明日のヒーロー豪炎寺修也（CV: 野島裕史）＆神童拓人（CV:斎賀みつき）

04 涙のArt　～虹色の花～霧野蘭丸（CV: 小林ゆう）＆フェイルーン（CV；木村亜希子）

05 恋のシュークリーム空野葵（ＣＶ:北原沙弥香)＆瀬戸水鳥（CV：美名）＆山菜茜（CV：ゆりん）

06 とどけっ！友情のエール西園信助（CV：戸松遥）＆狩屋マサキ（CV: 泰勇気）

07 炎のプライド豪炎寺修也（CV: 野島裕史）＆染岡竜吾（CV:加瀬康之）＆吹雪士郎（CV: 宮野真守）

08 好きだからっ！円堂守（CV: 竹内順子）＆鬼道有人（CV：吉野裕行）

09 手をつなごう松風天馬（ＣＶ:寺崎裕香）＆剣城京介（ＣＶ:大原崇）＆空野葵(ＣＶ:北原沙弥香)

10 眩しい未来Yeah!!! 円堂守（CV: 竹内順子）＆松風天馬（ＣＶ:寺崎裕香）

11 マジで感謝！from イナズマオールスターズ円堂守（CV: 竹内順子）＆染岡竜吾（CV:加瀬康之）＆松風天馬（ＣＶ:寺崎裕香）＆剣城京介（ＣＶ:大原崇）＆神童拓人（CV:斎賀みつき）

（ボーナストラック）＊初回生産限定盤のみ 12 オリジナルストーリー「イナズマイレブンGO クロノストーン特別編七夕の逆襲」脚本：日野晃博　出演：寺崎裕香（松風天馬）　木村亜希子（フェイルーン）　大原崇（剣城京

介）　斎賀みつき（神童拓人）小林ゆう（霧野蘭丸）　佐藤健輔（矢嶋陽介三国太一サスケ）谷山紀章（アルファ）

320K?下载地址

(115)http://115.com/lb/5lbasx8fcrc1 (baidu)http://pan.baidu.com/s/1jGih5hc (微盘)http://vdisk.weibo.com/s/APlR9kfmRq-H (360云盘)http://yunpan.cn/Q7PuNaeabABLm （提取码：b602）

GO2 Chrono Stone

イナズマイレブンGO クロノ?ストーンキャラクターソングオリジナルアルバム

(初回生産限定) CD (2013/2/27) ディスク枚数: 1 フォーマット： Limited Edition レーベル: FRAME 収録時間: 47 分 ASIN: B00AI9HHX6 EAN： 4988064550265

内容紹介イナズマイレブンGOクロノ?ストーンの人気キャラが集合! 夢のコラボ実現! まさに超次元サッカー!

テレビ東京系アニメ「イナズマイレブンGOクロノ?ストーン」、 12月1日公開の劇場版「イナズマイレブンGOvsダンボール戦機W」も絶好調! アニメのFRAMEから飛び出したキャラクターたちが集合!

どんなコラボが実現するのかっ?乞うご期待! だろ?

メディア掲載レビューほかテレビ東京系アニメ『イナズマイレブンGOクロノ?ストーン』から飛び出したキャラクターたちが

集合したキャラクター?ソング?アルバム。“夢のコラボ”が実現した作品。

曲目リスト

01.君だから。松風天馬（CV：寺崎裕香）&雨宮太陽（CV：江口拓也）

02.いつかの話三国太一（CV : 佐藤健輔）＆狩屋マサキ（CV : 泰勇気）

03.ヤサシイミライフェイ?ルーン (CV : 木村亜希子） & 菜花黄名子（CV : 悠木碧）

04.DO OUR BEST!! 浜野海士（CV：金野潤）&倉間典人（CV : 高垣彩陽）

05.青春おでん空野葵（CV：北原沙弥香）＆瀬戸水鳥（CV：美名）＆山菜茜(CV：ゆりん) ＆菜花黄名子（CV：悠木碧）

06.B.E.L.I.E.V. 霧野蘭丸（CV : 小林ゆう）

07.瞳の中にキミがいる空野葵（CV：北原沙弥香）

08.ココロJUMP!! 西園信助（CV : 戸松遥）＆影山輝（CV : 藤村歩）

09.勇気のハーモニー神童拓人（CV : 斎賀みつき）

10.僕たちの城松風天馬（CV：寺崎裕香）＆剣城京介（CV：大原崇）＆神童拓人(CV：斎賀みつき)＆西園信助（CV：戸松遙）＆霧野蘭丸（CV：小林ゆう）

11.手をつなごう -KMC MIX- (ボーナストラック)

320K下载地址

(115)http://115.com/lb/5lbbpknppymq (baidu)http://pan.baidu.com/s/1c0pfqPM (微盘)http://vdisk.weibo.com/s/APlR9kfmRq-c (360云盘)http://yunpan.cn/Q7rjnpLDtgXvX （提取码：695b）

无损下载地址

(115)http://115.com/lb/5lbc4y87imxb (baidu)http://pan.baidu.com/s/1i3yy71z (微盘)http://vdisk.weibo.com/s/APlR9kfmRq-7 (360云盘)http://yunpan.cn/Q7rjXinXdzHfb （提取码：f69f）

イナズマオールスターズ×TPKキャラクターソングアルバム「感動共有!」

CD (2013/8/14) ディスク枚数: 1 レーベル: FRAME 収録時間: 45 分 ASIN: B00D8SJ4QW EAN： 4988064550425

内容紹介歴代のイナイレブンシリーズからオールスターが集合! T-Pistonz+KMCの楽曲にのせて歌います!

あなたは「感動共有! 」に号泣必死です! 歴代のイナイレブンシリーズからオールスターが集合!

TPKの楽曲にのせて歌います! あなたは「感動共有! 」に号泣必死です! 昨年11月に発売された前

作を受けてのイナズマイレブンシリーズの全タイトルの人気キャラクターがTPK楽曲に乗せて歌う

第2弾! イナズマイレブン全シリーズのオールスターが一枚のアルバムに登場するのはこのアルバ

ムだけ! 大胆なコラボレーションが今回も実現するのかっ?! 期待度超次元! ★ポイント★ 1すべて

のイナズマイレブンシリーズからキャラクターを選抜。 2すべての楽曲をT-Pistonz+KMCが手がけ

ます。 3昨年11月発売の前作は、1万枚以上出荷している人気タイトルです。Disc-1 収録曲未定

※「感動共有! 」イナズマイレブンGO クロノ?ストーン』のアナザーオープニングテーマとして2

話目から18話目まで隔週でオンエアされた楽曲 →こちらをキャラクターソングとしてカバーする

ことが決定しております。

メディア掲載レビューほか TVアニメ『イナズマイレブン』シリーズから歴代の人気キャラクターがT-Pistonz+KMC楽曲に乗せ

て歌う第2弾アルバム。『イナズマイレブンGO クロノ?ストーン』のアナザー?オープニング?テー

マ「感動共有!」のキャラクター?ソング?カヴァー他を収録。 (C)RS

収録曲

恋のストラップ　瀬戸水鳥(CV.美名)&山菜茜(CV.ゆりん)
いい風が吹いてキター! 　松風天馬(CV.寺崎裕香)& フェイ·ルーン(CV.木村亜希子)
Don't Stop!!!! 　井吹宗正(CV.鈴木達央)
明日も晴れたら　空野葵(CV.北原沙弥香)&野咲さくら(CV.遠藤綾)
グレート魂　錦龍馬(CV.岩崎了)&ザナーク?アバロニク(CV.小西克幸)
友情の化身　雨宮太陽(CV.江口拓也)
ささやかな祈り　空野葵(CV.北原沙弥香)
となりにいるよっ　西園信助(CV.戸松遥)&三国太一(CV.佐藤健輔)
君が居れば　瞬木隼人(CV.石川界人)&鉄角真(CV.泰勇気)
三日月スマイル　円堂守(CV.竹内順子)&剣城京介(CV.大原崇)&神童拓人(CV:斎賀みつき)&霧野蘭丸(CV.小林ゆう)
感動共有!fromイナズマオールスターズ　松風天馬(CV:寺崎裕香)&神童拓人(CV.斎賀みつき)&井吹宗正(CV.鈴木達央)&鉄角真(CV.泰勇気) コーラス：空野葵(CV.北原沙弥香)&瀬戸水鳥(CV.美名)&山菜茜(CV.ゆりん)

320K下载地址

(115)http://115.com/lb/5lbasx8s76rm (baidu)http://pan.baidu.com/s/1qW18a1A (微盘)http://vdisk.weibo.com/s/APlR9kfmRo6M (360云盘)http://yunpan.cn/Q7rjbjL9qaqHk （提取码：89af）

无损下载地址

(115)http://115.com/lb/5lbd28jlr23x (baidu)http://pan.baidu.com/s/1bntlbYn (微盘)http://vdisk.weibo.com/s/APlR9kfmRo6b (360云盘)http://yunpan.cn/Q7rjbauhEWIXE （提取码：4406）

イナズマイレブンシリーズ 5周年记念「本当にありがとう」

[CD] イナズマイレブンシリーズ 5周年记念「本当にありがとう」イナズマオールスターズ商品番号 AVCD-55064 JAN 4988064550647 メディア CD 组枚数 2 価格 4095円(税込) 発売日 2014/02/19 アーティスト/ キャストイナズマオールスターズ商品说明イナズマイレブンシリーズ5周年特别企画「ベストイレブン国民投票」で発表される、ベストイレ

ブンのメンバーを中心に参加する「梦のキャラソンアルバム」が発売! 过去シリーズの人気キャ

ラソンを集めたディスク+新たに制作するキャラソンの2枚组CD。アナザージャケット仕様。収录曲【DISC-1】　メモリアルディスク

守ってみせる! 歌 : 円堂守 ( CV.竹内顺子 )
そよかぜドリーム歌 : 松风天马 ( CV.寺崎裕香 )
レジスタンス歌 : 鬼道有人 ( CV.吉野裕行 )
炎の理由歌 : 豪炎寺修也 ( CV.野岛裕史 )
グレート魂歌 : 锦龙马 ( CV.岩崎了 ) & ザナーク·アバロニク ( CV.小西克幸 )
炎のプライド歌 : 豪炎寺修也 ( CV.野岛裕史 ) & 染冈竜吾 ( CV.加瀬康之 ) & 吹雪士郎 ( CV.宫野真守 )
友情の化身歌 : 雨宫太阳 ( CV.江口拓也 )
ヤサシイミライ歌 : フェイ·ルーン ( CV.木村亜希子 ) & 菜花黄名子 ( CV.悠木碧 )
アイスロード歌 : 吹雪士郎 ( CV.宫野真守 )
マジで感谢! from イナズマオールスターズ歌 : 円堂守 ( CV.竹内顺子 ) & 染冈竜吾 ( CV.加瀬康之 ) & 松风天马 ( CV.寺崎裕香 ) & 剣城京介 ( CV.大原崇 ) & 神童拓人 ( CV.斎贺みつき ) 【DISC-2】　アニバーサリーディスク
またね···のキセツ歌 : 円堂守 ( CV.竹内顺子 ) & 豪炎寺修也 ( CV.野岛裕史 ) & 鬼道有人 ( CV.吉野裕行 ) & 风丸一郎太 ( CV.西墙由香 ) & 吹雪士郎 ( CV.宫野真守 ) & 松风天马 ( CV.寺崎裕香 ) & 神童拓人 ( CV.斎贺みつき ) & 狩屋マサキ ( CV.泰勇気 ) & 真名部阵一郎 ( CV.野岛裕史 )
CHAMPIONSHIP 歌 : 雾野兰丸 ( CV.小林ゆう )
选ばれし者たち歌 : 瞬木隼人 ( CV.石川界人 ) & 九坂隆二 ( CV.冈林史泰 ) & 皆帆和人 ( CV.代永翼 ) & 真名部阵一郎 ( CV.野岛裕史 ) & 鉄角真 ( CV.泰勇気 )
COOL HEAT 歌 : 神童拓人 ( CV.斎贺みつき ) & 井吹宗正 ( CV.铃木达央 )
流星ボーイ歌 : 木野秋 ( CV.折笠富美子 ) & 音无春奈 ( CV.佐々木日菜子 ) & 雷门夏未 ( CV.小林沙苗 )
FIELD OF LOVE 歌 : 空野葵 ( CV.北原沙弥香 )
手をつなごう歌 : 神童拓人 ( CV.斎贺みつき ) & 雾野兰丸 ( CV.小林ゆう ) & 瀬戸水鸟 ( CV.美名 )
雷门中学校　校歌歌 : 円堂守 ( CV.竹内顺子 ) & 壁山塀吾郎 ( CV.田野めぐみ ) & 松风天马 ( CV.寺崎裕香 ) & 剣城京介 ( CV.大原崇 ) & 西园信助 ( CV.戸松遥 ) & 狩屋マサキ ( CV.泰勇気 ) & 影山辉 ( CV.藤村歩 ) & 空野葵 ( CV.北原沙弥香 ) & 木野秋 ( CV.折笠富美子 ) & 音无春奈 ( CV.佐々木日菜子 ) & 雷门夏未 ( CV.小林沙苗 )
仆たちの城歌 : 松风天马 ( CV.寺崎裕香 ) & 剣城京介 ( CV.大原崇 ) & 神童拓人 ( CV.斎贺みつき ) & 西园信助 ( CV.戸松遥 ) & 雾野兰丸 ( CV.小林ゆう ) & 空野葵 ( CV.北原沙弥香 ) & 瀬戸水鸟 ( CV.美名 ) & 山菜茜 ( CV.ゆりん )
本当にありがとう! 歌 : 円堂守 ( CV.竹内顺子 ) & 松风天马 ( CV.寺崎裕香 )

320K下载地址

(115)http://115.com/lb/5lbbpknxjhlv (baidu)http://pan.baidu.com/s/1kT1InMB (微盘)http://vdisk.weibo.com/s/APlR9kfmRo6a (360云盘)http://yunpan.cn/Q7HJrGH8niZi4 提取码 24c3

无损下载地址

(115)http://115.com/lb/5lbasx8dywi1 (baidu)http://pan.baidu.com/s/1hqGb4Sc (微盘)http://vdisk.weibo.com/s/APlR9kfmRq-e (360云盘)http://yunpan.cn/Q7HJxmaA6sTZM 提取码 11fc

其他专辑

北原沙弥香 - 春のグラデーション（动画ED与游戏ED的完整曲整合）（无无损）

CD (2013/3/6) ディスク枚数: 1 レーベル: FRAME 収录时间: 45 分 ASIN: B00AU5R7X8 EAN： 4988064550296

内容绍介：テレビ东京系アニメ『イナズマイレブンGO』シリーズで人気のヒロイン役「空野葵」(北原沙弥香

)のファースト·アルバム。『イナズマイレブンGO』シリーズのエンディング曲に加え、ゲーム版

エンディング曲も収录したベスト·アルバム的な内容。

収录曲：

HAJIKE-YO!!
ガムシャラ
春のグラデーション
かなり纯情
梦のかたまり
夏が终わっちゃう
窓侧から爱をこめて
昨日の恋はどこ吹く风
やっぱ青春
爱情·情热·热风
夏がやってくる

320K下载地址

(115)http://115.com/lb/5lbd28jzrh8g (baidu)http://pan.baidu.com/s/1pJv40zh (微盘)http://vdisk.weibo.com/s/APlR9kfmRq-P (360云盘)http://yunpan.cn/Q7HJuJQd38csX 提取码 7b96

闪电十一人（动画）全op&ed音乐专辑整理

Sat, 26 Dec 2015 15:11:11 GMT

建议使用Ctrl+F迅速找到所在专辑有BK的尽量附上BK 该单曲要是有单曲专辑会在当前歌曲优先附上单曲专辑（一般来数单曲专辑是完整版歌曲，如果要寻TV版长度一般在原声集中）如无注明所有音乐最低品质320K，如果有无损会尽量附上所有歌曲的专辑皆以动画发布的歌曲专辑优先，歌手自己的专辑将不包括在这次整理中提示输入密码的话，所有密码均为：xingo 如果无法下载，又或者是因为疏忽编辑错误，又或者是发现了某资源的无损版本，请立刻在微博上@xingo 专辑来源来自互联网，非常感谢各位署名的不署名的分享！如果在这里找到自己的资源需要注明的话请与我联系我会立刻加上！

主题曲类

op类

立ち上がリーヨ（1话 - 26话）（所属专辑：单曲专辑、TV音乐精选集）

T-Pistonz - 立ちあがリーヨ

商品番号: PKCF-1001 メディア: マキシシングルCD 組枚数: 1 発売日: 2008/11/26 価格: 1050円(税込)

内容博多出身のロックバンド「豚骨ピストンズ」のメンバーを中心に「ラッキィ池田」などダンサーを含め結成された8人組パフォーマンスユニット "T-Pistonz" が歌う、TVアニメ「イナズマイレブン」のオープニングテーマ!

収録曲

立ち上がリーヨ
そばにおリーヨ
立ち上がリーヨ (Instrumental)
そばにおリーヨ (Instrumental)

下载地址

(115) http://115.com/lb/5lbbsb2ctdph (baidu) http://pan.baidu.com/s/1kTkhosn (微盘) http://vdisk.weibo.com/s/APlR9kfn2m-9 (360云盘) http://yunpan.cn/Q7sjkNRFQzXRp 提取码 3486

マジで感谢!（27话 - 54话）（所属专辑：单曲专辑、TV音乐精选集）

T-Pistonz & KMC - マジで感谢! 商品番號: PKCF-1010 メディア: マキシシングルCD 組枚數: 1 發賣日: 2009/06/10 價格: 1050圓(稅迂)

內容: 大人気TVアニメ「イナズマイレブン」の新オープニングテーマ!! 前作に引き続きT-Pistonzが担当、今作では福岡在住の人気ラッパー?KMCとのコラボ! KMCのクールなRAPと、トンニーノの熱いヴォーカルの異種格闘技が生み出した、新たな友情?愛情ソング。

收錄曲:

マジで感謝!
マジで感謝!～みんなでシャララversion～
マジで感謝!～KMC REMIX～
マジで感謝!(Instrumental)

下载地址

(115)http://115.com/lb/5lbbsb2mkanr (baidu)http://pan.baidu.com/s/1jGn7aOe (微盘)http://vdisk.weibo.com/s/APlR9kfn2m-4 (360云盘)http://yunpan.cn/Q7sjX9V8syRTx 提取码 7715

つながリーヨ（55话 - 67话）（所属专辑：单曲专辑、TV音乐精选集）

つながリーヨ/スゲーッマジで感謝!~スーパーファイア~ CD (2009/11/4) ディスク枚数: 2 フォーマット： Single, CD+DVD, Limited Edition, Maxi レーベル: FRAME 収録時間: 18 分 ASIN: B002M5P62S

つながリーヨ
スゲーッマジで感謝!~スーパーファイア~
つながリーヨ (オリジナル?カラオケ)
スゲーッマジで感謝!~スーパーファイア~ (オリジナル?カラオケ)

下载地址

(115)http://115.com/lb/5lbaf2mcclt4 (baidu)http://pan.baidu.com/s/1eQ5qhME (微盘)http://vdisk.weibo.com/s/APlR9kfn2m-e (360云盘)http://yunpan.cn/Q7sjaxCxjqJ4H 提取码 17f4

勝って泣こうゼッ!（68话 - 87话）（所属专辑：单曲专辑、TV音乐精选集）

登録情報

CD (2010/3/10)
ディスク枚数: 1
フォーマット： Single, Maxi
レーベル: FRAME
収録時間: 20 分
ASIN: B0031LSWBY

内容紹介パフォーマンス?ユニットのT-PistonzとラッパーのKMCによるユニットのシングル。テレビ東京系アニメ『イナズマイレブン』の主題歌で、心に響くご機嫌なナンバーとなっている。

曲目リスト

勝って泣こうゼッ!
友達でいようなっ
勝って泣こうゼッ! (オリジナル?カラオケ)
友達でいようなっ (オリジナル?カラオケ)

下载地址（192Kbps）

(115)http://115.com/lb/5lbcmwz5by4g (baidu)http://pan.baidu.com/s/1jG7POoQ (微盘)http://vdisk.weibo.com/s/APlR9kfn2m-5 (360云盘)http://yunpan.cn/Q7sj7FJZVntbF 提取码 888d

此专辑自购无损：https://blog.xingoxu.com/2015/04/self-copy-cd-inazuma-1-html/

GOODキター! （88话-107话）（所属专辑：单曲专辑、TV音乐精选集）

CD (2010/7/14) ディスク枚数: 2 フォーマット： Single, CD+DVD, Limited Edition, Maxi レーベル: FRAME 収録時間: 17 分 ASIN: B003I8WYPA

内容紹介

テレビ東京系アニメ『イナズマイレブン』と、ニンテンドーDS用ゲーム『イナズマイレブン3 世界への挑戦!! ボンバー』のオープニング?テーマを収録したシングル。歌唱は同シリーズの顔としておなじみとなったパフォーマンス?ユニット、T-Pistonzと男性ラッパー、KMC(ケムシ)が担当します!!

収録曲

GOODキター!
元気になリーヨ!
GOODキター! (オリジナル?カラオケ)
元気になリーヨ! (オリジナル?カラオケ)

下载地址（192Kbps）

(115)http://115.com/lb/5lbaf2mrn4gq (baidu)http://pan.baidu.com/s/1sjnYKZr (微盘)http://vdisk.weibo.com/s/APlR9kfn2m_O (360云盘)http://yunpan.cn/Q7sj7iTVbRvqi 提取码 2f58

此专辑自购无损：https://blog.xingoxu.com/2015/04/self-copy-cd-inazuma-1-html/

僕らのゴォール!（108话-127话）（所属专辑：单曲专辑）

T-Pistonz+KMC - 僕らのゴォール! 内容大人気アニメ「イナズマイレブン」の11月よりオンエアされていたあのオープニングテーマが遂に発売! カップリングには、イナズマオールスターズが歌うエンディングテーマ「またね???のキセツ」のT-Pistonz+KMCによるセルフカヴァーを収録。

收录曲目：

1 僕らのゴォール! 2 またね…のキセツ 3 僕らのゴォール!（オリジナル?カラオケ） 4 またね…のキセツ（オリジナル?カラオケ）

下载地址

(115)http://115.com/lb/5lbc4qg2agkf (baidu)http://pan.baidu.com/s/1c02CwAc (微盘)http://vdisk.weibo.com/s/APlR9kfn2m-4 (360云盘)http://yunpan.cn/Q7swgSEEk3ZH7 提取码 d992 (微云)http://url.cn/UzJV5P

ed类

青春おでん（1话 - 26话）（所属专辑：单曲专辑、TV音乐精选集）

twe'lv/青春おでん／純情青春ラブ [PKCF-1002] 商品番号: PKCF-1002 メディア: マキシシングルCD 発売日: 2008/10/29 価格: 1050円(税込)

アーティスト/ キャスト礼空トオル (作詞者)　青木隆 (作曲者)　高橋論一 (編曲者)　光田康典 (作曲者)

内容大ヒットゲーム「イナズマイレブン」に登場する春菜、夏未、秋の3人のヒロインが、ゲームからリアルな世界に飛び出してアイドルユニット"twe'lv"としてデビュー! テレビ東京系アニメ「イナズマイレブン」エンディングテーマとなるデビュー曲「青春おでん」は、「静岡おでんの会」応援ご当地ソングのカヴァー。カップリングにはカリスマゲームクリエーターであるレベルファイブ社長?日野晃博作詞、ゲーム音楽界の四天王と呼ばれる光田康典作曲による、ニンテンドーDSゲーム「イナズマイレブン」エンディングテーマ「純情青春ラブ」を収録。オリジナル?カラオケ付。

収録曲

青春おでん
純情青春ラブ
青春おでん(Instrumental)
純情青春ラブ(Instrumental)

下载地址

(115)http://115.com/lb/5lbafrk4dnnj (baidu)http://pan.baidu.com/s/1pJLmMN5 (微盘)http://vdisk.weibo.com/s/APlR9kfn2mrG (360云盘)http://yunpan.cn/Q7sjYHYA2Vn6T 提取码 19d8

青春バスガイド（27话 - 50话）（所属专辑：单曲专辑、TV音乐精选集）

TVアニメ「イナズマイレブン」ED2 - 青春バスガイド／Berryz工房商品番号: PKCP-5138 メディア: マキシシングルCD 組枚数: 2 発売日: 2009/06/03 価格: 1680円(税込)

内容 Berryz工房の記念すべき20枚目のシングルは、大人気アニメ「イナズマイレブン」のエンディングテーマ!! DVD(内容未定)付き限定盤。イベント抽選シリアルナンバーカード封入。

収録曲

青春バスガイド
ライバル
青春バスガイド(Instrumental)
ライバル(Instrumental)

下载地址

(115)http://115.com/lb/5lbcm6suhsmr (baidu)http://pan.baidu.com/s/1kT61SJd (微盘)http://vdisk.weibo.com/s/APlR9kfn2mkX (360云盘)http://yunpan.cn/Q7sjqPNMh8uRi 提取码 b388

流星ボーイ（51话 - 67话）（所属专辑：单曲专辑、TV音乐精选集）

Berryz工房 - 私の未来のだんな様 / 流星ボーイ[2009/11/11発売] 内容紹介２００９年１０月２８日発表の２１ｓｔシングル。ゲーム?ソフト『イナズマイレブン２　脅威の侵略者　ファイア』およびテレビ東京系アニメ『イナズマイレブン』エンディング?テーマとなった「流星ボーイ」ほかを収録。熱くファンキーな歌声を披露している。

収録曲

私の未来のだんな様
流星ボーイ
私の未来のだんな様 (Instrumental)
流星ボーイ (Instrumental)

下载地址

(115)http://115.com/lb/5lbafrk0opnj (baidu)http://pan.baidu.com/s/1eQvMFPg (微盘)http://vdisk.weibo.com/s/APlR9kfn2n1o (360云盘)http://yunpan.cn/Q7sjPVzZ3XJdN 提取码 6543

雄叫びボーイ WAO!（68话 - 87话）（所属专辑：单曲专辑、TV音乐精选集）

Berryz工房 - 雄叫びボーイ WAO! CD (2010/3/3) ディスク枚数: 1 フォーマット： Single, CD+DVD, Limited Edition, Maxi レーベル: ピッコロタウン収录时间: 15 分 ASIN: B0031LSWC8

ディスク：1

雄叫びボーイ WAO!
友达は友达なんだ!
雄叫びボーイ WAO! (Instrumental)
友达は友达なんだ! (Instrumental)

下载地址

(115)http://115.com/lb/5lbbsvicq5qv (baidu)http://pan.baidu.com/s/1gdraV8B (微盘)http://vdisk.weibo.com/s/APlR9kfn2mwI (360云盘)http://yunpan.cn/Q7sjPEYg3LwDR 提取码 58a4

本气ボンバー！！（88话 - 101话）（所属专辑：单曲专辑、TV音乐精选集）

Berryz工房 - 本气ボンバー！！価格：1,237円（税込、送料別）

収録曲

本気ボンバー!!
MOON POWER
本気ボンバー!! (Instrumental)

下载地址

(115)http://115.com/lb/5lbdyuctj69l (baidu)http://pan.baidu.com/s/1o68xEfK (微盘)http://vdisk.weibo.com/s/APlR9kfn2mQx (360云盘)http://yunpan.cn/Q7sjSVyRJmjSq 提取码 5293

シャイニングパワー（102话 - 112话）（所属专辑：单曲专辑、TV音乐精选集）

Berryz工房 - シャイニング　パワー

発売日：2010/11/10.品番/金額：CD＋DVD 【初回生産限定盤A】PKCP-5166～7/1,680円 CD＋DVD 【初回生産限定盤B】PKCP-5168～9/1,680円 CD 【初回生産限定盤C】PKCP-5170/1,050円 CD 【通常盤】PKCP-5171/1,050円 CD 【イナズマ盤】PKCP-5172/1,050円

シャイニングパワー
ちょっとさみしいな
シャイニングパワー(Instrumental)

下载地址

(115)http://115.com/lb/5lbewxd9xfmv (baidu)http://pan.baidu.com/s/1jGh1ycA (微盘)http://vdisk.weibo.com/s/APlR9kfn2m_Y (360云盘)http://yunpan.cn/Q7sjRAdcKfGqZ 提取码 4966

またね…のキセツ（113话 -127话）（所属专辑：单曲专辑、op6单曲专辑）

「イナズマイレブン」エンディングテーマ～「またね!」のキセツ/イナズマオールスターズ(円堂守(CV:竹内順子),豪炎寺修也(CV:野島裕史),鬼道有人(CV:吉野裕行),吹雪士郎(CV:宮野真守),風丸一郎太(CV:西墻由香)) [Single] [限定盤]

アーティスト竹内順子,野島裕史,吉野裕行,宮野真守,西墻由香レーベル FRAME JDC CD PKCF-1028 JAN CD 4942463622787 価格 ¥1600(税抜) 発売日 2011-02-16

初回生産限定盤／CD+DVD／同時発売通常商品はPKCF-1030

規格番号：PKCF-1028

特典?初回仕様について

「封入特典」以外の特典（ポスターなど）は、基本的にお付けしておりません。また、発売日以降のご注文では商品名に明記されている場合を除き「初回仕様」のご指定はできません。あらかじめご了承ください。

CDの内容：人気声優たちが集結し、｀イナズマオールスターズ｀を結成！人気アニメ『イナズマイレブン』エンディング?テーマ。　(C)RS

曲名リスト：

「またね！」のキセツ（イナズマオールスターズ）
最高で最强
「またね！」のキセツ（instrumental）
最高で最强（instrumental）

下载地址

(115)http://115.com/lb/5lbewxdx65lp (baidu)http://pan.baidu.com/s/1mgE7ukC (微盘)http://vdisk.weibo.com/s/APlR9kfn2mQl (360云盘)http://yunpan.cn/Q7sjMKVUdPYmM 提取码 a22d

此专辑自购无损：https://blog.xingoxu.com/2015/04/self-copy-cd-inazuma-1-html/

TV音乐精选集

本作有两个精选集，第二个因为是游戏及TV版背景音乐等没有资源，所以只能找到1。。

イナズマイレブン　ソングコレクション～超次元テーマソング集！1 登录情报

CD (2011/3/23) フォーマット： CD レーベル: アップフロントワークス収录时间: 46 分

曲目リスト

立ち上がリーヨ／T-Pistonz
青春おでん／twe'lv
マジで感谢！／T-Pistonz＋KMC
青春バスガイド／Berryz工房
つながリーヨ／T-Pistonz＋KMC
流星ボーイ／Berryz工房
胜って泣こうゼッ！／T-Pistonz＋KMC
雄叫びボーイ WAO! ／Berryz工房
GOODキター！／T-Pistonz＋KMC
本気ボンバー！！／Berryz工房
シャイニングパワー／Berryz工房

下载地址

(115)http://115.com/lb/5lbcmvxi844l (baidu)http://pan.baidu.com/s/1eQu0LPo (微盘)http://vdisk.weibo.com/s/APlR9kfn1VAE (360云盘)http://yunpan.cn/Q7fxAZxwF8kn2 提取码 8075

第二集的曲目列表在wiki上有就不附了：）

原声OST

イナズマイレブンテレビアニメ熱血サントラ! 第1巻

发售日:2009/09/23 CD碟数:1 发行公司:FRA 收录时间:01:04:53 JAN编号:4942463622626

曲目信息：

マジで感謝！
立ち上がリーヨ
青春バスガイド
青春おでん
雷門中学校（アニメＶｅｒ．）
雷門中学校　～円堂と仲間たち～
発動！バーニングフェーズ（アニメＶｅｒ．）
逆境（アニメＶｅｒ．）
伝説のイナズマイレブン
揺れる帝国
帝国学園のテーマ～帝国学園がやってきた！～（アニメＶｅｒ．）
帝国学園のテーマ～帝国学園がやってきた！～　デスゾーン
帝国学園との死闘（アニメＶｅｒ．）
行け！雷門中
公式戦（アニメＶｅｒ．）
サッカーバトル（アニメＶｅｒ．）
放課後の楽園（アニメＶｅｒ．）
１１の想い
謎（アニメＶｅｒ．）
忍び寄る雷鳴
黒き影～影山のテーマ～（アニメＶｅｒ．）
円陣（アニメＶｅｒ．）
やる気のない部員（アニメＶｅｒ．）
驚異の必殺技
バーニングフェーズ　スペシャル（ＬＥＶＥＬ５　ＶＩＳＩＯＮ　２００７　ＶＥＲＳＩＯＮ）
はじまり（アニメＶｅｒ．）
悲しい過去　ピアノバージョン
風と青春（アニメＶｅｒ．）
やろうぜ！サッカー
１分間の奇蹟
神々の聖戦（アニメＶｅｒ．）
聖地（アニメＶｅｒ．）

下载地址

(115)http://115.com/lb/5lbcmg88npfz (baidu)http://pan.baidu.com/s/1hqy02Jq (微盘)http://vdisk.weibo.com/s/APlR9kfn1VA2 (360云盘)http://yunpan.cn/Q7fxKKwj5DJsL 提取码 a449

イナズマイレブンテレビアニメ熱血サントラ! 第2巻

発売日 2010/05/26 商品番号 PKCF-1022 JAN 4942463622725 メディアアルバム CD 組枚数 2

少年たちに大人気のアニメ「イナズマイレブン」のサウンドトラック、第2弾! すっかりお馴染みの前OPテーマT-Pistonz「つながリーヨ」を始め、歴代テーマ曲、挿入歌など3曲、それに加えゲームでしか聴けなかった幻のED テーマ「あいつは太陽ボーイ! 」を初CD化。さらにアニメの名場面で使用された代表的な楽曲を20曲以上収録。オープニング映像、エンディング映像の他、ここでしか見られない貴重映像も満載のDVD付。

つながリーヨ/T-Pistonz +KMC
流星ボーイ/Berryz工房
スゲーッマジで感謝！～スーパーファイア～/T-Pistonz +KMC
イナズマキャラバン～最強の選手を探し求めて～
太陽に向かって
雷門中学校～夢と希望～
夕暮れの鉄塔
イナビカリファイター（アニメVer.）
葬られた希望
夏未お嬢様
ナニワランド
闘志
走るイナズマ
さらば豪炎寺修也
ピッチの轟き
悲しい過去（アニメVer.）
もう一人のエースストライカー
雷門の力
決死の攻撃
心の誓い
新監督　吉良瞳子
黒服の男
国家機関SPフィクサーズ
新人類　ザ?ジェネシス
対決！
黒いサッカーボール
ギャルズのテーマ
驚愕のエイリア学園
死闘～ジェミニストームとの決戦～
星の使徒
あいつは太陽ボーイ！/宮原永海

无损资源枯竭 [EAC] [100526] イナズマイレブンテレビアニメ熱血サントラ! 第2巻 (ape＋cue CDのみ)[100623].rar 430M http://tora.to/blog/420397.htm

下载地址

(115)http://115.com/lb/5lbafbm6zf2j (baidu)http://pan.baidu.com/s/1sjwgqAT (微盘)http://vdisk.weibo.com/s/APlR9kfn1VzQ (360云盘)http://yunpan.cn/Q7fx6fXBySHDB 提取码 c2d2

イナズマイレブンテレビアニメ熱血サントラ! 第3巻

メディア：　コンパクトディスク(12cm) ジャンル：　アニメーション,OVA等　発売日：　2011/06/22　　商品番号：　PKCF-1056 組数：　1 価格：　2300 円（税込） WEB価格：　2300 円（税込）　発売会社：　アップフロントワークスレーベル：　FRAME 販売会社：　キングレコード

コメント?特典：テレビ東京系アニメ『イナズマイレブン』のオリジナル?サントラ第3弾。T-Pistonz+KMCとBerryz工房のアッパーな歴代テーマ曲(TV尺)と、光田康典、亀岡夏海らが手がけた本格的なオーケストラ?サウンドの劇伴をたっぷり収録。闘志に火をつけてくれるようなとにかく勇壮に仕上げられた楽曲は秀逸。(キ) 初回仕様?特典物の記載のある商品につきまして初回仕様商品や初回特典付の商品のみ必要なお客様は、必ずお申し込み時に「通信欄」に「初回のみ希望」などとご記入の上、お申込み下さい。（特にポスターなど外付特典のあります場合は、特典内容を具体的にご記入下さい。）ただし、左の在庫状況表示が「お取り寄せ」「○-○日で発送」「発売日以降」表示になっています場合は、事前に入荷商品の仕様がわかりませんため、「初回仕様のみ」「特典付のみ」などのご指定がいただけません。通常商品でのお届けとなる場合がございます。

内容：

立ち上がリーヨ(アニメオープニングVer.)(T-Pistonz)
青春おでん(アニメエンディングVer.)(twe’lv)
マジで感謝!(アニメオープニングVer.)(T-Pistonz+KMC)
青春バスガイド(アニメエンディングVer.)(Berryz工房)
つながりーヨ(アニメオープニングVer.)(T-Pistonz+KMC)
流星ボーイ(アニメエンディングVer.)(Berryz工房)
勝って泣こうゼッ!(アニメオープニングVer.)(T-Pistonz+KMC)
雄叫びボーイWAO!(アニメエンディングVer.)(Berryz工房)
GOODキター!(アニメオープニングVer.)(T-Pistonz+KMC)
本気(マジ)ボンバー!!(アニメエンディングVer.)(Berryz工房)
シャイニングパワー(アニメエンディングVer.)(Berryz工房)
僕らのゴォール!(アニメオープニングVer.)(T-Pistonz+KMC)
またね…のキセツ(アニメエンディングVer.)(イナズマオールスターズ)
フットボールフロンティア?インターナショナル
それぞれのプライド
11の想い(Arrange Version)
砂の獅子
必殺タクティクス
雷門中の崩壊～衝撃の帰還～
研ぎ澄まされし聖者たち
燃え上がる爆炎
苦悩
さらば豪炎寺修也(Piano Version)
イプシロンの襲撃
フィールドの戦士
陰謀
カウンター
不落の要塞
究極奥義
不協和の気配
必殺技への挑戦
反撃ののろし
世界の強豪たち
ロスタイムの強攻
大陸の覇者
誕生
イナズマジャパン
さらば豪炎寺修也(Harmonica Version)
永遠の仲間たち
試合開始
みんなで行こうぜ!

320K下载地址：

(115)http://115.com/lb/5lbdy1bdexk5 (baidu)http://pan.baidu.com/s/1c0Il1mw (微盘)http://vdisk.weibo.com/s/APlR9kfn1Vzw (360云盘)http://yunpan.cn/Q7fx6CIdf5Pi5 提取码 f438

ape+cue下载地址（不带BK）

(115)http://115.com/lb/5lbcmv8laakf (baidu)http://pan.baidu.com/s/1i3j5uMp (微盘)http://vdisk.weibo.com/s/APlR9kfn1VzX (360云盘)http://yunpan.cn/Q7fxM6vtIVzHb 提取码 98ed

角色歌

価格 2500円(税込) 発売日 2011/04/06 商品番号 PKCF-1047 JAN 4942463622978 イナズマオールスターズ竹内順子(円堂守)野島裕史(豪炎寺修也)吉野裕行(鬼道有人)西墻由香(風丸一郎太)宮野真守(吹雪士郎)円堂守、壁山塀五郎&雷門中学校合唱部宮野真守竹内順子下野紘吉野裕行人気アニメ『イナズマイレブン』のキャラクターソングアルバム!! イナズマイレブンの中でも特に人気のあるキャラクター?声優によるキャラクターソングを収録。エンディングテーマ「またね???のキセツ」、『劇場版イナズマイレブン最強軍団オーガ襲来』の主題歌「最強で最高」のイナズマオールスターズによるカヴァーも収録! ジャケットには書き下ろしイラストを使用。

雷門中学校校歌円堂守、壁山塀五郎&雷門中学校合唱部
守ってみせる! 竹内順子
瞳の中の勝利吉野裕行
炎の理由野島裕史
Bad Boys Brother's Blues ～海と漢と侠とモヒカン～加瀬康之
舞いあがれ! 西墻由香
スターライン水島大宙
栄光へのエール! 下野紘
アイスロード宮野真守
最強で最高イナズマオールスターズ
またね…のキセツイナズマオールスターズ

下载地址

(115)http://115.com/lb/5lbbsa2fmwer (baidu)http://pan.baidu.com/s/1eQpHdC2 (微盘)http://vdisk.weibo.com/s/APlR9kfn1VzD (360云盘)http://yunpan.cn/Q7fx258zzuxVD 提取码 89eb

初识命令行git

Fri, 25 Dec 2015 21:50:12 GMT

git的教程很多，但很杂，留一篇自用吧

机遇

以前一直使用傻瓜式的SourceTree，然而今天（2015-12-1）升了级之后全部爆炸，完全push不上去，好吧，不得不感叹一下windows平台真的越来越像个定时炸弹（微软再这么玩真的。。。）在部署blog的时候也学习了git的一点点概念，所以上手挺快

0 安装

在windows平台上，git的客户端有很多，在这里我选择git for windows(以前是msysgit)

首先你得从他的官网(https://git-for-windows.github.io/)上下载下来

安装过程中没有什么需要配置的，如果看不懂，请自行学习英语这一门语言

安装后先打开git然后输入两条命令

git config --global user.name "user_test"
#git的全局设置，设置一次即可，这里设置用户名
git config --global user.email "user_test@user.test"
#git的全局设置，设置一次即可，这里设置邮件
git config --global push.default simple
#听说需要设置

1 初始化仓库

不管是远程已经有了仓库，还是自己家有仓库，首先在git里你都必须新建一个仓库，如果在文件夹下没有检测到.git文件夹，他就不会对这个文件夹有任何操作，such as pull or push

可以在任何你想建立仓库的父文件夹下右键git bash here(如果你没有在安装时去除这个钩钩的话)

进入后输入命令

mkdir 仓库名
cd 仓库名
git init

![git init][1] [1]: https://ooo.0o0.ooo/2017/05/25/5926482034f7a.png 你的仓库就初始化好了！

2 设置你的SSH Key

在与我们的github服务器进行交流前，我们要告诉他，我们是谁。在github中，我们可以用密码登陆，也可以用ssh key来操作仓库

如果你想使用其他方式与github服务器交流，请搜索其他文章，如果你已经初始化了ssh key，也请搜索其他文章如何关联

键入命令：

ssh-keygen -C '你的email' -t rsa

看清英文，一步一步，如果你需要设置密码，在途中自行输入，以后上传时都会要求输入密码，当然也可以不设置

3 pull and push

首先先将我们的仓库与远程仓库进行关联

 git remote add origin ssh地址

![ssh path][2] [2]: https://ooo.0o0.ooo/2017/05/25/592648208b7e8.png ssh地址都可以在github仓库页面上找到，以git@github.com:开头的，请将它们整个复制进去

操作完成后不会有任何提示

pull

git pull origin master

add

git add .

可以将当前所有文件加入push list(.git文件夹)

push

在push前，请记得打commit

git commit -m "commit注释"

git push -u origin master

目前还不明白 -u参数作用

4 What if I did wrong?

起因: 不小心把pixiv的账号密码一起传到了github上。。。

方法:

git reset --hard <commit_id>

git push origin HEAD --force

其他:

根据–soft –mixed –hard，会对working tree和index和HEAD进行重置:
git reset –mixed：此为默认方式，不带任何参数的git reset，即时这种方式，它回退到某个版本，只保留源码，回退commit和index信息
git reset –soft：回退到某个版本，只回退了commit的信息，不会恢复到index file一级。如果还要提交，直接commit即可
git reset –hard：彻底回退到某个版本，本地的源码也会变为上一个版本的内容


HEAD 最近一个提交
HEAD^ 上一次
<commit_id>  每次commit的SHA1值. 可以用git log 看到,也可以在页面上commit标签页里找到.

From： http://www.douban.com/note/189603387/

References:

如何在Markdown中显示链接中带括号的图片

hexo的备份与迁移

Fri, 25 Dec 2015 21:42:48 GMT

原虚拟机效率太低，决定重新装新的虚拟机只跑node.js+hexo，正好学习如何备份hexo元数据。

原则上来说，只需要备份post和主题文件夹，到新的环境下重新部署一下hexo就可以了，然而重新部署的过程中，在生成时发现，居然无法生成index.html了，也不知道是哪里出了问题，也不知道是不是插件出了问题，完全没地方下手啊，直接开搜（。

发现一个巨简单的方法，可忙这样的东西难道不是just work就ok的吗，你管他版本号要多新，想要版本号新了用新特性就再重新部署呗

原文来自：https://www.zhihu.com/question/21193762/answer/45552939 　　　　把整个hexo的文件夹打包即可换电脑的时候重新npm install就可以了~

使用后感受：这位小伙伴，你简直是天才！It works!

近况

Mon, 21 Dec 2015 22:57:16 GMT

很久时间没有写博客了，6月放假在外面忙活打工的事~~（为了还老妈的债）~~ ，9月去了北京和监督面了基，触动很大，便一直在学习与写作业，然后学校作业也是多的醉人，虽然没有任何技术含量然而还是很烦，主要是课程老师看完作品后就说，你再加个功能呗，我！终于有空了，然而却发现马上又要寒假了，自己还是什么经验和吹b的资本都没有_(:3」∠)_

按时间顺序留一些近况吧：

帝都面基

其实一开始没有什么动力去帝都，因为论展子，论城市化跟魔都差不多，去了没啥意思，然而母上说想去就去吧，车钱我贴你，我就厚颜无耻的去了，反正我又不出钱（。嘛去的那几天人不多，刚好是阅兵结束了，而且除了第二天下雨，其他几天都是很好的天气，很舒服。　　第二天和监督面触动比较大，白天各种聊天，晚上我突然想去他家看看，他说没问题，结果一到他家就发现沙发上一本docker，学习氛围各种啊！监督家还有很多很多很多很多很多好玩的东西，可惜我就坐了半小时，不开熏不开熏不开熏！！！！！早知道大家都宅不如窝在家里打一天3ds哈哈哈。　　第三天和肉排面基，去玩了圆明园啊看了又去中关村逛各种，感觉那两天过去不是玩的，是去聊天的233，但收获很大>.< 　　去北京的这几天的照片都在Google Photos上可以看见

C#/.NET学习

并没有很系统的学习，学校要教，我也没看书，就跟着vs的自动提示完成了老师的练习，感受就是IDE很强大，代码很爽，但是在界面控制上是非常累的，逻辑上就这个开，那个关的，非常累，到最后写大作业的时候就很吃力啊，对界面框架的不熟悉，写出来的东西就又臭又长，如果需求改了会非常累，所以最后那个下载器花了三个礼拜，做出来的效果自己感觉是一般的，因为本身引用的这个界面框架是非常厉害的。

Pixiv下载器

这个就是c#写的一个作业，从json api转换成我要的数据，多线程，还有http的8种交互，最后还有.net的绑定数据的超级简单，感觉这个东西让我见识到了很多，没有很系统的学习，也算是受益匪浅，有关pixiv下载器的功能与使用在这里。

开发心路：

关于多线程

子线程中的异常应当进行合适的处理，最好是返回给主线程进行处理，否则在只会在控制台中看到抛了异常然而主线程中却无法捕捉到任何异常。

关于数据绑定

在写程序的时候见识到了.net一些控件数据绑定的强大，然而有优点也有缺点，不知道是wpf还是界面框架开发者的疏忽，在进行数据绑定时，如果绑定的数据是引用类型的数组，此数组中剩余有元素没有进行初始化的话，CLR会抛出异常，然后抛出的提示却是“CLR遇到了一个问题，这个问题可能是CLR本身的问题”之类云云的，具体提示忘了。。。报的位置也不对，乱七八糟的，一会是这个线程，一会是那个无关的语句，还真以为是vs爆炸了，然后翻了之前的版本，发现不对呀是正常的，然后才发现是新加的feature导致开辟了数组却没有全部new，绑定的时候就爆炸了。

Surface Pro 4

监督的安利下购买了这款设备，唉想买个16g的太难买了，10月发布等了几乎快三个月，也是微醺啊！其实很想买mbp的，但是今年苹果没有出新款，然而的确是等着用一款便携式的设备（以前买的笔电太差了续航而且当时不懂买了个带显卡很好的，没用），而且还想顺便学学画画(?)~~听他放屁~~ 　　拿到手后，第一感受是，还不错，第二感受是，尼玛这系统做的太烂了，算了能操vs能操vmware能操多点任务就可以了，其他的就不要多折腾了。　　拿到手之后手贱拆了笔结果硬装上去大概装坏了，又是一个448再见！　　最心惊肉跳的是拿到手后的第三天，store打开异常，一直白的，刷了一下发现出墙的东西是正常的，以为是前两天搞了个Universal App出墙的东西坏掉了，然后就找网上去reset商店，结果找了个powershell的一个方法，一弄，商店彻底爆炸，图标不显示，变成了一串英文字母，{MSStorexxx这样子的，omg，心好累，想下恢复镜像，爬了半天下不下来，微软这个下载镜像不让断点续传还只能用浏览器自带还会自动断线是什么情况，让不让人玩了？？？？最后通过自带的恢复居然重装了系统，也是天了噜，这个功能微软你居然做了，还做了那么好。。。。。然后恢复之后键盘盖又爆炸了，驱动识别不出来，然后再一次恢复_(:3」∠)_，然后还是没有好，正当打算第二天去售后的时候，关了下机开机，好了，微软你可以爆炸嘛？

blog的新主题

从上次换了那个主题之后就一直耿耿于怀，那种设计感觉并不是我想要的那种感觉，一次逛v2的时候看到了这个主题，还不错，星期六的时候修改了一下，不知道看这篇文章的你喜欢吗

PixInTouch发布页面

Mon, 21 Dec 2015 13:42:54 GMT

作为一个花了三个礼拜稍微有那么点心思的~~其实花了很多想法，然而根本看不出这是一个花了心思的作品~~，还是给他开个页面用来发布吧！

需求：

.Net Framework 4.5 （windows xp不支持，windows 7/8用户如您不确定是否拥有这个环境，请您移步安装说明与使用）

功能：

按您关注的作者的新作品/您的收藏（公开/非公开）进行浏览作品
按您关注的作者（公开/非公开）的作品/收藏进行浏览作品
按pixiv官方榜单的呈现方式进行浏览作品
搜索某个关键词（以列表方式呈现不理想），以作者id浏览他的作品/收藏
浏览到的作品集中、批量下载（原图）
针对某幅作品的单独下载，漫画作品的挑页下载
集中的下载管理器
退出时的未下载完保存/手动保存未下载列表
自定义的背景图与颜色

注意：

针对动图的下载不够完善，移动端的api只能获取到600x600的动图帧，如果要下载原图，还是需要登录网页版手动爬图！请您知悉！

下载：

作为一个github的开源项目，该软体的源代码托管在这里，您可以时刻关注这个项目的最新发展及手动修改编译打造属于您自己的扒图器！
您也可以点击这里获得我为您编译的最新版本！

下载前的确认对话框的自定义显示
移除了一些我们完全不需要的文件

v0.9 beta3 given name

What's new?

下载前的确认对话框自选文件夹
扒图器的更名与添加图标

v0.9 beta2 little stabler?

What's new?

修复可能导致空列表的默认参数问题

v0.9 beta Acting Like a 5-year-old baby

What's new?

首次发布功能

安装使用与说明

本软体无需安装，直接打开pixiv_downloader.exe即可运行

windows 7/8用户如您不确定是否拥有.Net Framework 4.5的环境，请您按如下提示检查：开始菜单（Start）->搜索（Search）->控制面板（Control Panel）->程序与功能（Programs and Features）在程序与功能面板的右上角进行搜索：.net framework 如您发现类似于如下的提示，则您已经安装了4.5版本

如您发现并没有.Net Framework或是版本不足4.5，请您移步至：

如您有使用的问题，欢迎在下方进行留言，我会回复！

新的博客，新的自己

Wed, 16 Sep 2015 16:46:46 GMT

借着这个上学期期末误删的配置这学期开学重新配置以及同好好友给的力量，希望自己能够在这新的学期，努力多点一些技能树，望自己能成为更好的自己

话又说回来，以前最看不起java了，结果还是得学java，我倒是希望能赶紧自学google的go语言，不过还是先把java精了吧

另外，正如你所见，这里很多地方都正在under construction，所以注意不要点到什么奇怪的地方去了哦（根本没有233

重新搭建hexo的过程中，又被自己给笨到了，还是记一下部署hexo一定要使用旧版本（1.x）的msysgit，否则怎么deploy都上不去，气死了，老是说我密钥错误，换个git居然全好了，尼玛哦

参考：解决hexo一个奇怪的错误

自用下载： http://pan.baidu.com/s/1o6zP5CA http://yunpan.cn/cmherr5u6PsrM （提取码：46e7）

换新模板的过程中接触到了一些新的，比如swiftype这个玩意，不错

利用swiftype为hexo添加站内搜索v2.0 多说添加useragent

安卓4.4以上系统已root设备正确升级

Wed, 16 Sep 2015 16:39:38 GMT

原生root设备要是想要保留数据系统升级，一般都会选择线刷升级(直接刷入高版本system镜像等)，然而上次在逛g+时，却发现有人说这样升级非常不安全，一旦用户数据部分分区发生改变，直接刷入镜像启动后可能会发生假砖，导致最后得全新刷机，同时，这人也给出了一个非常安全的方法，看到后我觉得这样的方法非常可取，分享给大家

平刷当前版本的镜像，recovery system等，目的是为了去除root，保持system分区签名安全(如果安装了xposed框架，请先卸载在刷)
sideload OTA包，如果系统已经有了推送，下载好了ota，也可直接升级
enjoy the new system! 可以开始进行root操作等

详细的步骤就不完全写出来了，教程太多一抓一大把

Java学习笔记1

Tue, 15 Sep 2015 20:51:16 GMT

随便记的

部署与安装

三步：

下载并安装JDK
配置环境变量
测试

注意点：

环境变量有三：

JAVA_HOME 对应jdk根目录
PATH 对应jdk\bin目录
CLASSPATH 对应jdk\lib目录

使用IDE进行开发java程序

我选择eclipse

步骤：

创建java项目
创建程序包（一般为com.x）
创建源代码文件并编写
测试运行

变量与常量

注意点：

注意java中区分大小写，因此要注意大小写，关键字也要注意否则会编译错误

WNDR4300救砖（openwrt）

Tue, 15 Sep 2015 20:19:41 GMT

记一次作死把路由如何弄砖，又是如何救回来的过程

本教程适用于：

砖前为openwrt
救后为openwrt
因为刷了sysupgrade变砖的

其他情况本救砖方法不一定有效，请三思而尝试

怎么变砖

14.07大容量固件下用15.05官方升级包升级，变砖

尼玛，这个大容量固件是你们自己官方出的好伐！！！

下次再也不敢盲目尝鲜了！

救砖方法

救砖方法参考：http://blog.csdn.net/zhiyuan411/article/details/41399273

下载OpenWrt刷机包（要完整镜像，img的那种）：http://downloads.openwrt.org/
下载TFTP软件：http://www.wayos.cn/down/other/tftp.rar
把电脑用网线连在路由器，电脑改为固定IP：192.168.1.2，子网掩码：255.255.255.0，ip网关：192.168.1.1
WNDR4300用电源键断电
用细针等物件按住reset键不放（reset键在4300的底部，序列号的的最左侧，是个小圆孔，标有：restore factory settings）
按下4300电源键，通电
直到电源灯由黄色闪烁到绿色闪烁，松开reset
使用TFTP软件上传固件：路由器IP填192.168.1.1，密码留空，固件文件选择刚刚下载的OpenWrt刷机包那个img文件，点击“刷新固件”
等待TFTP软件显示绿色圆点，表示刷机成功。再等待几分钟，就可以看到电源键变绿，4300起来了。
此时，局域网已经支持DHCP，并可以通过 http://192.168.1.1 来进入luci管理平台，广域网口插入网线，设置后可以上网。

注：恢复后没有5G的配置项，解决办法：已经正常运行时，把4300断电，然后插电重启。就会看到5G的配置项。

最后再记

恢复后什么都没有了，要重头配置，在配置的过程中还发现了自己以前记录的一些问题

除了要安装那些包外，还要安装ip iptables-mod-tproxy这两个包
ss包从luci开发者的github界面进入，不要从其他地方进入，傲娇的很luci。。。记得选择spec优化版本（？）
ss更新过后luci界面开发者就将地址只支持数字ip了，不再支持域名了（明明人家windows客户端优秀的不行
尽管是2.3.2，但是新安装的（还是15.05的openwrt上）并没有看到UDP中继，然而ignore.list倒是要自己下载。。。
ignore.list下载方式在最下面

wget -O- 'http://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-latest' | awk -F\| '/CN\|ipv4/ { printf("%s/%d\n", $4, 32-log($5)/log(2)) }' > /etc/ignore.list

luci-ss界面关于不支持域名的issue：https://github.com/shadowsocks/openwrt-shadowsocks/issues/124

2015.05.12 C++继承

Tue, 12 May 2015 02:04:37 GMT

继承和组合是C++中比较重要的代码重用方式

继承与组合

通常，继承被看做是is-a，组合被看做是has-a 当我们不仅想重用内部实现而且还想重用接口的话，使用继承是最好的。

继承方法

C++内有三种继承方式：公有继承、私有继承、保护继承

公有继承

公有继承是把父类的公有和保护成员/函数保持原有状态进行继承

私有继承

私有继承是把父类的所有公有和保护成员/函数作为私有成员进行继承使用私有继承时，隐藏了父类的所有成员，能在子类中调用，完成部分功能。但既然已变成了私有，所有指针都不能指向此子类继承的成员，因此如果使用私有继承，在父类中有指针（虚函数）指向，则会提示“不允许对不可访问的基类进行转换” or “不可访问”

保护继承

保护继承是把父类的所有公有和保护成员/函数作为保护成员进行继承即：

	public	protected	private
公有继承	public	protected	不可见
私有继承	private	private	不可见
保护继承	protected	protected	不可见

C++中默认继承方式为private继承

向上类型转换

C++中允许向上类型转换，也就是，从一个专门的类型转换到一个更一般的类型，也就是从子类转换到父类，所以这样的类型转换也是安全的。对于这个转换唯一可能出现的事情就是它失去它专属的成员，而不是获得。

Thinking in C++ page.356

多父类继承

子类: 父类1,父类2的形式进行多父类继承对象的层次结构为，父类1，父类2，子类成员如果有同名成员/函数，无法直接调用，需要使用父类::成员来使用二义性适用于任何名字，包括函数名。二义性的产生见名字查找问题。

虚继承/虚基类

多父类继承时，如果一个子类继承的两个父类是从同一个父类中派生的，则在C++中会被认为成从两个同一个父类派生的，无法在子类中使用这个父类的函数or向上转换到这个父类，因为二义性，编译器并不知道是哪一个父类中的函数，即使他们是从同一个父类中派生的，因此使用virtual关键词来进行虚继承，否则编译器将报错。

Thinking in C++ page 810

名字查找问题

在同名的两个函数之间进行选择时，编译器将选择占优势的那个函数。如果没有占优势的名字，就会产生二义性。 人懒得要死代码都懒得抄了 多态与继承，有待更新

Reference

浅谈C++继承方式揭开私有继承的面纱 Thinking in C++ page 336-361

2015.05.09 C++多态

Sat, 09 May 2015 02:04:49 GMT

“调用’同名函数’却会因上下文不同会有不同的实现的一种机制” C++中的多态根据运行时机制的不同分为静态多态与动态多态，下面是静态多态与动态多态的主要实现方式。

静态多态

静态多态指的是基于模板的多态，对所有可能出现的情况，把所有代码全部写好，最关键的是，这些关联处理处于编译期而非运行期。常见的静态多态：函数多态，模板多态，宏多态。

函数多态/函数重载(overload)

不同参数，相同名字，返回值不看重即可对函数进行重载

class overload{
public:
	void overload_test(){
		cout << "This is a test function!" << endl;
	}
	void overload_test(int a){
		cout << "This is an overload function!" << endl;
	}
	int overload_test(double a){
		cout << "This is also an overload function!" << endl;
		return 0;
	}
};

模板多态/模板函数/函数模板

执行相同内容，只是参数类型不同，返回值也随着参数类型不同而改变，使用模板函数是最恰当的。模板函数要是欲对某一个不同的参数类型想进行不同的操作还可以使用模板特例。

class func_template{
public:
	template<typename X>
	X func_template_func(X a, X b){//function:return big one
		if (b>a) a = b;
		return a;
	}

	template<>//模板特例
	double func_template_func(double a, double b){
		cout << "This is a specfic template function" << endl;
		return 0;
	}

};

利用虚函数实现的多态

在父类中定义虚函数，在子类继承父类后对此函数进行覆盖，然后调用的时候一定要使用引用传递。虚函数与指针/引用传递传递一个不能少，虚函数与指针传递共同配合形成一个父类指针指向所需要的子类函数，如果缺了任意一个，即使通过编译，也仍然只会调用父类的虚函数内容。

要注意的是，子类继承时一定要使用public继承，否则编译会报错，不允许对不可访问的基类进行转换。因为指针并不能指向一个private对象，private对象也并不能向上转换（理解private的意义）

class father_class{
public:
	virtual void run(){
	};
	
};

class son_class :public father_class{
public:
	void run(){
		cout << "test" << endl;
	}

};



void output(father_class &a){
	a.run();
}

因为C++通过父类指针查找到子类函数，查找的过程，是在运行时完成的，所以这样的多态叫做动态多态。以上

代码中涉及到的一些其他，请参见：

待填充

Reference

C++多态 C++多态

2015.04.24 C++近期学习小结

Fri, 24 Apr 2015 02:05:32 GMT

函数参数传递，类的构造函数，类的可见性，类的继承都是一些碎片化的东西，做做笔记防止自己忘记

函数参数传递

只贴改过的代码了，其实程序和讲解这篇文章写得很棒，我就不当个复制粘贴的了

C/C++中函数参数传递详解

#include <cstdio>
#include <iostream>

using namespace std;

void swap1(int a, int b){	//value capture
	int temp = a;
	a = b;
	b = temp;
}

void swap2(int *a, int *b){ //pointer capture
	int temp = *a;
	*a = *b;
	*b = temp;	
}

void swap3(int *a, int *b){  //pointer capture another 
	int *temp;
	temp = a;
	a = b;
	b = temp;
}

void swap4(int &a, int &b){		//reference capture
	int temp;
	temp = a;
	a = b;
	b = temp;
}

void main(){
	int a = 1, b = 2;
	cout << "a=" << a << "\t" << "b=" << b << endl;
	swap1(a, b);
	cout << "值传递后:" << endl;
	cout << "a=" << a << "\t" << "b=" << b << endl;
	cout << "值传递只直接传递值，并不对原本实参有任何影响" << endl;
	cout << endl;
	cout << endl;
	cout << "a=" << a << "\t" << "b=" << b << endl;
	swap2(&a, &b);
	cout << "指针传递A后:" << endl;
	cout << "a=" << a << "\t" << "b=" << b << endl;
	cout << "对指针内容中进行交换，值变更" << endl;
	cout << endl;
	cout << endl;
	cout << "a=" << a << "\t" << "b=" << b << endl;
	swap3(&a, &b);
	cout << "指针传递B后:" << endl;
	cout << "a=" << a << "\t" << "b=" << b << endl;
	cout << "只对指针指向地址进行交换，而且也仅限于函数内的叫a,b的指针交换" << endl;
	cout << endl;
	cout << endl;
	cout << "a=" << a << "\t" << "b=" << b << endl;
	swap4(a, b);
	cout << "引用传递后:" << endl;
	cout << "a=" << a << "\t" << "b=" << b << endl;
	cout << "直接对变量进行操作" << endl;
	system("pause");
}

类的构造函数

默认构造函数

类的默认构造函数是一个与类名相同，参数为空的函数，当对象被创建时，将会自动调用类的默认构造函数。如果类没有定义默认构造函数时，编译器会自动给类创建一个函数体为空的默认构造函数。

重载/一般构造函数

可以为类自定义构造函数，构造函数名与类名相同，参数可以定义，当参数不为空时，则会对类的构造函数进行重载，在创建对象时，需要使用new语句，并输入参数，否则将使用默认构造函数。有参数的与类名相同的函数，称为重载构造函数，或一般构造函数。

类的可见性

public

public可见性可以在创建类对象的时候直接被对象调用，调用方法为object_name.variable/function

private

private可见性只能在本类定义中被使用，子类无法继承，对象无法直接调用

protected

protected可见性在无子类的情况下与private一致，有子类的情况下，能被子类继承，在子类定义中使用，但不能被子类的对象直接引用。子类继承的仍然是protected类型，也就是说能被子类的子类继承。

疑问

《C++ Primer》其中关于protected 成员的描述是这样的：

protected Members

The protected access label can be thought of as a blend of private and public :

Like private members, protected members are inaccessible to users of the class.

Like public members, the protected members are accessible to classes derived from this class.

In addition, protected has another important property: A derived object may access the protected members of its base class only through a derived object. The derived class has no special access to the protected members of base type objects.

奇怪的就是，难道是理解有误吗？明显protected就算被继承后也是protected类型，然而书上则说父类的protected成员只能通过子类的对象进行访问，然而即使是public成员，子类对象也无法直接访问父类的成员（如果已被覆盖），更何况是protected了，根本没法直接访问，通不过编译，不明白啊。

类的继承

子类继承父类，使用 derived_class_name:base_class_name进行继承，继承时，先执行父类默认构造函数，再执行子类构造函数。析构时，先析构子类构造函数，再析构父类析构函数。　　子类继承父类的public, protected成员函数与成员变量，继承下来的成员仍然是public与protected可见性的（public继承），子类可以对父类中的成员进行覆盖，在子类（对象）中优先调用子类成员。在子类定义中，即使成员已覆盖，也可以使用父类的成员，只需要在定义中使用father_class_name::member_name，就可以使用父类成员，但在子类对象中不能调用父类成员

类的操作的实现

#include <iostream>
using namespace std;

class father_class{

public:
	father_class(){//父类默认构造函数
		public_print();
		private_print();
		protected_print();
	}
	father_class(int a){//父类自定义构造函数
		cout << "father class constructed function overloaded." << endl;
	}
	int father_public_variable = 100;
	void public_print(){
		cout << "This is a public function." << endl;
	}
private:

	void private_print(){
		cout << "This is a private function." << endl;
	}
protected:
	int father_protected_variable = 2;
	void protected_print(){
		cout << "This is a protected function." << endl;
	}
};

class son_class :father_class{
public:
	son_class(){//子类默认构造函数
		public_print();
		//private_print();基类不可访问父类的private
		protected_print();		
	}
	int father_public_variable = 200;
	
	void public_print(){//覆盖父类中的public_print
		cout << "I'am son_public_print function." << endl;

		//print public variable
		cout << father_public_variable << endl;
		cout << father_class::father_public_variable << endl;
		
		father_protected_variable = 50;
		cout << father_protected_variable << endl;
		cout << father_class::father_protected_variable << endl;
	}
};

void main(){
	father_class father_object;
	cout << endl;
	cout << "father object created." << endl;
	cout << endl;
	father_class* father_object_2 = new father_class(0);
	cout << endl;
	son_class son_object;
	cout << endl;
	cout << "son object created." << endl;
	cout << endl;

	
	son_object.father_public_variable = 500;
	father_object.father_public_variable = 300;//不影响son_object
	//son_object.father_protected_variable = 10;子类对象不能对protected变量进行直接操作
	son_object.public_print();
	
	delete father_object_2;
	system("pause");
}

Reference

C/C++中函数参数传递详解 C++中protected的访问权限

两个Android Chrome的小坑

Wed, 22 Apr 2015 01:49:26 GMT

背景不支持fixed属性标题栏沉浸

背景不支持fixed属性

安卓浏览器/安卓Chrome中对于background已经移除了fixed属性

解决方法：

第一种：

对div进行fixed

第二种（适用于body background）：

html{
 height:100%;
 min-height:100%;
 }
body{
 min-height:100%;
 }

标题栏沉浸

支持Android 5.x下Chrome的标题栏沉浸颜色

header中加入以下代码，选个喜欢的颜色

<meta name="theme-color" content="#ffffff">

<link rel="icon" sizes="192x192" href="nice-highres.png">

Reference

支持Android 5.x下Chrome的标题栏沉浸颜色 background-size: cover not working in portrait on Android tablet

自抓 GOODキター!/ 勝って泣こうゼッ！/またね...のキセツ/手をつなごう无损下载

Tue, 21 Apr 2015 01:13:34 GMT

喜欢请购买正版，仅供试听学习用

解压密码：xingo

勝って泣こうゼッ！（初回限定版）

整轨下载：百度：http://pan.baidu.com/s/1sjJlAK9 360：http://yunpan.cn/cjeaFRNXRfFwK （提取码：e3fc）初回限定DVDiso下载：百度：http://pan.baidu.com/s/1hq5s8lQ 360：http://yunpan.cn/cjearCeBqRyMU （提取码：2902）

GOODキター!（初回限定）

整轨下载：百度：http://pan.baidu.com/s/1pJ9grIb 360：http://yunpan.cn/cjeaSigZun9Zj （提取码：1ca8）

初回限定DVDiso下载：百度：http://pan.baidu.com/s/1mgMfycC 360：http://yunpan.cn/cjeaBEQfMTazp （提取码：2085）

またね…のキセツ（初回限定）

整轨下载：百度：http://pan.baidu.com/s/1eQgsztg 360：http://yunpan.cn/cjeak2gANEvyI （提取码：1ad7）

初回限定DVDiso下载：百度：http://pan.baidu.com/s/1qW5cpQk 360：http://yunpan.cn/cjeavRVDIiKaN （提取码：c9a8）

手をつなごう

整轨下载：百度：http://pan.baidu.com/s/1jG3QLwy 360：http://yunpan.cn/cjea2X9IfV5ak （提取码：4764）

自用hexo+github pages搭建log

Fri, 17 Apr 2015 03:02:20 GMT

hexo+github pages 静态页面速度杠杠的

#环境

Node.js Git

GitHub Pages创建

很多种GitHub Pages，这次创建的是个人id顶级pages New repository，项目的名字就是username.github.io 其他选项不再详细赘述，比较简单

配置SSH Keys

（不知是否可以使用github自己客户端的git，自动生成ssh key，可以的话就跳过这步）现有ssh key check

$ cd ~/.ssh

No such file or directory 说明没有创建如果有，请删除，个人文件夹（C:/Users/username/）下的.ssh文件夹

生成新的SSH key

$ ssh-keygen -t rsa -C "邮件地址@youremail.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/your_user_directory/.ssh/id_rsa):

-C大写注意回车后系统要求输入密码，输入即可可以不设置

添加SSH key到GitHub

要把SSH key添加入GitHub才能正常pull/send requests

打开.ssh文件夹下的.pub文件，用notepad/notepad++等编辑器打开
登陆github，进入Account Settings -> SSH Public Keys -> add another public keys
把刚才的pub文件内容复制进key文本框中，点击add key

测试

输入以下命令：

$ ssh -T git@github.com

出现以下情况表示配置正确：

The authenticity of host 'github.com (207.97.227.239)' can't be established.
RSA key fingerprint is                                                    .
Are you sure you want to continue connecting (yes/no)?

输入yes

Hi xingoxu! You've successfully authenticated, but GitHub does not provide shell access.

完善个人信息

$ git config --global user.name "cnfeat"//用户名
$ git config --global user.email  "cnfeat@gmail.com"//填写自己的邮箱

配置成功

常见错误参考

GitHub Help - Generating SSH Keys GitHub Help - Error Permission denied (publickey)

开始使用hexo部署博客

安装hexo

$ npm install hexo-cli -g

部署hexo

找个地方新建个文件夹，右键git bash

$ hexo init

然后尝试执行

$ hexo g
$ hexo s

如果出现错误，尝试重新执行 npm install hexo-cli -g 成功后可以在浏览器中查看到localhost:4000

使用/调试

$ hexo s

$ hexo server

每次执行

$ hexo clean
$ hexo g
$ hexo deploy

deploy/d 是部署到github 但前提是首先我们要配置hexo

配置

首先安装

$ npm install hexo-deployer-git --save

否则不识别git上传方式

然后配置根目录下_config.yml

deploy:
type: git
repository: git@github.com:A-limon/alimon.github.com.git #此行内容可以在没有部署项目的项目首页找到，点击SSH
branch: master #为不同项目创建，参考其他资料

# Site #整站的基本信息
title:  #网站标题
subtitle: #网站副标题
description:  #网站描述
author:   #网站作者，在下方显示
email:  #联系邮箱
language: zh-CN


# URL
## If your site is put in a subdirectory
url: http://www.cnfeat.com #你的域名
root: /
permalink: :year/:month/:day/:title/
tag_dir: tags
archive_dir: archives
category_dir: categories
code_dir: downloads/code

这么多差不多就配置好了要注意的是hexo的配置文件，冒号后面一定要空一格空格，字符串后面也要空一格空格

安装主题

$ git clone https://github.com/wuchong/jacman.git themes/jacman

$ git clone https://github.com/A-limon/pacman.git themes/pacman

启用主题

_config.yml中

theme: jacman

更新主题

$ cd themes/jacman
$ git pull

注意备份主题_config.yml

安装插件

$ npm install <plugin-name> --save

安装sitemap与feed插件

$ npm install hexo-generator-sitemap --save
$ npm install hexo-generator-feed --save

修改_config.yml，增加以下内容

# Extensions
Plugins:
- hexo-generator-feed
- hexo-generator-sitemap

#Feed Atom
feed:
  type: atom
  path: atom.xml
  limit: 20

#sitemap
sitemap:
  path: sitemap.xml

主题中有相应部分也要做出修改

设置CNAME

在sources文件夹新建一个CNAME文件，内容是一行无空格一个CNAME域名这样做的目的是可以使hexo generate的时候把cname放进网站根目录下当github项目中的设置中这样显示的时候，证明设置成功

当你使用非cname，想使用A域名等，请看这里： Setting up a custom domain with GitHub Pages - User Documentation 最后不要忘记在你的ns服务商中设置cname哦

拾漏补遗&技巧

\scaffolds\post.md进行修改，可以更改默认发布模板例如：

title: {{ title }}
published: {{ date }}
tags: 
  - Uncategorized
description: 
---

pacman 主题启用公式高亮要在pacman的_config.yml中最后加入

highlight:
  enable: true

p.s.听说pacman还不支持3.0(?)

Reference

参见以下作者文章，感谢他们的努力！：

如何搭建一个独立博客——简明Github Pages与Hexo教程 Pacman主题介绍如何使用 Jacman 主题 Migration | Hexo Permalinks | Hexo

给github pages上ssl(hexo可用)

Fri, 17 Apr 2015 03:01:59 GMT

github pages已经支持https，可惜不支持自定义证书我们可以用cloudflare cdn加速，顺便还能上他新推出的flexible ssl

Getting Started

Sign up for Cloudflare if you don’t already have an account
Add your website, and make sure all automatically generated records match those on your registrar’s website

If you already have a gh-pages website and are simply moving to https, you don’t need to do anything else If not, and are trying to set up your site at apex, create an A record pointing to Github’s IP addresses, else a CNAME pointing to your-username.github.io Make sure there’s a CNAME file at the root of your gh-pages repo with your domain name

Go to your Domain Registrar’s website and change the Domain Name Servers to those Cloudflare provides you with
Finish Setting up your Domain on Cloudflare and go to the Domain Dashboard
Open the “Cloudflare Settings” for your domain, and change the SSL Setting to “Flexible SSL”

等待一个小时左右，Cloudflare就会为你的网站配上证书了

强制网页跳转https

在头代码中加入

<link rel="canonical" href="<%- page.permalink %>">
<script type="text/javascript">
       var host = "blog.xingoxu.com";
       if ((host == window.location.host) && (window.location.protocol != "https:"))
           window.location.protocol = "https";
</script>

Letting Search Engine know

Add these following in _config.yml:

url: https://www.yoursite.com   # with the https protocol
enforce_ssl: www.yoursite.com   # without any protocol

Caution

CloudFlare提供的SSL服务是基于SNI技术的，也就是说，机子上是IE8及以下用户完全无法打开（Chrome使用证书为系统，所以在win7下IE8的Chrome浏览器也是无法打开的，无论版本），注意了

Reference

Set Up SSL on Github Pages With Custom Domains for Free Variables | Hexo

Hello World

Mon, 06 Apr 2015 09:50:15 GMT

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

Quick Start

Create a new post

$ hexo new "My New Post"

More info: Writing

Run server

$ hexo server

More info: Server

Generate static files

$ hexo generate

More info: Generating

Deploy to remote sites

$ hexo deploy

More info: Deployment

openwrt 挂载硬盘以及迅雷下载

Tue, 03 Mar 2015 03:27:12 GMT

迅雷下载模块： http://www.right.com.cn/forum/thread-157967-1-1.html

luci界面： http://www.right.com.cn/forum/thread-135833-1-1.html

samba共享：

http://www.right.com.cn/forum/thread-151546-1-1.html

opkg update opkg install luci-app-samba

修改/etc/config/samba 增加以下内容：

config sambashare option ‘name’ ‘share’ option ‘path’ ‘/mnt’ option ‘read_only’ ‘no’ option ‘guest_ok’ ‘no’ option ‘create_mask’ ‘0700’ option ‘dir_mask’ ‘0700’

修改/etc/samba/smb.conf.template

guest ok = no invalid users = root

修改后执行命令： /etc/init.d/samba start

samba添加用户：

smbpasswd -a root 设置密码

挂载硬盘：

opkg install以下包

kmod-usb-storage kmod-usb-storage-extras 可选 block-mount kmod-fs-ext4 kmod-fs-ntfs 只读不可写

插入记得挂载，putty 命令 mount /dev/sda(x) /mnt/sda(x) 卸载umount /dev/sda(x)

迅雷离线教程： http://www.right.com.cn/forum/thread-115029-1-1.html https://chrome.google.com/webstore/detail/thunderlixianassistant/eehlmkfpnagoieibahhcghphdbjcdmen

自用WNDR4300搭建ss+chnroute满足需求

Mon, 02 Mar 2015 03:27:23 GMT

dnsmasq仍旧生效，效果很好

原文章来自：http://bilibi.li/2015/02/22/how-to-setup-shadowsocks-and-chinadns-in-openwrt-on-wndr4300/

https://cokebar.info/archives/664

原文已经基本阐述完整，就不再重复书写

Android 网卡（主机）显示名更改

Mon, 02 Mar 2015 01:45:17 GMT

逼格更高，路由器里显示手机名字2333333

使用R.E.管理器，找到/system/build.prop文件，使用文本编辑器打开，在最后一行添加下面一行内容：

net.hostname=yourname

重新启动手机
登录到无线路由，看看dhcp的客户端列表是不是已经变了。

注意！中间绝对不能有空格！可以有下划线和中横线

xingo

论垃圾佬的养成，一次 NAS 硬件升级与客厅电脑的升级的流水账

起因

背景以及第一代自组 NAS

硬件方案

软件方案

对第一代 NAS 方案的反思

掉盘后续

第二代 NAS 方案

硬件配置

软件配置

smfc

证书自动更新

直通

第 2.5 代 NAS 方案

p4 → dg1

dg1 → A380

附赠 算力机方案

后记

一些实用小链接

2026-02-05 随笔

升级 Jellyfin 到 10.9

TL;DR

尝试直接升级到 jellyfin/jellyfin 镜像

播放时不调用 GPU 加速，CPU 100%

中文字幕乱码

Extra 文件夹不显示

更换为 linuxserver/jellyfin 镜像

最后

2023 你的名字 飛騨高山 圣地巡礼

2024 年如何中间人 Android 网络请求

背景

apk-mitm

Frida

手机端准备工作

电脑端准备工作

启动脚本

References

聊聊管理番剧动画片这件事

jellyfin

插件

硬链

重命名

收拾 Extra

Episode-ReName

py-rename

Kodi

Jellyfin for Android TV

Jellyfin for Kodi

Findroid

参考

解决在 Ubuntu 24 中用 Docker 安装服务器端 Wireguard 的一个问题

背景

问题1 ip6tables 报错

问题2 客户端只能访问 IPv6 地址但无法访问 IPv4

太长不看

余谈

工作第7年，我从日本微信辞职了

7年之前我感觉自己中了头菜

跳槽

为什么干了6年都没有跳槽

那么为什么现在又打算跳槽了

LINE的这6年与我的这6年

将来的打算

用 Astro 翻新我的博客

为什么要写博客

为啥很久没有写博客了

Hexo 的问题

Astro

Waline

余留课题

Reference

wireguard + v6 双栈环境下构建 Transmission PT 做种客户端

背景

采用方案

原因

在 Docker 中安装 Transmission

问题 - 发现 PT 显示只有 IPv6 权限

解决

调整优先级让 IPv4 优先 IPv6

附赠算力机方案

2023 你的名字飛騨高山圣地巡礼

`require('./a.js') !== require('./A.js')`

`require('./a.js') !== require('./A.js')`

Node.js の解決 `async_hooks`