#Kotlin #Telegram https://github.com/Trumeet/EncoderBot

说到 resources，

Android 平时容易用到这些 resources:

一般放在 sourceSet dir 的 res/ 下
java 的却是默认放在 resource/ 下，一般除了 properties 就没有别的了

res 由 AAPT 处理，在打包的时候打包进 apk 里

drawable mipmap ninepatch vector
menu layout anim
style theme
string dimen color id
attr

... emmm 忘了还有什么了（

#Android 2.3.7 res 了解一下 http://androidxref.com/2.3.7/xref/frameworks/base/core/res/res/

https://github.com/Trumeet/EncoderBot/blob/master/src/main/kotlin/moe/yuuta/encoderbot/EncoderBot.kt
正准备使用 Scala 重写这个具有 Inline Keyboard/Callback Query 和 Inline Article 功能的 bot...

就是三种接口方式：

回复 Telegram

Message 普通消息
CallbackQuery 键盘回调
InlineQuery 内联机器人回调

第一次使用 #Java 的 Resources

第一次使用 #Scala sbt（死变态 emmm...

第一次使用 #Scala 的 experimental language feature: macros

虽然最后我还是放弃了继续写这些... 即便除了 bot 逻辑外的都写完了

虽然 Scala 再去继承一下 TelegramBots 的 Api Class，使用 postfix operators 和 implicit conversation 和比 Kotlin 搞基的 Pattern matching 应该可以实现更优秀的可读性，而且这应用逻辑本身就不是多复杂...

比如说，Scala 的 Postfix Operators

import scala.language.implicitConversions
import scala.language.postfixOps

final implicit class HelloableString(val m: String) {
  def ! : String = s"Hello, $m"
  def unary_! = this.!
  override def toString = m    
}

scala> !"duangsuse"
res0: String = Hello, duangsuse

scala> "duangsuse".!
res1: String = Hello, duangsuse

scala> "duangsuse"!
res2: String = Hello, duangsuse


比起 Jawa, Kotlin 里不断 execute(Query) 好多了...

有的时候觉得经验和记忆力重要，因为不会记住那些接口就不能编程了呢....
即便会怎么怎么样，可能比擅长编写应用的人们更适合去学习算法什么的，但是好像也不怎么样

又有时候会觉得对模型的直觉很重要

也有时候会觉得设计和分析的能力很重要....
因为能写很多真正能让人看不懂的东西，而不是容许一切复杂性都被藏在一些简单的东西后面

所以，到底是使用接口的知识『广度』大好呢，还是分析能力『深度』大好呢... 🤔

这是一个值得考虑的问题

🌚 你写 PHP 7.4 的样子好像 Node.js

* 新特性汇总
* RFC：箭头函数语法
* RFC：数组解构语法

上面的作为比较可以看看用 #Haskell 怎么写：

parts = ["apple", "pear"]
fruits = ["banana", "orange"] ++ parts ++ ["watermelon"]

fruits == ["banana","orange","apple","pear","watermelon"]

因为 Haskell 没有『Spread operator』所以就用 (++) 替换了，虽然说 spread operator 也不是魔法的就能实现把『item』里的东西全都 flat 添加到集合里的能力了，势必也得做额外的支持

result = f [1, 2] where f = (sum . ((*2) <$>))

(putStrLn . show :: Int -> IO ()) result

其中 sum 的定义是

sum [] = 0
sum (x:xs) = x + sum xs

或者，用 foldl 定义（非 point-free 版本）

sum xs = foldl (\ac x -> ac + x) 0 xs

(.) 就是 compose 啦（

(sum . ((*2) <$>))
就是

(\xs -> sum (map (* 2) xs))

(*2) 是柯里化的 (*) （
(*) :: Num a => a -> a -> a

拿到一个 Num a 以后还要一个 Num a（因为有交换律 transitive 所以不用考虑顺序）就可以得到乘积

最近是不知道该做什么，想做的太多了，时间太少了，又不会休息... 效率低下精力损失

思量着写点异步的应用学习一下 Events/Callback/Promise/Coroutine/AwaitAsync/Threads 什么的？

https://github.com/duangsuse/WowCoolApk/issues/1 #GitHub #CoolAPk

#info #Telegram 这周 duangsuse 将开始使用一种新的制度，可能可以提升我的工作效率和身体素质（目前应该视为首要任务） —

现在，很多东西对于 duangsuse 来说终于不是难题了，duangsuse 已经有了可以在应用层（包括异步、函数式、用户界面、计算机网络、数据库、IO 等）驰骋的能力，而且还是多语言！

所以我依然要继续学习 #CS 计算机科学了（而不是成天等着完成 XX 事情），

不过，我决定，因为每周的时间非常有限， 一周只完成大概的两件任务（任务是随便定的）

然后剩下的时间就主要是咸鱼看番（ 🐟
（算是对完成速度快的鼓励
（好吧，是因为我目前好像不应该在电脑面前坐太久呢。

#algorithm #cs #net #security 🌚

这... 他们也真是太有创意了，这都能想出来（其实也不意外，像这种增加服务资源消耗的破坏性攻击也是直觉所在了...）

🤔 HashMap 的最差时间复杂度，假设是扎堆的情况下可能是 O(n**2) ？
看来还是我不了解这些算法....

我一直以为最差大不了就是 O(n) 的，线性 Map 也就是这个复杂度：

#Haskell 里，（List）Map 可以这么定义：

data ListMap k a = ListMap [(k, a)] deriving Show

Eq

不能直接 derive。
然后我们定义基础的 get 和 put 操作：

import Data.Maybe (listToMaybe)

getKey :: (Eq k) => ListMap k a -> k -> Maybe a
getKey (ListMap xs) k = (snd <$>) . listToMaybe . find $ xs
where
find = filter ((== k) . fst)

putKey :: ListMap k a -> k -> a -> ListMap k a
putKey (ListMap kvs) k v = ListMap ((k, v) : kvs)

因为 Haskell 多了一层递归调用栈的空间复杂度（比如 filter 操作）... 算了，有 TCO... 算了... 和时间复杂度无关...

😫

但是，即使是 ArrayMap 的最差情况时间复杂度也只是 O(n) 啊！为啥 HashMap 就多了一个 n*...

我知道，现在流行的（比如，Lua 和 Ruby 和 PHP 的实现）散列表实现都是基于『散列桶』分配的，需要时多分配一些桶（链表），重新算散列分配操作

但那的复杂度好像也不是 O(n**2) 啊... 毕竟最差情况也就是算一次 O(1) 的散列 Key 拿储蓄对象的 bin，结果 bin 里碰撞了（不止一个 kv 被分配在某桶），那复杂度就会是 O(n) （要线性查找一遍）