Home » Posts tagged "blog"

Amazon Lightsail 試用兩天的心得...

前幾天在「Amazon Lightsail 降價...」這篇文章提到了 Lightsail 這波降價還蠻有競爭力的,但之前看過「Is the fact that Lightsail instances are just renamed T2 instances that run on CPU credits actually documented anywhere?」這篇,大概知道 Lightsail 後面其實就是 t2 系列的機器,只是在這次 t3 出來後的改版不知道有沒有順便一起改...

前幾天直接把 blog + wiki 整個搬過去看看。本來在 Vultr 的主機是 1GB RAM,就挑了對應的方案搬過去... 如果還是 t2 的話,應該就會是 t2.micro 的機器。

由於搬家前面一天都在弄各種環境,所以應該累積了不少 CPU credit,實際的情況還是要等 DNS 指過來超過一天後才會知道。在剛剛跑了一整天,把 CPU credit 吃差不多後確認了,應該還是 t2.micro,baseline 在 10% (被降速了):

這樣的話就維持在 Vultr 好了... CPU 資源看起來還是用超過了。

把 Blog 換成 PHP 7.2

去年十一月出 PHP 7.2,現在已經更新到 7.2.5,各家軟體的相容性也都修的差不多了,差不多該升級了。

在「PHP 7.2 的效能改善」這邊有提到與 PHP 7.1 的效能改善主要來自於同時間有多人同時存取時的最佳化。

同樣 wiki 也跟著更新了,來看看效果如何...

LINE 將內部的座位表由 Excel 改成 Web 界面...

LINE 將內部的座位表由 Excel 管理,改用 Web 界面了:「Excel管理の座席表をLeafletでWeb化した話」,這邊不確定是全球的 LINE,還是只有日本的 LINE...

如果跟日本人有過業務合作的話,就會知道他們對 Excel 的用法只能用

出神入化

來形容啊... 所以看到 LINE 特地寫了一篇來說明他們開發內部系統的事情,覺得還蠻有趣的...

起因是今年四月換辦公室,所以就順便換系統,把本來用 Excel 管理的座位表改用 Web 管理 (然後用了 Leaflet 這個 JavaScript Library):

人員の増加に対応するために、今年の4月、LINEはJR新宿ミライナタワーに移転しました。移転に伴い、IT支援室ではいくつかの新しい社内システムを導入しましたが、今日はその1つである「座席表」についてお話させていただきます。

這是 Excel 版本的樣子:

這是新版本的樣子,UI 上有更多互動的界面可以操作:

然後文末提到了總務業務量減少,而且因此變更座位變自由了而大受好評 (大概是不會讓總務煩死,所以就可以更自由換來換去 XDDD):

今回開発した座席表は総務の業務軽減に始まったプロジェクトでした。そして実際に導入後には、座席表の管理にかけていた総務の業務を大幅に削減することに成功しました。また、利用者からもかなり好評で、「これを待っていたんですよ!」といった声もあり、社内コミュニケーションの円滑化に一役買うことができているようです。誰の席でも自由に変更できるという点についても、これまでのところトラブルの報告を受けることなく運用できています。

翻了一下英文版的 blog,好像沒有提到這件事情?XDDD

WordPress 在 Internet 上的情況

WordPress 在 Internet 有很大的佔有率,在「Usage statistics and market share of WordPress for websites」這邊有一直更新的資料,現在是:

WordPress is used by 59.9% of all the websites whose content management system we know. This is 29.1% of all websites.

這數字可以參考看看。而在「State of the WordPress ecosystem」這邊就看到有人在分析 WordPress 在整個 Internet 上的情況。可以看到裡面有蠻多都是透過 BigQuery 分析出來的...

在分析整個頁面的平均下載量時,可以看到 WordPress 的頁面比較肥:

We get 1590 KB for wordpress=false and 1897 KB for wordpress=true.

但是在 WordPress 上未最佳化的圖片比較少,原文裡猜測是歸功於 plugin 的關係:

@amedina I wonder if this has to do with the availability of tools/plugins in the WordPress ecosystem that optimize images effortlessly, as opposed to other web development pipelines that require manual image optimization or installation of specialized tools.

所以就跑去分析了 WordPress 上使用了哪些 plugin,不過這是看 web request 以及 path 得到的,如果 plugin 是純粹在內部執行的話就看不到了:

整個分析還蠻有趣的,而且還在進行...

AWS 推出新的 Cost Explorer API,不過 API 不是重點啦...

AWS 的「New – Interactive AWS Cost Explorer API」這篇文章在一開頭就提到了 Cost Explorer API 的情況,所以他們要推出新的 API 改進:

We launched the AWS Cost Explorer a couple of years ago in order to allow you to track, allocate, and manage your AWS costs. The response to that launch, and to additions that we have made since then, has been very positive. However our customers are, as Jeff Bezos has said, “beautifully, wonderfully, dissatisfied.”

不過讓我笑出來的是選圖啊... 大概是 Jeff Barr 夠硬的關係,直接選了這張:

我喜歡這張 XD (尤其配合著出現在官方 blog 上的時候)

PHP-FIG 成立官方網誌

Twitter 上看到 PHP-FIG 成立 official blog「PHP FIG」了,放在 Medium 上:

另外有更正說明的 tweet:

是一個知道 PHP-FIG 又有什麼大事的管道...

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:

把自己的 Blog 丟上 CloudFront

因為 CloudFront 也支援 HTTP/2 了,對於效能的衝擊應該小不少。另外當初希望多用點 IPv6,CloudFront 也支援了。最後看了一下自己的流量,每個禮拜大約 380MB 與 210K requests,也還能接受。

就把自己的 blog 再次丟上 CloudFront 玩看看,不過這次只上了 Price Class 100 (只有歐美與加拿大)。之後也許來玩看看 AWS WAF,不過開起來應該就跟 CloudFront 費用差不多了?XD

先來看看效果以及有沒有 bug 吧...

Archives