Mailgun 這篇提供用戶端更換 API key 的作法還蠻有趣的:「Swap out your API keys with no downtime」。
舊的 API key 不會馬上失效。不過,比較常見的情況應該是服務提供商提供多組 API key 的能力就可以了?像是 AWS 就可以做到。用戶端換完後把舊的 API key 拿掉即可。
幹壞事是進步最大的原動力
Mailgun 這篇提供用戶端更換 API key 的作法還蠻有趣的:「Swap out your API keys with no downtime」。
舊的 API key 不會馬上失效。不過,比較常見的情況應該是服務提供商提供多組 API key 的能力就可以了?像是 AWS 就可以做到。用戶端換完後把舊的 API key 拿掉即可。
在「Git Workflows That Work」這篇提到了不少 Git 的 Workflow,從中可以看到各家的開發模式,以及想要解決的問題:
主要還是要看環境而決定,並不是哪一種 flow 就一定好...
把 PHP 的 Memcached 整理一下,未必適合其他人用。
設定上:
OPT_DISTRIBUTION
與 OPT_LIBKETAMA_COMPATIBLE
。SERIALIZER_JSON
,一樣是為了與其他程式語言相容。使用上:
add()
在 key 存在時會失敗,set()
則會覆蓋過去。add()
、set()
裡的 expiration 參數是 UNIX timestamp,而非直覺的秒數...get()
的 callback 不應該使用,因為無法設定 expire time。:
) 當作 key 的分隔,這對於統計資料會有幫助。先整理到這...
在一月時,Facebook 官方的 Engineering Blog 上提到 Facebook 使用 Mercurial 遇到的問題,以及所作的努力「Scaling Mercurial at Facebook」:
Facebook's main source repository is enormous--many times larger than even the Linux kernel, which checked in at 17 million lines of code and 44,000 files in 2013.
...
Instead, we chose to improve Mercurial. Mercurial is a distributed source control system similar to Git, with many equivalent features.
當時的解讀是 Facebook 把 main source repository 放到 Mercurial 上。
以 Facebook 的規模以及遇到的問題,是有能力直接改變世界的,用 Mercurial 或是 Git 都算是合理的選擇。
不過這幾天在 Twitter 上看到:
Facebook's git repo is 54 GB. pic.twitter.com/zLNSzDlFYF
— Feross (@feross) April 24, 2014
這讓人錯亂了啊 XDDD
Go 的 self-boot 計畫,也就是用 Go compiler 編 Go compiler:「Russ Cox – porting the Go compiler from C to Go」。
其中提到:
The goal is to convert *their* C code (not all C code). They want generated code to be human-readable and maintainable. They want automatic conversion to handle 99+% of code.
第一波想要用機器轉換過去,而且要轉出可維護的程式碼。可以馬上想到的事情是,如果這件事情成功,代表現有軟體的 C code 也有機會轉移?
接下來了幾個版本會開始發展整套機制,有得瞧了 :p
查 PHP 上 CRC32 的資料時,查到讓人噴飯的 comment:
For those who are wondering, there appears to be no fundamental difference between hash_file('md5')/hash_file('sha1') and md5_file()/sha1_file(). They produce identical output and have comparable performance. There is, however, a difference between hash_file('crc32') and something silly like crc32(file_get_contents()). crc32(file_get_contents())'s results are most similar to those of hash_file('crc32b'), just with the octets reversed: <?php $fname = "something.png"; $hash = hash_file( 'crc32', $fname ); echo "crc32 = $hash\n"; $hash = hash_file( 'crc32b', $fname ); echo "crc32b = $hash\n"; $hash = sprintf("%x",crc32(file_get_contents($fname))); echo "manual = $hash\n"; ?> crc32 = f41d7f4e crc32b = 7dafbba4 manual = a4bbaf7d
不只是 hash_file()
抓出來不一樣,連 algorithm 都來亂...
Python 2.7 將支援到 2020 年:「Extend Python 2.7 life till 2020.」。
The End Of Life date (EOL, sunset date) for Python 2.7 has been moved five years into the future, to 2020. This decision was made to clarify the status of Python 2.7 and relieve worries for those users who cannot yet migrate to Python 3. See also PEP 466.
This declaration does not guarantee that bugfix releases will be made on a regular basis, but it should enable volunteers who want to contribute bugfixes for Python 2.7 and it should satisfy vendors who still have to support Python 2 for years to come.
有種淡淡的哀傷...
「Buggy Security Guidance from Apple」這篇再次說明了 C 語言因為 undefined behavior 而讓 coding 需要注意的事情變多...
這段 code:
size_t bytes = n * m; if (n > 0 && m > 0 && SIZE_MAX/n >= m) { ... /* allocate "bytes" space */ }
問題在於 C 語言裡對 overflow 並沒有定義行為 (undefined behavior),所以 size_t bytes = n * m;
這段 code 並不保證當 overflow 後 bytes 的值會是多少,於是就很容易造成各種意外。
原文有提到更多資訊,以及提出的解法,這邊就不提了...
在「Split a commit in two with Git」這邊看到有趣的方法:
git rebase -i <oldsha1> # mark the expected commit as `edit` (replace pick in front of the line), save a close git reset HEAD^ git add ... git commit -m "First part" git add ... git commit -m "Second part" git rebase --continue
squash 是把多個 commit 合起來,這個方法是拆開。還沒有 push 出去,需要整理時應該會用到...
前幾天有人成功利用 XML External Entity 安全問題,取得 Google 伺服器內的資料:「How we got read access on Google’s production servers」。
可以看到上圖是 /etc/passwd
的內容...
XML Parser 預設有太多功能是根本不會想要用到的,沒有注意到而忘記關掉就會中獎...