來拉板凳看日本警視廳對 Open Source 的敵意...

出自 Twitter 上的這則 tweet:

下面已經開始有人在吵了,該來拉板凳了...

將 Sketch 輸出成 iOS/Android 的程式碼

Supernova 是前陣子看到的工具,目前是 public beta,將 Sketch 的設計直接轉成 iOS/Android 的程式碼,減少每次手動調整的痛:「Introducing Supernova」。

目前只支援 iOS/Android,但之後有打算要支援 React Native。(參考「Import & Export」這邊的說明)

五月時寫到的「透過 NN (類神經網路) 訓練好的系統,直接把圖片轉成程式碼」這篇是直接從圖片轉成程式碼,也是想做類似的事情。但 Supernova 因為有 Sketch 內的資訊,轉換的準確度會高不少...

對 Adobe Flash 的開源請願

Adobe Flash 在 2020 年要被收掉 (參考「Adobe Flash 將在 2020 年 End of Life」),但有很多作品是使用 Flash 寫的,這表示這些作品在 2020 年以後將無法存取。

所以就有人提出請願,希望 Adobe 將 Flash 開源,讓這些作品可以延續下去 (像是轉成 HTML5+CSS+JS 或是其他方案):「Petition to open source Flash spec」。

Google Chrome 59 之後的新功能:看 CSS 與 JS 的 Coverage

在「What's New In DevTools (Chrome 59)」這邊看到 Google Chrome 59 後所推出新的工具,可以看目前網頁的 CSS 與 JS 跑過的 coverage 比率。

像是這樣,總大小以及未使用的比率:

然後可以再直接看有哪些部份沒跑到:

可以拿來分析,降低使用者下載的量。不過真的要切的話好像不太好做...

Microsoft Blogs 上 TDD 的戰文...

文章標題就直接寫「#NoTDD」的戰文 XDDD

列了 Pros (一行) 跟 Cons (超長 XDDD):

Pros

  • We end up with tests that verify the behavior of the code and help prevent regressions

這個是 TDD 的目的。而 Cons:

Cons

  • It takes us longer to write code using TDD
  • The tests get in the way. Because my design does not have low coupling, I end up with tests that also do not have low coupling. This means that if I change the behavior of how class works, I often have to fix tests for other classes.
  • Because I don’t have low coupling, I need to use mocks or other tests doubles often. Tests are good to the extent that the tests use the code in precisely the same way the real system uses the code. As soon as I introduce mocks, I now have a test that only works as long as that mock faithfully matches the behavior of the real system. If I have lots of mocks – and since I don’t have low coupling, I need lots of mocks – then I’m going to have cases where the behavior does not match. This will either show up as a broken test, or a missed regression.
  • Design on the fly is a learned skill. If you don’t have the refactoring skills to drive it, it is possible that the design you reach through TDD is going to be worse than if you spent 15 minutes doing up-front design.

這四個問題講的是時間與能力兩個因子的作用,轉一個角度來討論其實是:如果 junior engineer 可以寫出好的測試,他們就不叫 junior engineer 了... 而 senior engineer 是稀缺資源,讓他們多花時間寫出「好的測試」未必是划算的。

反而是另外一種常見的方式常常跟 TDD 在對抗:透過 QA team 在完成後測試,尤其是用手動測試的 QA team XDDD

這個方法很簡單,而且行之有年。而且很無奈的,跟一般軟體工程所期望的相反,junior engineer 就可以做的不錯,所以人力的部份相當好 scale,而品質也有不錯的水準 (畢竟是直接測實際的功能了)。

剛好前陣子有提到另外一篇論文也在討論 TDD 的效果 (參考「又一篇戰文:討論 TDD 的過程」這邊),也有類似的反思。

前陣子在 Twitter 上看到這則也是很有趣,拿來當結尾 XDDD:

透過 NN (類神經網路) 訓練好的系統,直接把圖片轉成程式碼

這個禮拜被 AlphaGo 洗臉後,又看到來搶工作的東西了:「pix2code: Generating Code from a Graphical User Interface Screenshot」。

直接把 Mockup 圖檔丟進去,然後就把 iOS 或是 HTML 程式碼生出來:

不過「刻 UI」的確是工程師最討厭的事情啦,這部份能自動化要怎麼說呢... 好像也是不錯的事情啦 @_@

直接從 IMDb 編號看影片

看到「Now Anyone Can Embed a Pirate Movie in a Website」這邊介紹的東西,直接輸入 IMDb 的編號 (包括 tt 開頭的那串編號),他就自動拉出 embed code:

然後可以直接線上觀看:

然後還支援字幕 (唔):

Interestingly, should one of those sources be Google Video, Vodlocker says its player offers Chromecast and subtitle support.

官網有寫來源是到處找:

VoDLocker searches all general video hosters like youtube, google drive, openload...

看起來整塊技術其實都是現成的。透過 search engine 加上定期的檢查機制與回報機制就可以做完 @_@

OpenSSL 將轉為 Apache 2.0 License

OpenSSL 最近打算把原本的 license 換成 Apache License, Version 2.0:「Licensing Update」。

主要的原因是希望相容於現有大多數的 open source project:

OpenSSL Re-licensing to Apache License v. 2.0 To Encourage Broader Use with Other FOSS Projects and Products

但這非常詭異啊,舊的 license 最大的問題就是與 GPLv2 不相容,而預定要換的 AL 2.0 也還是不相容啊,搞屁啊。

Amazon EC2 上的 gettimeofday 與 clock_gettime 的效能

看到「Two frequently used system calls are ~77% slower on AWS EC2」這篇在講 gettimeofdayclock_gettime 的效能,另外搜資料時發現應該也是作者提問的「gettimeofday() not using vDSO?」這篇。

EC2 比較新的機器上用 tsc 應該是沒問題的 (在 2015 的時候官方就這樣建議了):

it seems tsc support in Xen has improved with version 4.0 and with improved CPU support in Sandy Bridge+ platforms. Modern EC2 machines should be okay with tsc. Check Xen version using dmesg | grep "Xen version". Amazon recommended the tsc clocksource already in re:Invent 2015 (https://www.slideshare.net/AmazonWebServices/cmp402-amazon-ec2-instances-deep-dive). I'm not yet running to production with this, but the situation doesn't seem as bad as implied by packagecloud.

開了一台 t2.micro 看 /sys/devices/system/clocksource/clocksource0/current_clocksource 看起來目前是設成 xen

ubuntu@ip-172-31-22-165:~$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
xen

在「(CMP402) Amazon EC2 Instances Deep Dive」這邊也可以看到一些資料 (page 24 與 page 25):

AWS CodeDeploy 支援 BlueGreenDeployment

AWS CodeDeploy 推出了 BlueGreenDeployment 的功能:「AWS CodeDeploy Introduces Blue/Green Deployments」。

BlueGreenDeployment 的目的不計成本想辦法把上線的 downtime 壓到最低,而且當出問題時 rollback 的時間壓到最低的方法:

One of the challenges with automating deployment is the cut-over itself, taking software from the final stage of testing to live production. You usually need to do this quickly in order to minimize downtime.

Blue-green deployment also gives you a rapid way to rollback - if anything goes wrong you switch the router back to your blue environment.

其實就是直接跑兩個環境 (所以成本比較高),一套跑舊的一套跑新的,然後在前面的 load balancer 切換:

The blue-green deployment approach does this by ensuring you have two production environments, as identical as possible.