Microsoft 虛擬化的兩個消息:Azure 被打臉以及 AWS 推出轉移工具

首先是 VMware 發文打臉 Microsoft 說他們所宣稱的轉移工具 (從 VMware 轉到 Azure 上) 並沒有 VMware 原廠支援:「VMware – The Platform of Choice in the Cloud」。

然後 AWS 則是推出了從 Hyper-V 轉移到 AWS 的工具:「Migrate Hyper-V VMs to AWS with AWS Server Migration Service」,這邊倒是沒提到官方支援...

這臉不只是腫腫的而已了,有種連續技的感覺 XD

AWS 提供 Windows 上的 Deep Learning AMI

有一些 Windows 上的東西就可以直接開起來跑了:「Announcing New AWS Deep Learning AMI for Microsoft Windows」。

目前支援 2012 R2 與 2016:

Amazon Web Services now offers an AWS Deep Learning AMI for Microsoft Windows Server 2012 R2 and 2016.

然後 driver 與常用的東西都包進去了:

The AMIs also include popular deep learning frameworks such as Apache MXNet, Caffe and Tensorflow, as well as packages that enable easy integration with AWS, including launch configuration tools and many popular AWS libraries and tools. The AMIs come prepackaged with Nvidia CUDA 9, cuDNN 7, and Nvidia 385.54 drivers, and contain the Anaconda platform (supports Python versions 2.7 and 3.5).

AWS 推出可以在 Red Hat Enterprise Linux 上跑 Microsoft SQL Server 的 AMI

自從 Microsoft SQL Server 宣佈可以在 Linux 上跑後 (參考「Microsoft SQL Server 出 Linux 版...」),就沒看到什麼 Linux 上跑 SQL Server 的消息了... 結果在這波 AWS 的活動上推出了 RHEL 上跑 SQL Server 的消息:「Amazon EC2 now offers SQL Server 2017 with Red Hat Enterprise Linux 7.4」。

SQL Server 2017 is now available for Amazon EC2 instances running Red Hat Enterprise Linux (RHEL) 7.4 as an Amazon Machine Image (AMI) from the AWS Marketplace. With this release, you can now launch RHEL instances on-demand using SQL Server 2017 Enterprise License Included AMIs without having to bring your own license. SQL Server 2017 on RHEL 7.4 AMI is available in all public AWS regions starting today.

這個消息看到的時候嚇了一跳...

Microsoft 與 GitHub 合作,將會把 GVFS 移植到 Linux 與 Mac 上

MicrosoftGitHub 合作將本來只有在 Windows 上可以用的 GVFS 移植到 LinuxMac 上:「Microsoft and GitHub team up to take Git virtual file system to macOS, Linux」。

GVFS 是解決微軟內部自己在用 Git 的痛處,因為微軟的 repository 都... 有... 點... 肥... (畢竟有不少產品發展了很久)。

目前 Git 的操作是卡在 I/O 與 memory cache 的限制上:

Also, Git wasn't designed for a codebase that was so large, either in terms of the number of files and version history for each file, or in terms of sheer size, coming in at more than 300GB. When using standard Git, working with the source repository was unacceptably slow. Common operations (such as checking which files have been modified) would take multiple minutes.

GVFS 的想法是有用到的部份再真的去拉,藉此大幅減少 I/O 需求...

所有主流瀏覽器的最新版都支援 WebAssembly 了

Mozilla 的「WebAssembly support now shipping in all major browsers」提到了最近幾個禮拜,新版的 SafariEdge 都相繼支援 WebAssembly 了:

In the past weeks, both Apple and Microsoft have shipped new versions of Safari and Edge, respectively, that include support for WebAssembly.

由於 ChromeFirefox 都已經支援了,這宣告 WebAssembly 的障礙都已經排除了,接下來只是時間的問題... 對於需要效能的應用程式來說多了一個方式加速。

大家在吵漢堡的 Unicode 呈現...

前幾天在 Twitter 看到這個 tweet,然後在高雄的時候 (MOPCON 2017),跟 zonble 聊天時他也提到這則 tweet 很有趣 XD:

然後有人回必要條件 XDDD:

結果微軟是對的 XDDD

然後這邊有實物照片:

不過比較有實際價值的是知道了「? Emojipedia — ? Home of Emoji Meanings ????」這個站台,可以查每個平台的呈現方式...

跨各平台的 Microsoft Edge 又讓搞網站的人爆炸...

還好用的人應該不會太多 (?)

微軟宣佈在 iOSAndroid 以及微軟自家的系統上都推出 Microsoft Edge:「Announcing Microsoft Edge for iOS and Android, Microsoft Launcher」,另外也很「貼心」的整理了一篇不同平台上的差異 (尤其是 iOS 與 Android):「Microsoft Edge for iOS and Android: What developers need to know」。

不過 Twitter 上微軟自家人 Kyle Pflug‏ 講的比較簡單:

把重點講的超清楚,然後順建讓人有種 WTF 的感覺 XDDD (等於是一次推出三個不同行為的 browser 啊!)

設計師鐵定會詛咒他不要流行起來 XDDD

Google 放棄對海外伺服器搜索票的抵抗了...

先前美國政府透過搜索票,要求各雲端廠商提供海外伺服器的資料而引起話題 (像是先前 Microsoft 往上打官司抵抗:「Does US have right to data on overseas servers? We’re about to find out」),而現在看起來 Google 打算放棄掙扎了:「Google stops challenging most US warrants for data on overseas servers」。

Google has quietly stopped challenging most search warrants from US judges in which the data requested is stored on overseas servers, according to the Justice Department.

Microsoft 這邊有些不錯的進展,成功在巡迴庭擋下:

Microsoft convinced the New York-based 2nd US Circuit Court of Appeals—which has jurisdiction over Connecticut, New York, and Vermont—that US search-and-seizure law does not require compliance with a warrant to turn over e-mail stored on its servers in Ireland.

不過沒看到 AWS 相關的消息,感覺不妙...

Adobe Flash 將在 2020 年 End of Life

Adobe 發出的公告,將在 2020 年中止所有對 Flash 的支援:「Flash & The Future of Interactive Content」。

Specifically, we will stop updating and distributing the Flash Player at the end of 2020 and encourage content creators to migrate any existing Flash content to these new open formats.

然後 GoogleMicrosoft 也來補刀講兩句話:「So long, and thanks for all the Flash」、「Saying goodbye to Flash in Chrome」、「The End of an Era – Next Steps for Adobe Flash」。

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: