太肤浅了，居然认为 property 是没意义的。我弄 Unity3D 时就觉得，只用 field 不用 property 各种不便……

https://zhuanlan.zhihu.com/p/51395461

#linux #security #windows

PuTTY 释出新版本修复 8 个高危漏洞

在时隔 20 个月后，流行 SSH 客户端 PuTTY 释出了新版本 0.71，修复了 8 个高危漏洞。根据官方的安全公告，旧版本的 PuTTY 包含了多个安全漏洞，允许恶意服务器或被入侵的服务器劫持客户端系统。这些漏洞包括身份认证提示欺骗，劫持 CHM 文件的代码执行漏洞，Unix PuTTY 工具的缓冲溢出，重用随机数，整数溢出漏洞，等等。使用旧版本 PuTTY 的用户最好尽快更新。Media

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

所以呢，细心的大佬们仔细观察一下 duangsue 这条消息，你们会发现 duangsuse 开始决定走出之前某次导致某 Android 开发者频道被删的事件的阴影了

#statement #Android #dev

自然，情绪平复是需要时间的。 ⏲

大佬们看垃圾 duangsuse 之前的广播，会注意到可能有表现得很难受的消息，甚至有些消息，是有莫名讽刺意味的

实际上这非常的智障，首先，我自己在那个领域（指 Android 应用程序开发/计算机图形图像/图形用户界面和布局设计）（这个领域基本还需要基本的异步编程和 HTTP 等，软件架构也了解一些，至少要能模式识别别人的 pattern，此外文档要会看资料和代码要会找，思维方面的和函数式编程/算法相比的确不可否认的相比一般较少，好比现在国内高中的文理分科）还不够好啊！（告诫之心） 😝

是的，我不会再像以前一样到处『别喷』『别喷』乱叫了（跑） 🤔

而且，我知道我不是天才，之前足足两年的努力，已经充分说明了我不聪明，但是也不愚蠢。

我已经能看到前面怎么继续做，当然，这都得感谢我看过的十多本书和数不清篇数的 A4 纸、博文，他们有的是关于编译原理、有的会教函数式编程、有的是异步/事件驱动/并行算法的（虽然异步和并行使用上一般没有太大关系）、计算机网络（虽然我基本没学，只会个 HTTP 而已，OSI 七层模型都忘了）、有的关于面向对象类结构设计、有的是图形用户界面的、有的教一些现代开发平台，比如广泛了解 Google V8 的类库/函数库使用

🤔📖

现在 duangsuse 显然，不会站在 show 『我从来没读过书』『无书自通』优越的人们那面了

读书给了我比『代码写多了书看少了』的人们更多的，一些不一样的东西

比如，看到学术那面的能力
比如，搜索资料的能力
比如，知道从电子电路到程序设计语言类型范围知识的能力
比如，看到接口后面复杂度的能力
比如，对算法和数据进行可视化分析的能力
比如，对函数式『简洁而难理解』结构的分析能力
比如，程序变换而非简单过程式编程的能力
比如，关于历史的知识

🤔
好像是很没用的技能呢，但是，但是，我觉得也是很不错的方向呢。
我觉得这样可以走的更远，于是，即使有时候好像看不出和一些『老程』会去写出的代码有什么区别，看起来还幼稚的多，也是坚持走『看书实践』的路线
也一定会坚持下去的，坚持训练自己快速解决 trivial 问题的能力、对 nontrivial 问题的分析能力。

虽然没有 OI、CodeWars、各种好的算法项目、各种 Android 应用去做自己的确优秀的证明.... 因为还是学习者啊...
现在看书，的确是因为没有时间啊...

== 那么就来说说之前那件『阴影』一样的事情吧，现在看起来是越来越多了呢，虽然也就那么一两个人。

@drakeet 呢，是现在任职于 M$ 做 Android 开发的一个软件工程师，看起来好像有 6 年经验的样子。好像之前在深圳来着

GithubRank.com 排行前列，不过我觉得他写过的软件架构库（框架）最好的也就是 MultiType 和 Floo 了

🐙

