少女祈禱中...
Loading...
图片加载过慢?试试 从源站加载资源 X

ccloli

[AD] 网易云音乐社招内推

READ MORE →

Bilibili 1024 CTF 记录

6THX~65%RJ]74O2WR2FJ7NC

]V%LZ~ZKYNJP(~NI0U_]HE8

又名 679 事件

又名 679 事件

QQ截图20201025182510

1. 页面的背后是什么?

2. 真正的秘密只有特殊的设备才能看到

QQ截图20201024023016

READ MORE →

ロリ节存活报告

わたてん!

わたてん!

by 芦田伊知朗@ichirouf 2019-01-21 15:15:37 on pixiv

又到了惯例的「ロリの日」,虽然只剩最后一个小时了,而且这两天也并没有看点兔三期,不过还是来扯些和ロリ相关或者不相关的东西吧。

去年提到了购入了个 lolicon.icu 的米,毕竟当时注册价格才不到两刀,而且 icu 也算好记,既有萝莉控 ICU 病房的意思,又有 lolicon I see you 的意思,所以还算有点意思,也因此 loli.icu 直接被人抢注了 10 年。然而今年年初续费前收到了 Namesilo 即将自动续费域名的邮件,顺带登帐号上去看了下,发现续费价格居然涨了,不再是 2 刀了,而是 6 刀了。虽然其实还好,但是当时脑抽感觉被背刺了,于是就把自动续费的开关关了,想着反正之后域名放出再注册价格还是两刀。于是……如你所见,这个域名当然已经不是我的了,现在想想好像有点小亏,而且这域名比那个完全摸不着头脑的 uno 好记多了……不说了,血亏。

同样血亏的还有上个月忘了续费 loli.io 的 某人,等他发现的时候域名已经被挂在 park 页面上竞价了。顺带去围观了下,域名起价 99 刀。竞价嘛,肯定要高出域名价格的,不过考虑到 .io 域名本身就三十多刀,所以其实这个起价应该还好。park.io 的竞价周期是 10 天,而竞价嘛,肯定前几天没什么人起价,所以前几天域名基本就是在 100 刀这样。直到最后一天,价格竞价到了 1000 刀……

总之 loli.io 大概就这么没了,虽然不知道为什么 NAS 上的 CrystalDiskInfo 还是能用这个域名的邮箱发警告邮件,难道网易企业邮箱不会重复校验 MX 合法性?

