/tmp/duangsuse.sock
23 subscribers
303 photos
3 videos
92 files
337 links
从 duangsuse::Echo (@dsuse) 跟进出来的分支,将在作者恢复原帐号访问的时候合并删除。
Download Telegram
Forwarded from Deleted Account
应用,图个开心嘛,平常工作做得就行了。
Forwarded from Deleted Account
都做那么好,用户也看不出来,还浪费 CPU,得不偿失。
Forwarded from Deleted Account
优雅可以弄成模块做,就像 Java 可以选择 assertation 是否 -ea
Forwarded from Deleted Account
不必每次都检查
Forwarded from Deleted Account
其实也没什么的,就是 users.forEach { val name=it.key; val (x,y,z,w) = it.value }……好吧,的确不很好看
Forwarded from Deleted Account
所以我说,数据表示层的东西就放本层解决,不要干扰到其他抽象,那就惨不忍睹了。
Forwarded from Deleted Account
如果你专门建立一层处理这个复杂性
Forwarded from Deleted Account
你的软件还可以同时兼容两种格式,虽然那没有用而且有不良影响
Forwarded from Deleted Account
可是一般情况都不会出现的,出现代表数据本身有问题了
Forwarded from Deleted Account
json.org 可能有这种规范?
Forwarded from Deleted Account
可是检查可能浪费 cpu cycle 啊
Forwarded from Deleted Account
现在一些开发者
Forwarded from Deleted Account
应用启动快那么两三毫秒
都是非常骄傲的
Forwarded from Deleted Account
他们还会弄那个什么 Java 双检锁
什么 lazyload、preload
Forwarded from Deleted Account
我们这些基层人民,就是喜欢降智提速。
Forwarded from Deleted Account
算喽,没有调查就没有发言权,你我都懒得去 profile,不就 +1s-1s 的问题么,应用层谁在乎呢。
Forwarded from Deleted Account
某些开发者喜欢自己写算法,或者暴力搜索,浪费 JVM 应用不少时间和内存,还不是没什么。
Forwarded from Deleted Account
你等我找相关代码…… JSON object 解析是不是
https://github.com/duangsuse-valid-projects/jison/blob/master/src/commonMain/kotlin/org/jison/JsonParser.kt#L82

private val jsonObj: CParser<Json.Dict> = kvPair.joinBy(tCOMMA)
.then { it.toMap() }.surroundBy(tLB, tRB) then { Json.Dict(it) }


其实我要写长一点,不先解析到 List<Pair 再那个转化也是可以了(MutableMap 直接 setValue),只不过为了方便我没那么干。
Forwarded from Deleted Account
其实不一定需要那个 list pair -> map 的过程,就像你的音频软件用那 audio buffer 也不一定非得按整个音频为单位处理一样,有一定窗口大小就够了。
Forwarded from Deleted Account
kotlin.collection 的扩展函数实现啊,List<Pair<K, V>>.() -> Map<K, V>