PNG 格式联合设计者去世

图像格式 PNG（Portable Network Graphics）早期核心设计者、PNG Development Group 的联合创始人 Glenn Randers-Pehrson 去世。他是 PNG 规格 version 1.0、PNG 1.1 和 1.2 的主要作者，1995 年在 Web 上发布了最早一批的 PNG 图像。他也是 PNG 参考库 libpng 的长期负责人。Media

https://www.solidot.org/story?sid=58351

.Net 的这个东西，要摸清它起码得深入到很底层的部分，而且不是三言两语就能解释完的

https://docs.microsoft.com/en-us/dotnet/api/system.threading.tasks.task.yield

#tech #ieng

#dotnet #csharp #microsoft #windows

过会将会检查更新 Gekyll，如果有可能必要增加的特性都将加上
并且将新加入的 InScript 特性开 issue 到 https://github.com/duangsuse/Lite 里
明天要准备 Ins 的总设计文档

转眼间我买的第一个一年的域名已经过期了，我离开酷安入 Telegram 也快一年了，第一次接触 Java 大概也有两年了呢。这两年收获巨大。当然主要都是我自己看书学的（（但是也感谢大家的科普，愿大家以后都能成为优秀的工程师，能够游刃有余的处理各种复杂的分布式、并发处理和同步、异步、底层、计算机网络、信息安全、机器学习、CG、算法、优雅函数库 DSL、解释器、逆向工程/二进制相关、函数式逻辑式等问题

曾经书本上复杂、晦涩难懂的知识对我来说已经不是黑盒。我曾经购买的十多本书里再也没有一行完全看不懂的内容。
原先根本看不懂的什么位长度、什么半字双字缓冲器已经成为日常。
原先一个原生 .so（SharedObject 共享对象）就是“无法理解”的黑盒，现在 x86 机器码根本不是问题、远程 GDB 调试和高等 GDB 功能也不是问题
原先连 Java 的 OOP 类型系统自动子类自动转型基类都无法理解，现在理解整个 Java 类型系统已经不是问题
第一个黑历史 Android 应用 MinBase64 到现在，我却已经记住了 Base64、double-quoted 编解码方式

如果翻译器对程序进行了彻底的分析而非某种机械的变换，而且生成的中间程序与源程序之间已经没有很强的相似性，我们就认为这个语言是编译的。彻底的分析和非平凡的变换，是编译方式的标志性特征。
如果你对知识进行了彻底的分析而非某种机械的套弄，在你脑中生成的概念与生硬的文字之间已经没有很强的相似性，我们就认为这个概念是被理解的。彻底的分析和非凡的变换，是获得真知的标志性特征。 

感谢 Telegram 无限的消息历史记录和数据下载的功能让我能回首这段「入门」的历史。
也感谢 GitHub 一直为我提供了那么好的代码托管、DevOps 体验
也感谢曾经的，“老”的酷安改变了我的人生，让我认识许多志同道合的朋友并且走上软件工程之路 #coolapk

其实环境总是会变的。你不能指望环境不去改变来适应你。
人也总是会变的。“当年的脚本小子都成后端工程师了”，酷安虽然是变了，进了很多可能不真正热爱这些东西的人，也是没有办法的事情呢，没有人愿意真正加入创建 GeekApk 这样的东西来改变这一切，所以，其实也是都不够想嘛，思想也是会变的

以后技术还将继续进步，但愿再有一年后，可以有丰厚的技术基础迎接未来。 #life

ps. 其实对于强类型语言，以「类型检查」是在编译时还是运行时（duck typing 动态类型）进行来判断是否为“动态语言”是可行的

对于「编译时」和「运行时」的鸿沟我看来主要就是「源对象到生成目标有没有损失信息」

我们来举个（不好的）例子，假设你把 C 编译到了 C（已经预处理）（换句话说就是 “预处理” C 代码），语义上是等价的，但是的确丢失了很多信息，比如没有用到的宏定义和宏定义体的源代码，无法访问到的这些信息就成为了“编译时”和“运行时”之间的鸿沟。