他的工程领域呢，就是 Android 开发。
他的主要公开作品呢，我觉得是 Pure （纯纯）系列应用
他主要在 JVM 平台上工作，使用 Java，最近学了 Kotlin（实际上 Kotlin 2017 年被 Google 钦点为 Android 官方开发语言后很多 Android 工程师都开始用了）
除了 JVM 平台上的 Kotlin 和 Java，他也会使用 Python、C++ 来设计程序（语言什么的其实不重要，这里只是介绍一下）
除了 Android 外，他也会写 JavaEE（虽然我目前只见过他开发了一个开源的应用）和其他类似 IDEA 插件一样的程序
至于技能方向，就是泛向的 Android 应用程序开发，我个人总结一下，细分出来绝对会包含以下方面：
+ 面向对象和面向对象软件架构基础
+ RecyclerView、ConstraintView 使用
+ 适应新 Android API 的能力
+ 布局和动画能力
+ SQLite 数据库使用、ORM、HTTP API 使用
+ 查阅任何文档、寻找开源项目、第三方/网络开发平台、博文等的能力
+ 异步编程能力，已经可以看到他完全适应 Observer 信息流处理模式

（你们别喷我瞎介绍，我真的不是瞎介绍... 信息来源，这是他自己公开的，而且如上，这根本就是一个会拿自己照片当头像的软件工程师附带的公开属性嘛）
以上简单地介绍了一下他，仅仅是给可能不认识他的人一个介绍。


我在 coolapk.com 认识了他，不过他一直都是作为酷安开发者来着的（
后来我来到 Telegram...

说到为什么 @drakeet 要删除自己的 Telegram 频道，闭源自己的很多开源项目（包括他的 Pages 博客，虽然里面的文章不是很多），全 TMD 怪我 🤪...

首先，我得说明一下，我对 drakeet 这个人来说只是技术观点上稍有不同，我对他的人格还是完全理解并尊重的（而且我自己也有个问题，就是太『热爱』技术以至于经常熬夜什么的...），以下任何言论，皆是客观（虽然是我叙述的）事实。不能在任何侧面上被解读为对 drakeet 的冒犯，也不能在任何程度上被理解为对 drakeet 代码或者实践的负面评价，我对发生这种令人遗憾的事情也深表歉意。 🗒

=> 我在酷安上认识了 drakeet 和他的 PureXXXX 系列 Android 应用；后来我在 Telegram 找到了 Drakeet 宣传的群并且加入
=> 第 0 次，我加入了 drakeet 的 PureWriter Friends 讨论群组；因为有时候会发一些很专业倾向的内容（在坐各位都知道我一贯的尿性，不发就没有记忆用啊~）而且都是很 Trivial 的内容（e.g. 用 VisualGC 看某 JRuby 应用的 Java 堆... 实际上是我策划好的某书上的实践可能... 但的确很 Trivial，好比一些编译 XXX 软件包/如何安装/部署的帖子一样）
=> 第一次，drakeet 表示自己的应用纯纯写作有独特的代码保护，反正就是软件安全/信息传输安全保护方案（他还写了博文）；我花了三天多利用 AndBug 动态分析下断点『破解』了纯纯写作的『藏叶于林』 Proguard repackage 保护，找到了检查签名攥改验证的代码路径（实际上，有两天的时间是尝试理解二进制，也即 ByteBuffer）；我向 drakeet PM 告诉他『或许这真的不是无敌的，因为貌似有办法破解』；中间我有一次向 drakeet 提到了一个『安全』界比较内部的名词：“猫鼠游戏”，结果导致 drakeet 误认为是我是『猫』他的保护方案是『鼠』（其实原意是，软件安全领域，双方的对抗是永恒的），当然最后他原谅我了，这是第一次误会，当然你们理解为冒犯也不为过，如果你们只是把我当 *** 看的话 🐱

=> 一次（没错我不记得顺序了），我记得为我被（因为我本来打算自己搞的，后来某原酷友自己可能是在看了我的广播后又创了一个『社团』... 叫 GeekApk，which 现在我在尽可能想办法复活的）弄的一个非常弱智的项目（因为很多加入者也是各搞各的，虽然加入者基本都是前端，还有一个唯一的大佬，现在已经搞高性能计算去了，因为基本设计比如模型关系操作通知等都没有决定好，无法开工啊）去和 drakeet 讨论了一下，不知道别人 PM 不能随便转发的我转发了一条给 GeekApk Core，导致 drakeet 被 Core 的其他成员吐槽，这是第二次

