IngramChen 積分 0

如果要講些什麼經驗的話,就不用硬上 幹話 這種虛詞吧,無助要表達的東西。而且講得內容不就是 找藉口推掉 嗎?

幹話這詞也被用爛了,現在什麼都叫幹話,我這留言也是幹話,你全家都幹話。

IngramChen 積分 0 編輯於

Groovy 和 Scala 都曾挑戰過 Java 的霸權,不過最後的下場都是失敗。其中一項原因就是可讀性比 Java 差。(很奇怪吧?明明是更簡潔的新語言... 但事實就是它們做過頭了)

Kotlin 吸收兩者的教訓,調的剛剛好,讓人愛不釋手。

IngramChen 積分 3
  • Xamarin 是弄給 C# 開發者的
  • React Native 是 Front End 開發者才會去寫
  • Kotlin 是那些 Android/Java 開發者才有興趣
  • Flutter 是 Googler 內部使用

每個跨平台工具都有不同的跨平台的做法,但其實都有強烈的背景在。如果你不是該背景的人,通常不會去選該種特化的工具。

這些工具都各有優缺,但最主要的問題還是市場上人力資源不足,市場上多半還是 native 開發者較多。Mobile 開發者如果決定投入某平台的開發,他/她會投資相關的工具鏈和技能,很難說放棄再學另一套的,尤其是 Mobile 開發現在深似海…

有沒有人學好幾套的?一定有啦,但很多嗎?這位開發者的薪資又會上升到什麼等級?你公司請得起嗎?

IngramChen 積分 0

理論上是假消息, 但 apple 如果不澄清的話, 表示其實 apple 未來有想...

IngramChen 積分 1

我以為 ajax 的部份是用 fetch 了

IngramChen 積分 1

沒有喔 , 很多人受不了跨平台跳出來 (通常是 bug 太多, debug 太難

IngramChen 積分 0

總算惡意廠商不能靠 target 低版本做弊偷資料了

IngramChen 積分 0

還有 es5/es61 兩個 parse 出來的結果不太一樣,馬的,JSON 明明就是從 js 生態出來的,自己還搞得不相容

IngramChen 積分 1 編輯於

都用 Z 嗎?那的確是沒問題

但 offset 的 +/-hh:mm 其實也是 local ,但大多數的人把它當做絕對在用

IngramChen 積分 0 編輯於
  • integer 最大可到 2^53 ,拿來放 unix epoch timestamp 可以放到 5000 年,夠了。時間這個欄位規格和 parser 一直很混亂,時區也難搞,所以我個人最後通通退化成 epoch milli-second 了。

  • 最上層只能是 {}[] 到是第一次注意到,所以單單寫 "foo" 這樣不算個 JSON。

  • JSON 格式很簡單,但難用的是不能寫 comment,還有不允許結尾多個 comma:

{
   "foo":"bar",
}

不接受結尾 comma 很煩

IngramChen 積分 0

不是新玩意,不過看到別人在用這個分析 amazon 的 review 正確性。

amazon (美國) 的 review 很早以前就覺得怪怪的,日本那邊感覺比較少問題,不過可能是語言不熟所以判斷假 review 更難。

當然啦,Fakespot 之流的會不會之後也同流合污就不曉得了 (就像 adblock 開始收錢放白名單一樣)

好奇大家怎麼分辨假 review ?

IngramChen 積分 3 編輯於

a long story...

這個架構看完後,真是憂喜半參,憂的部份比較多。

首先,全部的專案感覺都要混在同個 repository ? 希望這只是範例的問題。

第二,能夠共用的有 common, common-client,但感覺沒有很多。common 還好,都是 data model ,設計一份後給所有人共用就行了。

common-client 就有點難了,它將原本寫在 Activity/ViewController 裡的程式抽出共用的部份,盡可能讓所有平台都共用程式碼邏輯。理論上是不錯的。

但經過我這幾年待團隊的經驗,abstraction (抽 interface) 這件事很多開發者都做不好。一是能力不足 (寫前端/mobile 的人大多太年輕),另一個是根本沒機會點這方面的技能,自然也進步不了。

common-client 很吃開發者抽象化的能力,我的預期是最後是一團比原來更看不懂的程式碼。

第三,裡面的 DateTime 範例嚇到我了,為了跨平台,連這種最基礎的元件都要再抽象化一層。拜託,處理時間的函式庫難寫的要死,抽象化做對更是難上加難。要應用程式開發者做這種事是不切實際的。

也許這只是個範例,不過 DateTime 在跨平台上現在 kotlin 還沒有解 (最近 1.2 版出了 kotlin 版的 Math,解決掉一小塊)。而且還有許多塊要解決,這也不知道哪天會完成。在尚未完成前,就很吃開發者的功力了。

data class Account (
   val uid:Kuuid,
   val createTime:KDateTime
)

上面是個隨便的帳號 data model ,如果 uid 設計成 UUID,很顯然的每個平台的實作都有點不大一樣,kotlin 又沒提供,所以你只好自己刻一個 Kuuid ,然後下面的 KDateTime 也是同樣的意思...

這跟我想要的不大一樣啊....

IngramChen 積分 0

升到 kotlin 1.2 , android kotlin relfection 好像壞了

IngramChen 積分 0

帳密怎麼會 commit 進對外的 repo 啦!

private repo 不保證就是安全的. 而且自己人也可以任意 checkout, 不是一個超大洞嗎. 密碼或 key 只能少數人會碰到才是

能 commit 進的, 頂多是那些受限的 aws iam 帳號而已

IngramChen 積分 0

uber 把 aws 帳密 commit 到 github private repository, 然後駭客偷到密碼後去他們家 aws 逛街, 逛到了 archive 的司機和乘客的資料

駭客向 uber 勒索, 然後 uber 也付錢了事.

IngramChen 積分 1

let 最常用 (基本上是萬用),其次是 apply,剩下的都是想到後再查哪個適合。

IngramChen 積分 0

看他們的最早的 amazon sdk 就知道了,整個是 xml hell,然後不同語言的版本基本上就是用 java style 在寫。