每天早上掃地時,除了落葉垃圾外,總是會掃了許多螞蟻。如果馬上畚起來打包進垃圾袋,這些螞蟻可能會跟著落葉垃圾上垃圾車,然後進焚化爐,結束那短短的生命。
不忍,所以總是會隔段時間再畚,讓這些已被變故驚嚇的螞蟻懂得反應,在有限的時間趕快逃離。
有時,總是會聯想到上帝是不是也會這樣,當要有變故時,也會先給我們一先徵兆,預留一些時間,讓我們能有機會作反應。
想起約五年前很流行的一部影片《改變世界的6度C》,裡面提到每升高一度,會有怎樣的改變(內容摘錄於後),其中一個很重要的論述就是2度C會是一個臨界點,當上升超過2度C時地球暖化的趨勢將全面失控,形成惡性循環越演越烈,簡單說當超過這個臨界點後,不管做再多的努力都回不去了!
在2010年時,已經上升0.8度了,2012也來到0.85度了(有興趣的朋友可以關切這裡)。雖然有許多科學家並不認同這個氣候模型,但是已經是11月下旬的小雪日,我們仍然穿著短袖開電扇(甚至冷氣),相信大多數的人都承認這種氣候有問題了。
大部份的螞蟻會在我畚起垃圾前逃離。
老天已經給我們算是很明顯的徵兆,也給了我們時間作反應,我們有辦法作得比螞蟻好嗎?還是要繼續麻木無感,耽於逸樂,只重眼前利益?
註:摘錄自這裡
全球氣溫上升攝氏一度
- 北極圈可能半年不結冰,傳說中的西北通道打開,讓船隻通行。
- 漲潮可能淹沒孟加拉灣周遭數千棟房屋。
- 氣溫上升攝氏一度可能引發颶風開始侵襲南大西洋。
- 美國西部的嚴重旱災可能導致全球穀物和肉類市場短缺。
- 美國西部的乾旱地區可能變回沙漠般的環境。
- 氣溫上升攝氏一度,可能促成英國的農業大改變,之前無法在英國生存的農作物將開始蓬勃生長。英國如今有超過四百座葡萄園,種植通常在法國生長的葡萄。
全球氣溫上升攝氏兩度
- 格陵蘭的冰河以更快的速度持續融化。事實上,格陵蘭的雅各布港冰川(Jakobshavn Glacier)已是全球移動最快速的冰原;每隔幾天從冰河斷裂的冰塊水含量,足以供應紐約市一整年的用水。
- 因為海洋冰原減少,北極熊成為瀕臨絕種的動物。
- 昆蟲可能往奇怪的新方向遷移。舉例來說,當溫和的氣候移到美國北部,松樹甲蟲可能會摧毀廣大的白榕樹林。
- 森林開始在融化的加拿大凍原生根成長。
- 太平洋吐瓦魯群島(Islands of Tuvalu)可能被上漲的海潮淹沒。
- 當氣溫上升兩度,海洋生態系統受到的衝擊可能很嚴重;全球大多數的熱帶珊瑚礁可能會成群死亡。
全球氣溫上升攝氏三度
- 在全球氣溫升高三度的極端情況下,亞馬遜雨林可能經歷重複不斷的乾旱和火災循環。倘若我們失去大片的亞馬遜雨林,數億噸儲存的二氧化碳可能會重新釋放,可能讓全球暖化再升高一度。
- 氣溫上升攝氏三度,導致阿爾卑斯山山頂的積雪消失。
- 地中海和歐洲部分地區夏季極度乾燥酷熱。
- 隨著海洋愈來愈熱—一種極度不穩定的全球氣候模式出現,也許會反映出所謂厄爾尼諾現象(El Nino)的天氣異常。
- 假如地球溫度上升三度,下一代的超級風暴:首批六級颶風可能會出現。
- 許多科學家將氣溫上升三度,視為地球上生活方式劇烈改變的臨界點。
全球溫度上升攝氏四度
- 氣溫上升攝氏四度可能導致海平面持續上升,淹沒人口稠密的三角洲:如孟加拉和埃及等國家可能被毀滅,如威尼斯等城市可能會被完全淹沒。
- 恆河是中國、尼泊爾和印度超過十億人口的生命泉源。首先,注入恆河的喜馬拉雅山冰河融化雪水,可能會宣洩史無前例的大洪水。然而,假如冰河完全消失,也會發生極嚴重的缺水和飢荒問題。
- 研究顯示以目前的流失速度,到了2035年,喜馬拉雅山脈的冰河將全部消失。
- 加拿大北部可能成為全球最豐收的農業區域之一。
- 整個西南極大冰原可能會崩塌,造成海平面更進一步升高。
- 氣溫上升四度時,海平面可能上升超過一公尺,全球的海岸大城市將面臨大災難。
全球氣溫上升攝氏五度
- 兩個不適宜居住的巨大區域,可能延伸到南北半球原本的溫帶地區。
- 供水給全球某些大城如洛杉磯、開羅、利馬、孟買的高山積雪和地下含水層可能將枯竭。
- 氣溫上升攝氏五度時,氣候造成的難民可能會增加至數千萬人,爭奪極有限資源的潛在衝突可能一觸即發。
全球氣溫上升攝氏六度
- 當氣溫上升攝氏六度,世界可能變成像一億四千四百萬到六千五百萬年前的白堊紀時代,當時全球的氣溫比現今高許多。
- 營養素消失的海洋可能會變成亮藍色(bright blue)。
- 沙漠如同勝利大軍一般,在各大陸成功開疆闢土。
- 天災成為家常便飯,世上某些大城市可能會被淹沒或遺棄。
2015/09/25
Can't receive GCM notifications in some environments
This is a strange issue about Google push notification.
I am trying to send notifications to my APP. In office, my Samsung Galaxy Mega 5.8 (4.2.2) and Nexus 7(5.1.1) can receive the notifications with wifi connection, but the Infocus M210 (4.4.2) fail to get the notification.
To narrow the problem, I try Push Notification Tester to do the test on M210 and Mega 5.8. The M210 also misses the notifications.
I take these 2 phones home. The M210 receives all the missing notifications when it connect to the wifi in my home. I try Push Notification Tester again and both phones works fine.
All phones work fine but the M210 in my office's wifi. The M210 can work fine in home's wifi only. I can't figure out why M210 can't get the notifications in my office. Is the wifi the root cause? Surfing on the Internet, I still can't find the reason and solution yet.
I am trying to send notifications to my APP. In office, my Samsung Galaxy Mega 5.8 (4.2.2) and Nexus 7(5.1.1) can receive the notifications with wifi connection, but the Infocus M210 (4.4.2) fail to get the notification.
To narrow the problem, I try Push Notification Tester to do the test on M210 and Mega 5.8. The M210 also misses the notifications.
I take these 2 phones home. The M210 receives all the missing notifications when it connect to the wifi in my home. I try Push Notification Tester again and both phones works fine.
All phones work fine but the M210 in my office's wifi. The M210 can work fine in home's wifi only. I can't figure out why M210 can't get the notifications in my office. Is the wifi the root cause? Surfing on the Internet, I still can't find the reason and solution yet.
2015/06/11
Working with files in JavaScript
Worth to read!
Working with files in JavaScript
Part 1: The Basics
Part 2: FileReader
Part 3: Progress events and errors
Part 4: Object URLs
Part 5: Blobs
Working with files in JavaScript
Part 1: The Basics
Part 2: FileReader
Part 3: Progress events and errors
Part 4: Object URLs
Part 5: Blobs
2015/06/05
Blank window issue on Safari Mobile and a quick solution
I am working on an embedded project. The device provides simple Web HTTP interface to interact with this device. It works fine on all browsers but Safari Mobile on iOS 8.3.
Surfing on Google, there are some problems on Safari Mobile (article 1, article 2, article 3, article 4, article 5). They sound like not same as what I am facing to. I monitor the packets captured by Wireshark, and found that Safari Mobile didn't load all resources(css, js, ttf, etc.) completely causes this problem. The Safari Mobile communicates with Web server in HTTP pipeline, while the others (Chrome, Firefox, Opera, IE, Safari Desktop, etc.) don't. (The others will reuse the connection, but won't pipeline them). That is the major difference!
In theory, the HTTP pipeline can speed up requests by reducing the number of round trip times. But there are some articles(articles 6, article 7, article 8) comment on this point. This is not what I want to discuss in this page. Let's back to my problem.
The HTTP pipeline raises lots of problem. Some developers submit tickets to Apple, but there is no plan to solve the problem. I try to find
I found an easy workaround for this issue at last. This problem can be solved by setting the connection field of the HTTP response header. I force the connection field to be "close" if the browser is Safari, and it works! In Java Servlet, you can set it as
(or you can set the header field in Filter), or in PHP
or you can set the field in Web server setting.
In Safari Mobile, it will close the connection when receive the response, and won't send further requests thru this connection. That is, no more HTTP pipeline from Safari Mobile. I am not sure is this the best solution or not, but it really solve my problem.
Surfing on Google, there are some problems on Safari Mobile (article 1, article 2, article 3, article 4, article 5). They sound like not same as what I am facing to. I monitor the packets captured by Wireshark, and found that Safari Mobile didn't load all resources(css, js, ttf, etc.) completely causes this problem. The Safari Mobile communicates with Web server in HTTP pipeline, while the others (Chrome, Firefox, Opera, IE, Safari Desktop, etc.) don't. (The others will reuse the connection, but won't pipeline them). That is the major difference!
In theory, the HTTP pipeline can speed up requests by reducing the number of round trip times. But there are some articles(articles 6, article 7, article 8) comment on this point. This is not what I want to discuss in this page. Let's back to my problem.
The HTTP pipeline raises lots of problem. Some developers submit tickets to Apple, but there is no plan to solve the problem. I try to find
I found an easy workaround for this issue at last. This problem can be solved by setting the connection field of the HTTP response header. I force the connection field to be "close" if the browser is Safari, and it works! In Java Servlet, you can set it as
response.setHeader("Connection", "close");
(or you can set the header field in Filter), or in PHP
header("Connection: close");
or you can set the field in Web server setting.
In Safari Mobile, it will close the connection when receive the response, and won't send further requests thru this connection. That is, no more HTTP pipeline from Safari Mobile. I am not sure is this the best solution or not, but it really solve my problem.
訂閱:
文章 (Atom)