查了下 MX 记录,也没数据,不过看这 DNS 信息,看来是被 Snowfom 拐走了(

不过现在想想,1000 刀是不是其实也还好,比如 Namesilo 里挂着的另一个 loli 域名竞价是这样的:

这么一想倒是有点担心之前瞎注册的 loli.uno 了,于是趁着近期域名到期续费时提前把 loli.uno 也续费了。顺带看了下近期 Namesilo 的域名价格,发现 .uno 现在注册费居然也只要 2 刀,血亏……虽然续费价格还是 18 刀。然而在订单页面结算时,发现这个域名居然被标记为了 Premium Domain,而且一次只能续费 1 年。啊这,NIC 这算趁火打劫吗???不过虽然是 Premium Domain 但是为什么价格居然还比标称价格便宜了,迷惑。

H7G1UF27$S36E03U{L{TMMX

总之大概就先这样吧,这又是没啥萝莉属性的存活报告,不如再塞张ロリ?

臭 DD,就这?


萌节存活报告

秋天的倒数第二份冰淇淋

秋天的最后一份倒数第二份冰淇淋

不知不觉又一年过去了呢,嗯,暂时没什么想说的,毕竟只是年常报平安罢了。

和过去差不多,浑浑噩噩又过去了一年,估计也早就离所谓「萌」的道路越来越远了吧。

先这样流水账吧,今晚来集点兔打个鸡血吧,明天再说些和「萝莉」相关的事好了(?

READ MORE →

通过 Verdaccio 自建 npm 仓库测试 npm 包

在开发会被其他项目依赖的 npm 包时,有时需要在其他项目下安装测试。为了方便测试,我们通常会将包本地安装或者发布到 npm 仓库下再安装。但是实际上前者会有很多 npm 处理依赖的坑,而后者即便可以用 canary 通道,某些精神洁癖的同学还是会不太乐意。

那么我们可以换种思路,为何我们不在本地自建一个 npm registry?这样可以随意发布测试,不会踩到本地安装 npm 的坑,还不会影响到线上包。Verdaccio 就是一个随开随用甚至无需配置的 npm 仓库,用户不需要自己搭建数据库,只需要一行指令即可在本地启动一个 npm 仓库。

太长不看版

READ MORE →

解决 QQ 8.x 下同步聊天记录时无法输入独立密码

TL;DR. 本地搭建一个转发 http 与 https 请求到 https 的代理服务器,并签发一个 *.qq.com*.vip.qq.com 的自签证书并信任,然后本地修改 hosts 将 proxy.vip.qq.comverify.qq.com 指向代理服务器即可

本着「又不是不能用」的原则,本地的软件基本不保持更新,所以本地 QQ 也保持在了 8.9.3 版本。

20200501001230

结果某一天作死开了个 QQ SVIP,再次登录时 QQ 提示需要输入独立密码同步信息,结果输入密码后点击确认,没有任何反应。

20200501000646

于是接下来就是喜闻乐见的作死环节了,为了尝试恢复同步消息,在 QQ 的设置里将「同步最近消息到本地」的勾选框取消了。结果重新勾选的时候,弹出了需要输入独立密码,同样无法输入,甚至还无法改变聊天记录同步时间,提示服务器超时。

20200501000951

估计是 API 服务器不兼容旧版 QQ 了,于是在虚拟机上装了个最新的 QQ,结果大片的空白和间距感觉要吐了,老年人审美决定还是不升级了,于是问题回到了怎么折腾 8.x 上的独立密码的问题,唯一的收获是在新版 QQ 上是没问题的。顺带查了下版本号才发现原来 8.9.6 就是 8 的最后一个版本。

READ MORE →

名为年度总结的季度存活报告

6CWS1C_5$5CLBG1PZFU~QU

hi,好久不见,不知还有多少人记得这里。其实说是年度总结,倒不如说是年末总结,毕竟前几个月已经基本忘得一干二净了,那么就权当是季度总结了。

败了个显示器

10 月末的时候入手了个显示器作为外接屏幕(虽然其实可能并不用得上),主要看的是几个廉价 4K 显示器,虽然 Windows 的高分辨率即便在 Windows 10 下还是比较屎。最终确定了两个型号,一个是三星的 U32J590UQC,一个是优派的 VX2780-4K-3。二手东上在最优惠时的价格差不多,而三星的价格一般会更高一些,再加上也没体验过 VA 的效果,所以决定先试试看三星。

三星的这个显示器是 32 寸的 VA 面板,上市时间是 2017 年,据说当年在某外媒被列入了最佳 4K 游戏显示器之一,因为相比较之下是最便宜的 4K 显示器还有完整的 FreeSync 支持。从 displayspecifications 上看,使用的是 群创的 VA 面板,最大 60Hz 带完整 FreeSync,亮度标称大约有 270 nit,8 bit FRC 抖 10 bit。由于是 VA 所以拥有较高的 3000:1 静态对比度,虽然亮度比较低,但是由于静态对比度比较高,所以在低亮度场景下可以看到更深的层次(此处存疑,也有说这与对比度无关,而与面板本身的色深有关)以及更艳丽的场景(此处同样存疑,这有可能是显示器出场校准偏色,至少从 RTINGS 的评测来看色准不行,实际也是如此,画面整体偏红)。而且对于 4K 来说,32 寸刚好是个比较良好的尺寸,像素密度大概和 1080P 的 15.6 寸笔记本屏幕差不多,所以其实是个挺不错的显示器。

实际到手使用的时候,发现色彩确实非常艳丽,观感效果也非常棒,检查了一下也没什么问题。但是问题也就出现在艳丽上,整个画面明显偏红,而且有些红的不自然。而且由于屏幕比较大,在一下子看不了整个屏幕的情况下是有 VA 自带的泛白偏色的。虽然比垃圾 TN 的上下反色好很多,可视角度也好不少,不过如果注意到的话还是会有点奇怪,大概就像下面这样。

不过偏色和泛白其实还好,熟悉两三天后就习惯了,所以其实不算什么大问题,毕竟人眼更喜欢艳丽的色彩,哪怕不真实(校色?不存在的),而且泛白至少比 TN 的偏色好。低亮度下(< 30%)是 PWM 调光,所以在高帧率拍摄下是能看到摩尔纹的(顺带一提居然还是红色的摩尔纹),不过其实一般不会调低亮度(况且亮度本身就比较低),所以也可以忽略不计,毕竟大学 4 年用的 Acer E5-572G 就是垃圾 TN 屏 + PWM 调光。 但是这回就到这个显示器最大的问题了,亮度不够。虽然 VA 在全黑或者暗画面下效果非常出色,但是在屏幕全白时亮度明显比不过 G3 笔记本自带的 300nit 屏幕。而且在之前提到的评测网站 RTINGS 上,测试人员测试出来的屏幕亮度居然其实只有 200nit 左右……未免也太寒酸了。在尝试游玩 ~~盗版的~~ 莱莎与炼金工房时,使用 OBS 复制画面到笔记本屏幕,虽然感觉显示器的色彩非常饱满,但是也明显感觉在较高的亮度下笔记本的视觉效果反而更好,谁让 HDR 是趋势呢。

IMG_20191030_233823

IMG_20191028_223449

最后折腾了三天,还是再在二手东上购入了优派的 VX2780-4K-3 做对比,~~毕竟京东 7 天无理由退货呢~~。

显示器到手明显感觉 27 寸比 32 寸小了一圈,像素密度比 14 寸的 1080P 屏幕还要高。而且虽然这款显示器之前爆出使用的是 LG 的面板,而且在京东商品页和官网的参数是 IPS 的 1300:1 对比度,在屏库网上这个对比度也只对应上了 LG 的面板。但是其实从京东评论区的反馈来看,这款 LG 面板后来爆出了四角泛红的雷,所以这个系列的新产品,包括 LG 自己的低端 4K 显示器都换成了京东方的面板(京东评论里还有人晒出了工厂模式的图),自然对比度也变成了垃圾 IPS 的 1000:1,~~不知道是不是能告欺诈消费者~~。最后到手进入工厂模式,果然是京东方的面板,不知没有泛红但是对比度不高算是好还是坏。不过除此之外其他的参数没什么问题,典型亮度标称 350nit,比三星的那个 VA 不知高到了哪里去。其他的参数倒是有细微差别,虽然是 8bit 抖 10bit,但是是全程 DC 调光,最大 60Hz 但没有 FreeSync(不过 N 卡也不支持在 HDMI 2.0 下运行 G-Sync 兼容),而且 IPS 也没有 VA 的泛白问题,还附带了一个比较鸡肋的 HDR10……额,350nit 的 HDR 能好到哪去,HDR400 都达不到,而且这个菜单未免也太简陋了……

20191101_231532

20191101_203303

实际上机测试,会发现高亮度下带来的视觉效果真的好太多了,如果莱莎里正午的光照在优派的显示器上作为参照的话,三星的显示效果就像午后太阳开始偏西一样。但是在较暗的图片下(比如使用了 Bing 首页的各类背景图做对比),会发现 VA 的暗部细节比 IPS 好不少,毕竟 IPS 漏光比较可怕,画面全黑的时候屏幕还是比较亮的,这也算是 IPS 通病了,如果在暗室使用对亮度也没要求,VA 无疑是更好的选择。

IMG_20191101_224609

IMG_20191101_220416

IMG_20191101_215731

IMG_20191101_215229

当然 VA 最大的问题就是黑白电平转换过慢,在 testufo 的文字滚动测试下,VA 有更明显的视觉残留,而提升响应时间而引入的 overdrive 又让画面出现了过载虚影,显示的效果反而更糟糕了。相比较之下 IPS 只需要较低的 overdrive 就能达到不错的显示效果。

不过最后就是真正纠结的地方了,为了测试游戏的效果选择了使用巫师 3 来测试游戏画面,结果发现巫师 3 其实非常适合用来测试屏幕素质。巫师 3 的里可以方便的控制日夜转换,因此可以测试显示器在高亮度画面和低亮度画面下的显示效果,而且血与酒 DLC 里的新地图是一个非常好的测试环境,因为游戏画面里的景色拥有非常高的对比度,可以直观的看到显示器本身的色彩素质。结果也正如之前说的那样,三星的 VA 面板可以看得到非常艳丽的色彩,再加上 32 寸的屏幕,色彩效果很有冲击感。但是问题还是出在低亮度上,和优派的 IPS 对比,画面就像有一层遮罩,尤其是在白天使用猫头鹰魔药时,优派的 IPS 屏幕相比较之下更白更刺眼(真实闪瞎),而三星的 VA 面板看起来明显不够亮,白光的区域反而显得看着像灰色。但是 VA 在暗景下还是有优势的,暗景下屏幕本身就比较黑效果自然也更好,而且在游戏黑夜里骑马奔跑时 VA 的高对比度(也有可能是响应时间过慢)使得屏幕能更清晰地展示远景的轮廓。

总之……两者还是难分伯仲,两者都有各自的优点,VA 相比之下优点更多缺点也更多,但是抛开这些不谈,两者的屏幕素质都非常不错……最后考虑了很久,还是选择了优派的 IPS 屏幕……啊,要是有同时结合两者的优势的屏幕(包括便宜)该多好……

350nit 真亮!(?

350nit 真亮!(?

READ MORE →

从 Fetch 到 Streams —— 以流的角度处理网络请求

Title image of Streams API by Mozilla Contributors is licensed under CC-BY-SA 2.5.

Title image of Streams API by Mozilla Contributors is licensed under CC-BY-SA 2.5.

此文章的略微润色版可前往 知乎掘金SegmentFault专栏 查看

在服务端开发中,流是一个很常见的概念。有了流我们就不再需要等待整个数据获取完毕后才处理数据,而是可以一段一段地拿到数据,在获得数据的同时直接解析数据。这样既可以高效利用 CPU 等资源,还减少了存放整个数据的内存占用。不过在过去,客户端 JavaScript 上都没有流的概念,而随着 Streams API 在各大浏览器上的逐步实现,我们终于可以使用原生的 API 以流的角度来看待数据了,例如从 fetch 请求上可以得到一个网络流。

既然标题是「从 Fetch 到 Streams」,那么首先让我们来看看既熟悉又陌生的 Fetch API。相比较于 XMLHttpRequestfetch() 的写法简单又直观,只要在发起请求时直接将整个配置项传入就可以了。fetch() 方法接受一个 Request 实例,或者是大家更常使用的方法——传入需要请求的 URL 以及一个可选的初始化配置项对象,然后就可以从 Promise 中取得返回的数据:

如果你不喜欢 Promise 的链式调用的话,还可以用 async/await

看起来相当的直观,在请求时直接将所有的参数传入 fetch() 方法即可,甚至相较于 XHR 还提供了更多的控制参数,例如是否携带 Cookie、是否需要手动跳转等;取出数据也只需要调用 Response 对象上的方法就能拿到格式化的数据(例如 res.json())。而直接使用 XMLHttpRequest 看起来就没那么方便了,初始化时既有方法的调用又有参数的赋值,看着还挺混乱的:

而随着 AbortControllerAbortSignal 在各大浏览器上完整实现,Fetch API 也能像 XHR 那样中断一个请求了,只是稍微绕了一点。通过创建一个 AbortController 实例,我们就得到了一个可以控制中断的控制器。这个实例的 signal 参数提供了一个 AbortSignal 实例,还提供了一个 abort() 方法用于发送中断信号。我们将 signal 传递进 fetch() 的初始化参数中,就可以在 fetch 请求之外控制请求的中断了:

只可惜提出这个解决方案并实装的时间还是有点晚,Fetch API 早在 就在 Firefox 上实现,并且最早于 在 Chrome 上实装。而该功能最早也是 Edge 浏览器在 2017 年 4 月实现,Safari 直到 2018 年末才被发现 AbortController 不能中断请求的 bug,最后在 2019 年 3 月的 Safari 12.1 中才正式解决。算下来从 Fetch API 在浏览器上实装开始,到主流现代浏览器全部支持,跨越了整整四年。

Image of AbortController & AbortSignal Support Table by caniuse.com is licensed under CC-BY 4.0.

Image of AbortController & AbortSignal Support Table by caniuse.com is licensed under CC-BY 4.0.

晚归晚,但是看起来现在的 Fetch API 已经无所不能了,不过在「真香」之前,我们来考虑一个很常见的场景:浏览器需要异步请求一个比较大的文件,由于可能比较耗时,希望在下载文件时展示文件的下载进度。XHR 提供了很多的事件,其中就包括了传输进度的 onprogress 事件,所以使用 XHR 可以很方便地实现这个功能:

但是 Fetch API 呢?你打开了 MDN,仔细地看了 fetch() 方法的所有参数,都没有找到类似 progress 这样的参数,毕竟 Fetch API 并没有什么回调事件。难道 Fetch API 就不能实现这么简单的功能吗?这里就要提到和它相关的 Streams API 了——不是 Web Socket,也不是 Media Stream,更不是只能在 Node.js 上使用的 Stream,不过和它很像。

READ MORE →

萝莉节存活报告

嗯,今天也还活着,不过倒也没什么想说的。

要说和今天相关的事情的话,其实,除了 xn--eekf.xn--q9jyb4c 这个域名以外,在半年前还买了个 loli.uno。当然,买了并不代表用上了,所以暂时就重定向到 xn--eekf.xn--q9jyb4c 上了。结果大概上个月的时候 IP 被墙了,所以其实你们现在直接连接也访问不了了。

smokeping-cloudcone

smokeping-cloudcone-2

traceroute 断在了 Multacom 机房的路由,ssh 后 traceroute 到国内的 IP 断在了骨干网,ping 其他邻居的 IP 基本没有事。所以应该不是屏蔽网段,而是直接针对 IP 屏蔽了。不过也奇怪应该没有什么大流量之类的,发现出问题的时候还在公司走 ss 用 Telegram,并没有什么大流量,不是很懂。嗯……难不成之前是瞎玩写的 xn--eckxj725iv5g.xn--eekf.xn--q9jyb4c 被发现了,然后就被屏蔽了?反正不是很懂,目前暂时靠 CloudFlare 续命,十一回家的时候发现家里的联通网络相性非常好,还能流畅在 YouTube 看阅兵(?

traceroute

另外上个月折腾了下 Oracle Cloud,选择了日本线路,延迟感人,绕道到 ping ~200ms,speedtest 到东京的测试服务器上行 48Mbps 下行 4Mbps,iperf3 也就 10Mbps。由于羊毛被褥的太狠,想开第二台机器做内网 iperf3 测试,结果开通的时候提示已经售罄了,所以至今不知道这玩意的网络配置是什么样,感觉或许还不如美西节点,美国节点还有免费邮件额度。相比之下韩国节点可是在公司跑到了 500Mbps 的,不过韩国基本不能访问 porn 也没什么用,日本节点再慢,至少还能看个 DMM(虽然也不知道能买什么,也不玩页游,所以……好像也没用)。

oracle-dmm

或许之后会试着在那个东京节点上做一份 mirror,有时间再折腾吧。对速度感兴趣的同学可以访问这个对象存储的链接,看看速度有多渣:https://objectstorage.ap-tokyo-1.oraclecloud.com/p/VdT8VdFqkU-e4Tex4GnHK-VA6XwCnH_7zjpnM_Xtnr4/n/nrzblovvku9x/b/bucket-ccloli/o/76825905_p0.jpg 。总之,这个东京节点路由不行,虽然 traceroute 机器的上一个路由是从广州出口直接到 Tata 的,不过还是很慢,对东亚用户来说还不如美国线路(韩国用户和日本用户除外?),反正现在的 ping 值比到位于西海岸 LA 的 Multacom 机房的 200ms 还高,夜间高峰期线路干扰更可怕,丢包率 50%……除了能访问只有日本 IP 能打开的网站外,还不如美西节点。

oracle-ping

嗯,总之,大概就这样吧,明年的存活报告或者明天见。

嗯,先赶在 23:59 前先发布了,然后再来编辑(

萌节存活报告

嗯,我还活着。

感觉每年十月十日发文章就当是存活报告好了。

嗯,就这样,明年见。