#China #web 🤔

【品葱】
看到这个，我只想说：意料之中。

整天内斗吵架，不维护社区氛围、不鼓励创作，那么就只能慢慢的死亡了。因为品葱本身的竞争力不大，很容易就能找到替代品。真正让用户持续在品葱发表内容，都是靠用户维护出来的氛围。肆意将用户污蔑成网军，对原创内容的不重视，极大的破坏了这一氛围。品葱自然就丧失自己的独特性了。

更不用说趾高气昂的管理员。这点相信如果大家有和某些管理员接触过就知道我在说什么。

不重视内容，不重视用户体验的恶果已然显现出来。品葱站长无论是公开还是私下都多次表示品葱的目标是要“活下去”，而不是“做大”。但是品葱目前面临的问题是自身在失去“生命力”。错将维护讨论氛围、改善用户体验视为“扩张”。对于提出问题的用户刻薄与打压（甚至污蔑对方为网军），对于不满管理员决策的用户嘲弄与侮辱。品葱与半年前提出的《习惯法》沦为废纸。所谓“用户自治”彻底失败。可以说，品葱作为公共讨论空间，已完全失去“讨论”。目前品葱的定位更多的是内容农场而不是“问答式社区”

品葱的例子令人惋惜。曾经的旧品葱无论是氛围还是内容都无法挑剔，可惜在中共的威逼利诱下被迫关闭；新品葱在最初的时候虽然小众，但是质量、氛围、人气随着反送中运动的爆发而爆发，往后无论是反送中，新冠肺炎，都有着非常大量且用心的内容发表。可如今再去看品葱，关于国安法的讨论寥寥数个，首页大半部分被搬运新闻和旧贴占据。质量也不尽人意。看了看品葱曾经的archive，看到曾经品葱上的人们乐观而且满怀希望得为自己心中的信念与他人据理力争，再看看如今少有答案/评论超过一百个字。曾经置顶各种活动贴，多方联动。如今躲在角落里自己一个人玩泥巴

不禁感叹一句“时过境迁啊。

品葱已死，我们还要继续走下去。希望大家永远都要记得品葱，记得它曾经大放异彩，更要记得它是怎么落寞的。

各位晚安。

#gui #android

请教一个相机相关的问题。打开相机以及设置预览回调都在同一个子线程内。但是在onPreviewFrame回调方法中打印当前线程却是 main。 何故？

Callbacks from other methods are delivered to the event loop of the thread which called open(). If this thread has no event loop, then callbacks are delivered to the main application event loop. If there is no main application event loop, callbacks are not delivered.

#Kotlin #collection 怎么把两个List合为Map?

可以 (xs.zip(ys) as Iter<Pair<A,B>>).toMap() 但不一定真是 Iter
可以用 xs.associate { it to yz.next() }
可以 ys.associateBy { xz.next() }
据说还有 xs.associateWith(ys) { (x,y) -> x to y }

如果连 Pair 都不想创建，可以 zipToMap 组合+归纳:
while (xz.hasNext() && yz.hasNext())
map[xz.next()] = yz.next()

api依赖就是compile的

implementation 是 runtime，那么 runtimeOnly 又是？

天哪。 #android #java
反正我只爱 DOM 和 Model/View

现在大家用aac架构的多吗？怎么看这个架构

Android architecture components

这个跟mvvm mvp mvc相比，是不是复杂了

但是啊，我的配置已经是4G了：

@AntiRevoke
請幫忙檢舉謝謝（
Report > Other
範文：
This channel provides a "plugin" for tdesktop that breaks the delete message feature for other chat members, this plugin violates clause 1.4 of telegram's api tos, please ban this channel.

雖然的確違反 API ToS 但它不是一個用戶端

#Telegram 另：喜闻新 Channel Comment 功能产生

https://t.me/AndroidDevCn/167939 #android #gui 看到了有意思的东西 #db

借着这个官方手刃同人的机会，咱来谈一谈 Channel comment board 应该怎么写。

这里不提及回调、消息队列、按钮盘和内联之类的细节，只写成接受必要参数的 fun onXXX() 的形式

与 Telegram 的数据交流与存储责任优先提及：
inline keyboard 各钮的文本和 callback ID 由tg保存，回调含 targetMessage

bot PM(private message) 含事件 onMessageEdited, onMessageDeleted

单单实现添加评论很简单，在按钮链至PM /start 后提示用户输入，再更新目标消息、插入"${user.name}: ${msg.text}"即可。

不过这个流程会被打断成 inline-button 存 targetMessage 再 pm 得检查关于 user 的 state (1参， targetBoard) 才能做到收到后更新。

这个状态表优化后就是 Map<UID, MID>
可以设计为 UserState: add(u,v) get(u) pop(u) 的形式

onKeyboardCallback(msg,key) = state.add(msg.user, msg)
onMessage(chat,msg) if (chat.isPM)
  msg.command == "start" -> if (state.get(msg.user) != null) /*提示*/
  state.pop(msg.user)?.let { /*更新board*/ }

如果要支持编辑/删除消息操作，必须进行一定程度的关系型数据库建模。
因为文本是由 board 保存的，可以仅对 board msgId : PM msgId 实际储存，从而能在 PM 删除时 getBoardMsg

Board(channelId, msgId)
hasMany PM(msgId)

顺便存 chan. Id 也无所谓，如果实现 channel 的 board 枚举用得到

至于编辑可以实现 parse:(String) -> Map<UID, String> 操作和对应的 toBoardText() 操作，当然也可以直接 String.modifyBoardText(i, text)

以字符串保存列表必须处理转义问题(比如单项的换行符必须保留，人类可读，就可以用 "\n(.*):  " 切分而替换单项的文本，不过在 tg 里用 bold mark 标注用户名就可以了)，但这样还是比独立存储文本再去拼合的开销低。

但仅这样还差一点：不知道要修改的是第几条。假设一个 board 同 user 只能有一条评论，可以再建立一个记录 Board hasMany BoardUser(no, user) ，或者如果 SQL 扩展支持数组的话，直接保存用户ID数组

必须保存创建编号来升序排列，而可 indexOf 查出编辑消息用户的位置，不过这样也就可以同时做一个『最近评论』页了…… (以编号降序，某人在某板评论了 board.findPM(/**/) )

毕竟关系数型据库的 record 除了 "relation" 外也称为 "entity"

当然，更正经的做法是直接保留 PM 的创建顺序，然后查某pm在某board里的位置(pm.board/*findBoard()!!*/.indexOf(pm))，上面是提示思维过程。

关系型数据库的名字可不是白叫的，它不是像 CSV 一样，仅仅像 ORM(object rel. mapping) 一样是 List<T> ，尽管它所支持的“关系”非常初步，而且基于 foreign key，只有 hasOne/hasMany 以及 relation "wtf" 的双边关系。