=> 最后一次，drakeet 提到一个数组（线性表）优先级排序的问题（OI 入门内容，所谓初等内容都是 dfs bfs 这种的，计算机可解的数学问题，游戏模拟、递归算法、关系代数，稍微搞基一点的离散化、编译原理、神经网络）
就是你们之前看到纯纯支持 Book 的 Chapter 手动排序的特性，他在群里讨论了一下，（想了一段时间）说是逻辑上冲突无法实现，我表达了一下自己的看法『你可以做 Pin Chapter 的功能啊，我觉得应该会用得到』，但是 drakeet 觉得这依然是 NP-hard 问题（他觉得这类似停机问题，是不能解决的，我的观点大概就是不必须使用优先级排序，排序什么的有很多方法，都好说，『半自动排序半手动』是完全可行的），我最后甚至用 Ruby 写了个算法实现（就是能够 Pin 数据的 Array，并且可以自动 sort，sort 完手动 pin 的数据依然在表头部），结果就被踢了.... 🙁

That's all I ever did. 😟

然后我因为不爽就在自己的频道说了几句不中听的话，有点 judge 人了（技术... 技术... 技术...
（有人说，跟程序员交流，不要说那么多话，要么秀代码，要么秀妹子。）唉我怎么扯到这些了，鬼扯

顺手又分析了一下 drakeet 的技能栈
顺手又评论了一下人家的算法功底，这 EQ 可以。当然我不是说 EQ.... emmmmm
hhhhhh....

然后，人家觉得我从之前老转发重新转发的他的广播，消息什么的，都是『间谍』『小号』转发的
然后就在频道上继续... emmm
然后我被他『全线 banned』
然后就是删频道、闭源项目什么的了...

我很久都没有从这里走出来，一直以为自己会经常被一些同道喷。被害妄想。 🤪

̶就̶是̶这̶样̶，̶喵̶。̶

至于道歉什么的，我开始已经道歉了。
至于我原来对他有点过激的言论（我发誓真的只是有点，我只是比较『露骨』地说了实话和我内心真实的感受而已，首先，我确认都是实话）
因为某 Android 爱好者朋友的建议都删了

后来我看到 @FiveYellowMice 的一篇文章 《我喜欢网络上的大家，但是我好纠结》

至于后来我还要不要『和好』什么的，我觉得是不必了，我开始以为这只是一时性起而已，会不会还要挽回这第一个我搞砸的事情，后来我发现这后面有必然的因素 — drakeet 没有真正把我当朋友看待，或者说这其中作为长者对后辈的部分多一点，毕竟 drakeet 不是冰封哥（你们看看我当时的言论，其实冰封哥是最大限度的容忍傻逼『咦你是在骂你自己』）或者 RednaxelaFX，我不能指望他一而再再而三容忍太多。

所以我们其实不是朋友，他『如此残酷』自然也有理由了。

所以我们其实不是一条道上的人，只是碰巧都在 JVM 上（或者说，Dalvik 上，有时，当然 JVM 和 Dalvik 的区别在我看来还没有大到必须区别对待的程度），仅此而已。

那么，就不要再见，或许是最好的解决方案了。 🤔


有时候想想，年轻时看起来多么要好的朋友，时间流逝，环境变迁，也会有一天再也不见，甚至，见到了也只能让那美好的回忆生出裂痕。

从前有从前的环境和故事，现在又是一篇故事了... 虽然我不是这故事的主人公，但我觉得，如果是我，我要保守友好的真心... 诚心希望走出半生，归来仍是少年...

啊，RIME 的地球拼音音标记号真好用啊，记得现代输入法经常使用决策树和一些人工智能算法...（违和感）
啊，汉语拼音真好玩啊，可是就是有点难学，记得小学的时候学了很久 Latin 字母和拼音... 原理都忘了
啊，wiki 真的是人类历史上相当有用的知识形式啊...
啊，开源真好

时间真的可以改变一切。

唉....

上面的，我最后还是只能抱怨一下自己的缓慢，和做最后一点能做的事...

1. AXMLSerializer，我正在写（格式从这个 axmlparser 里学中，也看到了它用一个 Binary Data Reader 帮助类很好用，可惜 Delegate 类全是余赘代码），顺手学了一下 POM 模型一些比较入门的东西

== POM 模型我设置的属性（基本 Maven Center 里都能看到的）：

Group, ArtifictId, VersionName

PomURL, PomName, PomDescription, PomPackaging

DevName, DevId
ScmUrl, ScmDevConn, ScmConn
LicenceURL, LicenceName, LicenceDist

2. 支持 lambda calculus 的计算器，我真的很想体验一下 Unicode 语法（跑

1+1
1+2*3
(9-3)*2+1
10/1
1.1*100
0xabcdef
10e1
-4
(-4)+1
nand = λa b. ¬(a ∧ b)
xor = λa. λb. a∨b ∧ nand(a)(b)

