要找到適合的站立桌不容易阿,之前公司買了IKEA的升降桌,結果每個人的身高不同所以最後也沒什麼人用。
感覺要像圖片裡面那樣的手臂可以有點斜度,可以很舒適的擺著,才會感受到好處。
這不是 Objective-C 那邊的傳統嗎? 為什麼 Swift 要幹類似的事情,兩者語法完全不同阿wwwwwww
現在就看 Mooink 能不能起到關鍵作用了。就像 Kindle 推出之後 Amazon 電子書才起飛一樣。電子書要有閱讀器,讀起來才能算得上比較舒服。
不過最近 Kobo 的折扣真的很凶狠阿...
Readmoo 有起來的跡象...事實上可以買的電子書已經相當多了
我也填了,雖然不是 jetbrain 的愛用者...(逃
我猜這應該是怕merge過程出錯,不是想用 fast-forward。
如果全部都刪掉再重加,就保證 code 一定是最新的,不用顧慮conflict。反正他們團隊從來不在 master 上開發,所以只有其他分支單向合進 master
100% Adobe RGB 有點驚人阿,通常筆電有 100% sRGB 就已經算是高級面板了。
不太懂為什麼最後那個Y型管可以應用白努利定律?
實在太長了...
C# 是暗示 Windows 是驢子嗎XDD
對阿,這時primitive的生命週期就是跟著那個物件了。 (題外話C++物件可以宣告在stack上XDDD
放在 stack, 脫離作用域就釋放
學到一招! 感謝
Atom 跟 Visual Studio Code 幾乎同時推出即時協作功能。以後可以直接坐在座位上 code review 了。
現在我們公司是用 Twitter 的 Fabric。不知道這個有什麼差別?
原來 Go 已經八年了阿,比想像中久。
UI 有差,而且有些舊的Add-on不能用了。
之前FF 52真的是卡到飛天,逛Facebook不定時就會卡死幾秒鐘。56/57之後就沒有問題了。而且 FF 的字體渲染比 Chrome 好看多了...
已經用 beta 版好幾個禮拜啦,加速有感,很順暢。FF 57 出來之後已經把主力瀏覽器從 Chrome 改回 FF 惹。
砍文了...
佛曰:不可說XDDD
其實很多的軟體工程原則像是「函數的長度不應該捲動超過兩頁」之類的,也是受限於人類的大腦能力吧
牽涉到Database所以就不能單純看時間複雜度啦。DB query過程中可能會存取硬碟,而存取硬碟的時間遠大於存取記憶體的時間,O()預測法八成會失準(因為常數太大)。
我自己猜測直接用 DB Query 會比較快,因為DB本身的資料結構通常都已經針對硬碟存取優化過了。
真的要硬做的話,直覺的作法就是先排序然後用二分搜尋法,看你的資料量有多「大」,能不能全部塞進記憶體裡面做。
目前大多數開源專案都是「無償勞動」的結果
我用這款唯一的理由就是可以一鍵打開 Pull Request
公司的空間離職就沒了,但是學校的通常畢業後還可以繼續用
Kmark 是一個類似 Markdown 語法的格式,以下為提供的功能:
*兩邊加單星*
**兩邊加雙星**
~~兩邊加雙曲號~~
> 左邊加個大於符號
左邊加個大於符號
* 可用星號 * 也可以 - 減號 * 數字加點也可以
`abcdefghijk`
兩邊用倒引號包住
abcdefghijk
``` function abc() ```
上下都用三個倒引號包住
function abc()
[這是連結][1] [1]: http://example.com
連結第一部份是文字,先用中括號包住,後面再加上 [編號]。 第二部份是連結本身,放在文末,開頭是 [編號]: http
這是連結1