Is Google killing Nexus 5 to sell more Nexus 5X?

I had enjoyed my Nexus 5 since December 2013, until last Saturday, the screen displays color noise and nothing is working.


As a “ask Google first” developer, I naturally searched the internet to see if I were the only one with bad luck.

Clearly, I am not alone.


[Many]() [others]() [share]() the same pain, and it sounds related to some hardware defects. And I saw light for free [replacement]().

So, I [contacted]() the support. After 40mins listened to the boring music from the other side of phone and followed “standard troubleshooting procedure” by a human voice, no solution, no scheme for replacement, but redirected the call to LG support with a warming message “Sorry, we don’t work on Saturday”.

As that moment, I gave up trying to find a fix, I decided to buy a new phone. I found that I could buy Nexus 5X with HKD$700 discount before May 6th, I instantly ordered it.

On Monday, I called the LG support to find out how much it would cost a fix. It requires HKD$150 for a check and will quote price after that. Then I asked Google again, fount that the cost is ranged from HKD$360 to HKD$1700, while the trade price(收購價) is about HKG$400. So, I decided to leave it right now.

Today, I get my Nexus 5X. I restore my backup, and happily put my finger at the back to unlock the phone.

Now, I plan to disassemble Nexus 5 and see if I could fix it myself. I plug the USB charger into it, miracal happens, a normal boot screen is shown. Except there are still some color noise during lock and unlock, everything is just work as before.

Therefore, I have a evil guess, did Google introduce this kind of defects in the latest patch upgrade in order to sell more phones? This coincidence is happened too close to the end of the promotion date.

Deep learning framework for writing programs

I wish there is one.

Happy April Fools’ Day!!!

Running Go Applications via Systemd

Example Go Application

Here is an example Go code to return a simple HTTP response.

package main

import (

func handler(w http.ResponseWriter, r *http.Request) {
	fmt.Fprintf(w, "Hi there!")

func main() {
	http.HandleFunc("/", handler)
	http.ListenAndServe(":8000", nil)

Save it as file goweb.go, and build it:

go build -ldflags "-s -w" -o goweb goweb.go

Upload the output file to server /opt/goweb

Systemd Unit File

Create Systemd unit file:

sudo vim /usr/lib/systemd/system/goweb.service

Here’s the file content:

Description=Go Webapp



Then run:

sudo systemctl enable goweb.service
sudo service goweb status
sudo service goweb start

Minify Hugo Generated HTML

People have been asking for this for Hugo since 30 Aug 2014, but it is unlikely having the official support any time soon.

However, it can be easily archived by using Gulp and some scripts. You can see the result from the source of this blog.

Here is the gist, which you can copy into the root directory of your Hugo website:

Then you should run the following commands to build the website with minified HTML files:

npm install
npm run build

Openstack Ceilometer Status

Ceilometer has some blueprints implemented on Kilo, and more is coming on Liberty. However, by just looking at the blueprints, it is quite hard to tell where is the project heading to.

In this post, I try to summarize my findings to give a better picture about the development of Ceilometer.

Ceilometer has scaling problem (?)

Two interesting projects are developed to address the scalability issue.


Gnocchi is a service for managing a set of resources and storing metrics about them, in a scalable and resilient way. Its functionalities are exposed over an HTTP REST API.

Gnocchi was initiated by Julien Danjou, starts as an experiment of rethinking Ceilometer metric storage.


Monasca is a open-source multi-tenant, highly scalable, performant, fault-tolerant monitoring-as-a-service solution that integrates with OpenStack. It uses a REST API for high-speed metrics processing and querying and has a streaming alarm engine and notification engine.

Monasca comes from HP and Rackspace, which consists quite a few components and some are written in Java.

Why You Should Avoid DigitalOcean

I have been using DigitalOcean since 2013, this blog is deployed on it too.

Across time, I have some annoying experience, which I find it is worth to share.

  1. Scaling-up requires downtime

    According to its guide, the first thing you have to do is to power off your Droplet.

    The downtime is proportional to the Droplet size. It means the more disk storage you are going to purchased, the longer that you need to wait.

  2. Long-running operation can not be cancelled

    Resizing a Droplet or taking a snapshot of a Droplet often requires an hour or so to running, the only thing that your could do is waiting progress bar to complete.

  3. No way to scale-down droplet

    They have a guide about “How To Downgrade DigitalOcean Droplets”, except it doesn’t work quite well.

    It is even intended to officially not support such an essential feature.

  4. Upgrading kernel is slow and painful

    Following their guide, you need to power off your Droplet first, and carefully select the kernel version that matches your Droplet downloaded one, from a very long list.

    Even worst, their kernel list is not updated frequently, you are likely could not use latest kernel.

  5. Low disk storage for higher price tiers

    The $80 / month plan offers only 80GB SSD, while Linode offers 192GB SSD.


Therefore, for any serious projects, you should not choose DigitalOcean for long-term.

However, you could still start with their $5 per month plan, once you have to scale-up, move away from it.

You could get 2 month free hosting by using my referral link to signup.

Running Arch Linux on Raspberry Pi 2

Finally, I purchased Raspberry Pi 2 for setting up my little personal experimental server.

I have heard Arch Linux ARM quite a while ago, so I decided this is perfect time to try it out.

My setup


The setup process is pretty simple.

I followed the guide on Arch Linux ARM to format the SD card.

Then I put the SD Card into the Pi, plug in the cables, power it on.

The screen is flashing booting messages, then I can login with root/root.

At this point, I have a usable Linux running without too much effort.



站在客戶的角度上考慮,支出預算和交付時間都十分重要,自然想愈早知道愈好。 軟件開發者因而就會儘早要求列明項目的功能, 嘗試分析各功能的複雜程度及大約需要的開發時間,再因應不確定因素的比例調整估算, 然後給客戶作參考。


既然稱之爲評估,當然不可能 100% 準確。 不過如果符合以下條件,要做出相對準確的評估還是可以的。

  • 項目需求十分清晰,不會改變。
  • 項目很簡單,幾小時內可以完成。
  • 所需要的功能已經做過,或有相似的經驗。
  • 沒有或極少對外的依賴關係。例如,需要要求某某公司設置服務器、等待設計師修改設計。

無奈,大部分的項目都不符合以上幾點的描述。 尤其是創新和需求不明的項目,幾乎是見步行步,很多變數。 可想而知,由此估算出的工作量自然會有較大的落差。

正因如此,在一些項目規劃實踐中,會將程序員估算的數字乘以 1.5 至 3 得出最後的數字。 聽起來可笑,但這 1.5 至 3 的範圍也是從經驗中總結出來的,旨在避免延期交貨。



現實上,自由職業者在基於價格的競爭情形中,爲求獲得工作,很多報細價。 不少客戶著眼於降低價格,經常延伸需求, 開發者很容易因此失去動力,致使交付的質素降低或延期。

按小時收費保障了自由職業者不會因爲額外的工作而埋怨, 客戶亦不需要爲多餘的估算埋單。

根據實際情況,客戶與自由職業者可協議一個較短的清算週期,從而避免一筆過的起始定金, 讓雙方能夠更容易開始合作。即使不幸合作不來,也沒有太大成本。



對比固定的預算,按小時收費似乎很難讓人知道最後的支出數字。 其實不是,按小時收費的時候依然要估算項目需要的工作時數, 以此乘以每小時的收費就可大概知道預算。