上面那个不知是不是从“虎书”、“龙书”、CSAPP、SICP 里抄的，不过我觉得这个 “没有很强的相似性” “很强” 定义不明确而且没有举例子讲述概念所以不是很好的表达，按理说“数学性”的东西不应该是 P ≠ NP 这样不明确的命题，这样看又好像是在搞哲学一样...

顺口说一下，我准备先花 20 分钟左右开发个在 Android 上自动启用 USB Tethering （USB 绑定网络）的应用，虽然很简单
（如果以后可能的话，可能想开发一下原生（Like C++）应用的 Hook 插件，要研究怎么做的话会在频道上更新的）
然后把 METO 的 sm.ms 图床接口代码发上来快速分享给大家
然后给 Vultr 钱钱...
然后补充一下 Gekyll 的设计，有时间时写
然后给 InScript 添加新特性，假期结束前出总文档

最后有没有大佬愿意想方设法教教我 C# 的 async 和 await 是什么原理，我虽然看了《CLR via C#》上的 async 状态机的讲解和《ES6 标准入门》的讲解还是感觉不是很清楚其用途，“以同步的方式异步”？
#task

#PL #life #tech “知其变，守其恒” 这个短语实在是太酷了，在学校的时候想了 5 分钟才回忆起来... 结合技术水平来看真的超有震撼力啊。

总之不管说计算机科学来看，偏向“理论”的不管是什么水平，偏向“工程”的水平都至少是提升了（虽然计算机科学是工科），所以对我来说技术的确提升了，虽然没有时间写什么代码。
大概是 CS、信息科学、电子电器都有点可以入门的感觉但是因为数学不好所以暂时还是很小的方向发展... 连画画都差点不会（其实至少怎么画圆和怎么画弧形（圆角的长方形）都是不知道的）

Canvas 这种高度封装的东西加上 Math 都不会用的话... CG 方面的确是不可能啊... Math.sin 是什么... log10 又是什么... hyp 是啥...

#Haha #OI #dev 🤣👍

正是因为知道的多，所以才知道自己的无知

真正有知识的人的成长过程，与麦穗的成长过程一样：

麦穗空的时候，麦子长得很快，麦穗骄傲地高高昂起；

但当麦穗成熟饱满时，它们开始谦虚地垂下麦芒。

正是因为能透过问题的表象看到本质、透过宏观看到微观，能站在比别人低、比别人靠近本质的地方观察，才能做到「知其变」，才能在技术更新越来越快，各色语法糖变化、语言特性换上新包装的时代里坚守自己永恒不变的真知「守其恒」

正是因为懂得多，看得细致、能够透过一行行 C# 代码看到生成的 IL、看到 JIT 编译出的机器代码，才可以发现底层以微粒子形式存在的数据竞争风险和值类型装箱操作的隐患，而不是等到程序已经公开部署、安全漏洞已经被大量利用才迟迟修复

只有肯沉下心来学习知识，才有可能从理解 -> 使用 -> 创造一步步走上去，只有有了更高层次的视角 才能解决别人“不能解决”“无从寻觅”的问题

感谢 C# 大佬的好心，据说 《CLR via C#》 作者 Jeff 曾经写了一个 AsyncEnumerator 类，不知道有什么关系

我觉得奇怪的是假如说 async 函数里 await 别的 async 函数时这个函数直接返回...（啊啊啊是我想错了...

ES6 的 Generator（Corountine 携程）函数我还了解（包括在 coroutine 里 yied 别的 coroutine 函数），但 async 语法好像让问题理解复杂起来了，到现在还一直不是很清楚，只知道怎么用不知道是怎么实现的...

// 附：ECMAScript v6 Generator 函数例子

function *coOneTwoThree() {
  yield 1
  yield 2
  yield 3
}

var co123 = coOneTwoThree()

> co123.next()
{ value: 1, done: false }
> co123.next()
{ value: 2, done: false }
> co123.next()
{ value: 3, done: false }
> co123.next()
{ value: undefined, done: true }

async/await 的，要先知道 foreach 的实现原理