体验了 EPL(懒得检查表达式了)、Fritzing(这个玩意是用来进行嵌入式设计的，当然你也可以理解为开发板编程什么的，可以画原理图、建面包版和写串口通讯代码)
因为打印了很多博文的缘故，已经开始手动处理网页来尽可能压榨一面 A4 纸的信息量

顺手分享 #doc #share #cs 包含很多 PLT(依赖类型 Agda) 的内容和一个 PL 和编译原理的内容（R大 09 年的一个博客）

R 大 09 年就那么大佬了，难怪现在我都看不见他一样了... 这世界有代沟啊

Agda 的 coinductive record 么... 我还没学会，emmm。
Agda 环境我还没建立，到时候建立了会发一些简单的证明帮助大家入门。

立即 公开维护（

#telegram #github #issue https://github.com/duangsuse/Share/issues/2

AXMLParser parser = new AXMLParser(apkFileInputStream);
int eventType = parser.getType();
while (eventType != AXMLParser.END_DOCUMENT) {
String parserName = parser.getName();
boolean isManifest = "manifest".equals(parserName);
[...]
eventType = parser.next();
}

这个原来的玩意是用流模式的...
我也打算这么做，当然也会提供扫描整个文档的辅助方法

这种方式也被 LLVM Cookbook 里的 TOY 语言 Lexer 采用（get_token() 函数从输入流扫描，然后返回词条类型，业务代码判断词条类型访问相应静态变量拿信息）

就作为 Iterable 吧，因为我觉得这种方式（eventType + static field 存储 AXML 结构信息）不够面向对象，反而能嗅出点过程式的端倪。

换句话说，我觉得我应该这样封装：

val parser = AxmlSerializer.Reader(axmlFileInputStream)

for (node in parser.treeIterator) {
  when (node is AxmlTag && node.tag == "manifest") {
    // [...]
  }
}

虽然这样会导致它不够『底层』以至于不是所有 xmlparser 可以处理的文档它都可以处理，但我还是觉得... 不错
不过... 其实鱼和熊掌可以兼得，先做一个流处理最底层的 AxmlSequencer，再在上面封装 AxmlSerializer.Reader 不就好了吗？
流处理，最下面是 Binary 数据的 Reader (Extension)，提供最底层的二进制格式 DataView
中间一层是文件大格式的 Scanner (Reader)，扫描 AXML 『大体』的文件格式（Chunk）
最顶端一层提供 AxmlTree 流接口和帮助函数，每次需要新 node 时就看看自己的缓冲区里有没有剩下的对象可供返回（数据指针移动）
如果没有了，向底层 ask 新的 chunck，拆分，入队，否则返回已经扫描出来的对象

val treeIterator: Iterator<AxmlNode>
get() = asIterator()

fun asIterator(): AxmlNodeIterator<AxmlNode> {
return /* 实现 next 和 hasNext，如果队列为空则从 Sequencer 里读取下一块，拆分，存到 NodeIterator 的队列里，否则返回出队元素 */
}

https://github.com/duangsuse/AxmlSerializer/wiki/Binary-Serialization-%E7%B1%BB%E8%A6%81%E6%8F%90%E4%BE%9B%E7%9A%84%E6%88%90%E5%91%98%E5%92%8C%E6%96%B9%E6%B3%95%E6%93%8D%E4%BD%9C#binary-serializatoin

我正在准备分析手头上的资料总结出『后面』的文件格式，等我验证规范有效之后，就会开始写一个二进制序列化类库，使用这个线性字节流结构提取式类库解决 AxmlSerializer 的问题

新的库有糖能够使得文件格式的表达更具定义式风格，避免了使用旧式的 byte array 一大堆算偏移量、提取字节数组组装某种数值、裁切子序列的操作（一些不嫌麻烦的库现在依然选择这种方式）

@ByteStruct
class ResChunkHeader {
  @Type(Unsigned16) ChunkType type;
  @Type(Unsigned32) long size;
}

这样对于简单的结构体，在 parser 里面调用 reader.readStruct(ResChunkHeader.class) 就可以了
🤔

AAPT2 AXML 文件格式的总结，将在这里讨论

为了方便快速了解格式详情，会使用弱类型的『脚本语言』Ruby 进行 STDIN IO 解析 AXML 文件基础结构。

简单的思路，虽然写了我很久 🤔...