幹壞事是進步最大的原動力
AWS 宣佈 Lambda 支援 Ruby 2.5：「AWS Lambda Supports Ruby」。
另外宣佈可以透過 Layer 的方式讓任何程式語言在上面跑 (前面提到的 Ruby 看起來就是用這個方式支援的)：「New for AWS Lambda – Use Any Programming Language and Share Common Components」。
The Runtime API is the future of how we’ll support new languages in Lambda. For example, this is how we built support for the Ruby language.
這兩天又遇到一次，這應該是 Laravel 裡設計比較奇怪的地方，既然是跑 PHPUnit 的環境，為什麼不預設在錯誤發生時把完整的 stack 拋到 console...
這邊的解法是參考「Laravel: How to enable stacktrace error on PhpUnit」這篇的解答。
舊版需要自己丟 handler 進去 (5.4 以及之前的版本)，在 5.5+ (寫這篇時最新的穩定版本已經是 5.6) 有內建 withoutExceptionHandling() 可以用，所以在 tests/TestCase.php 內搞定 setUp()：
protected function setUp()
{
parent::setUp();
$this->withoutExceptionHandling();
}
不知道有沒有機會直接進 Laravel 的 package 設定裡面...
看到「JVM Anatomy Park」這篇，作者是 Red Hat 裡 OpenJDK 團隊的人，寫了二十則與 JVM 效能相關的主題，裡面提到每則大約花五到十分鐘可以看完，不過我覺得應該會再久一點 (需要翻資料交叉查)。
除了網頁版外，也提供 EPUB、MOBI 與 PDF 格式可以下載。
都是講效能相關的，從不同角度看。以第一個 Lock Coarsening and Loops 來說，已知這段程式碼：
synchronized (obj) {
// statements 1
}
synchronized (obj) {
// statements 2
}會被轉換成這樣等效的程式碼：
synchronized (obj) {
// statements 1
// statements 2
}作者就問了，那這樣的話，這段：
for (...) {
synchronized (obj) {
// something
}
}會不會轉成這段呢：
synchronized (this) {
for (...) {
// something
}
}答案是不會，但可以橋：
While lock coarsening does not work on the entire loop, another loop optimization — loop unrolling — sets up the stage for the regular lock coarsening, once the intermediate representation starts to look as if there are N adjacent lock-unlock sequences. This reaps the performance benefits, and helps to limit the scope of coarsening, to avoid over-coarsening over fat loops.
就大概是這樣的主題 XD 每天看個一兩篇慢慢消化還不錯...
在「Excel team considering Python as scripting language: asking for feedback」這邊看到微軟正在考慮要不要讓 Excel 支援 Python，出自 UserVoice 上的：「How can we improve Excel for Windows (Desktop Application)?」。
比較感覺到有可能性應該是因為微軟做了一個問卷收集資訊：「Python and Excel」。
不過本來的功能就已經可以用到很出神入化了... XD (想到最近提到的「LINE 將內部的座位表由 Excel 改成 Web 界面...」)
扣除掉 fork 的程式碼後，研究人員在 GitHub 上還是發現有大量重複的程式碼：「DéjàVu: a map of code duplicates on GitHub」。
This paper analyzes a corpus of 4.5 million non-fork projects hosted on GitHub representing over 482 million files written in Java, C++, Python, and JavaScript. We found that this corpus has a mere 85 million unique files.
用 Java/C++/Python/JavaScript 寫的 4.5M 個專案有 482M 個檔案，但只有 85M 個檔案是不一樣的 XD
想一想其實也是... 現在愈來愈多工具產生程式碼了 XD (i.e. Scaffold)
GitHub 寫了一篇「GitHub welcomes all CI tools」，不過對我來說比較有趣的是各家 CI 在 GitHub 上的市占率：
可以看到 Travis CI 還是擁有壓倒性的佔有率 (大約一半)，這跟他提供免費的 public repository 方案有關。但以另外一個角度來看，這也讓使用商用版本 (travis-ci.com) 的人有大量的範例可以參考，而不需要擔心資源太少。
在朋友的 Twitter 上看到 shellcheck (ShellCheck, a static analysis tool for shell scripts) 這個專案：
但我最近還是在維護/砍一堆 shell scripts 就是惹，推薦 https://t.co/INDLQeeZOK
— Suiting Tseng (@suitingtseng) October 27, 2017
可以看到有點像是 lint 工具，給了不少建議：
而且看起來已經發展很久了... 在各大 distribution 內都可以直接裝。
官方對於 HHVM 的未來提出了說明：「The Future of HHVM」。重點就是他們不打算以 PHP7 為目標，打算關起來自己玩...：
Consequently, HHVM will not aim to target PHP7. The HHVM team believes that we have a clear path toward making Hack a fantastic language for web development, untethered from its PHP origins.
如果以 Packagist 上的資料來看 (PHP Versions Stats - 2017.1 Edition)，HHVM 的數量應該是沒人了：
And because a few people have asked me this recently, while HHVM usage is not included above in the graph it is at 0.36% which is a third of PHP 5.3 usage and really hardly significant. I personally think it's fine to support it still in libraries if it just works, or if the fixes involved are minor. If not then it's probably not worth the time investment.
Comment 的地方有註明這是扣掉 CI 的量：
@ocramius: These numbers ignore Travis CI and other CI systems that set the "CI" env var in their workers. Without excluding those HHVM is around 0.95% so it's still low but those .36% is probably actual usage.
這樣就放心可以完全不用管 HHVM 了 XDDD
2015 的文章以及演講，最近冒出來看到的。Google 的 Peter Norvig 提到了用 ML 的方式分析，發現程式競賽的成績與工作品質的負面相關性：「Being good at programming competitions correlates negatively with being good on the job」。
換句話說，程式競賽的成績反而是是個負面指標 (對於 Google 內的情況分析出來的，所以是基於 Google hiring process 的前提過濾過的)。
In this talk, Peter talked about how Google did machine learning and at one point he mentioned that at Google they also applied machine learning to hiring. He said that one thing that was surprising to him was that being a winner at programming contests was a negative factor for performing well on the job.
給了一些對原因的猜測：
Peter added that programming contest winners are used to cranking solutions out fast and that you performed better at the job if you were more reflective and went slowly and made sure things were right.
YouTube 的留言處也有一些猜測，像是：
What he's talking about is the fact that several extremely important parts of software engineering are not included in these contests, for example code reusability, maintainability, decomposition of the problem using the OO paradigm, etc. All of these make a good engineer, but are not necessarily needed in competitive programming contests.
StackOverflow 直接拿薪水戰 Tab 與 Space 的差異啊 XDDD：「Developers Who Use Spaces Make More Money Than Those Who Use Tabs」。
這下糟糕了 XDDD