網頁

2014年5月21日 星期三

XOOPS SPAM


服務 XOOPS 的主機 CPU莫名的持續飆高。經檢查後原來是有大量的存取連線一直針對 XOOPS 的 register.php 這支程式在做連線的動作。而這支連線因為要產生亂碼的驗證碼所以才造成此困擾。因應此問題,順便對主機做了些調整。
  1. Apache新增了 mod_evasive 模組,此模組可預防大量的 DDOS 連線攻擊。相關的參考資料可參考下方的相關連結。
  2. 註冊的程序僅允許校園內的 IP才能做註冊的動作,非校內使用者則經另一管道註冊。
經此調整後,有明顯改善大量連線與 CPU 飆高的問題。



相關資料:

2014年5月1日 星期四

XOOPS頁面空白問題

這是一件很神奇的事,因為同仁反應在 news 模組內無法發表評論。這個現象後來查出來是因為在升級 2.6版本時,在 xoops.xoops_xoopscoomments 資料表沒有正確的被 update所造成,但在升級的時候應該是有按手冊的升級方式確實完成升級。解決的方式,按此篇文章第9樓所提及的,將缺少的項目新增到資料表就可以了。

上面出現的問題修正後過了幾天後。又突然發現管理者的帳號在使用閱讀全文功能時會出現空白頁面的狀況,而前一天還可以正常的使用。這現象推測有可能是同仁在調整其它使用者帳號後所發生的。也因為沒有錯誤記錄可供參考,我這就直接比對先前可以使用時的 SQL檔案。發現只要將 xoops_users{umode} 內的 nest 改成 thread 就可以正常的呈現資料了。

相關資料:


2014年4月28日 星期一

質與量

質與量是不是該劃做一個等號?

舉個例子:工程師在撰寫程式時,有快有慢。一個有經驗的工程師有可能會花了很多時間在架構一些提需求時未考慮的事宜,有時也可以很快速的完成複雜的需求。 這要如何衡量價值。

以最近在做的 dashboard 為例,呈現出每日校外換證的漂亮曲線圖。很棒的想法,但背後所付出的代價是什麼?機器的效能、coding 人員的腦汁汗水 ……等。一個頁面的執行到呈現出結果需要耗費 40-50秒,到最終的修改完成版能在 1秒內執行完成達要相同的呈現結果。同樣逹成一件事,但可以用與可以穩定的用、有效率的用那可能不會指的是相同一件事。

另一個例子,一個穩定的系統與一個常常定時出現狀況的系統:常常出現狀況的系統,負責人員很積極有效率的,可以迅速的恢復該服務,這讓使用者的印象分數是加分呢?還是減分呢?一個穩定的系統,它為什麼穩定。穩定到幾乎讓人忘了維護者的存在,維護者有做了什麼付出什麼,這是加分呢?還是減分?這又讓我想到之前看到的一篇文章,文章中在討論什麼叫好的產品。是永久不會故障的燈泡呢?還是時間到了會自動故障的燈泡呢?

相關資料:

2014年4月22日 星期二

Dashboard 溫度感測

前些天(103.04.18)開一個關於 dashboard 的會議,主要是要討論要將那些資料項目採用 Dashboard 的方式呈現。於會議中同仁提及到一個我覺得還蠻好玩的想法。

因為自從實施節能後,館內空調的溫度會設定於某一個固定的溫度。但是自從這樣做後,常常被學生反應某區太熱或太冷。當然溫度每個人的感受本來就很主觀,不過也許建置 Dashboard 溫度感測後,可以讓使用者了解所前往的區域目前的溫度,他可以有個資訊來參考,再決定要不要前往該區,也許能降低此方面的困擾。

稍微實做了一下。前端的頁面是利用 Google Chart 來產生溫度計的效果。至於後端的資料來源則仍需請廠商協助提供界接的方式。

相關資料:
 成品示意圖:

2014年4月1日 星期二

Timeline @ NTHU Library


Timeline 的呈現方式有很多種。也有許多不同的專案可供選擇。

現在要做介紹的 TimelineJS 這個就很棒。TimelineJS 中文資料不多。其實要應用它真的很容易,若將要呈現的資料選擇放在 Google Docs上,其實可以很快的將這個應用給迅速架設起來。實作的方式在它的網站上就說明了很清楚了,在這就不多做說明。

雖然可以選擇使用 KnightLab's CDN 的服務,但我的習慣還是將程式的原始碼放在自家的機器內,它的專案程式碼可以到 GitHub 下載。下載完成後,解壓縮後,在目錄內有相關的範例檔案,直接拿它的範例檔案來做修改即可。

相關資料:


2014年3月27日 星期四

Dashboard 程式的執行時間

在撰寫 dashboard 時。不知什麼原因,後端資料的產出有時結果出現的很快,有時出現的很慢。加入以下 timer 這段程式可以大概推敲出那一段程式卡住了。
  • 後端在做分析 20 多萬筆的資料,理論上在資料庫應不會反應這麼慢,應該是在於程式的寫法上。
  • 後來查找資料才明白,原來 MySQL 有自動快取( query cache )的功用,這也是 MySQL執行會這麼快的原因之一,當接收到一個相同的 SQL Query 時,會直接由先前已分析過的快取直接引用結果,所以才會出現覺得有時快有時慢的錯覺。
  • 程式加快的方式應該可以考慮以下兩種做法:
  • 後來重新將程式修改過,改成先刪除不需要的資料,將要分析的資料單獨另外寫到一個獨立的資料表內,再去做分析。分析的時間由原本的 10+ sec 變為 <0.2 sec,真的還差真多。
//PHP Timer code
//程式起始時間
$time_start = getmicrotime();
…...
//放要測試的執行程式
…...
$time_sql = getmicrotime();
$time = $time_sql - $time_start;
echo "執行SQL條件的執行時間 : $time seconds"; //輸出總運行時間

function getmicrotime()
{
list($usec, $sec) = explode(" ",microtime());
return ((float)$usec + (float)$sec);
}
//PHP Timer code EOF 

相關資料:



2014年3月26日 星期三

創新、創造價值

有想法、有創意真的很好。如果你的身份是屬於發想者而不用負責實現或收尾工作時,那真的很棒,恭喜你,提完後無事一身輕。但如果您是屬於實作者或是收尾者時,那也要恭喜你。生活中總是充滿變數,也因為如此才會多彩多姿。

看人家做事情都感覺都很簡單,待自己深入之後才會了解,發覺人家做的快、做的順、做的好,根本不是您想像中的那一回事;大家都想要自動化、系統化。最好是能讓一鍵送出所有的程序就全部完成。但其實真正能做到這樣時,有時換個角度去想想,其實應該要有警覺性。真的要開始思索或著手找未來的第二春。

創新、創造價值。不管對組織與個人都重要。記得在進入清華時,老師和我在聚餐的談話,有一句話令我印象深刻 ~「創造被利用的價值」。其實在實現這段話的過程中,就會讓你凡事都是以積極的心態去學習。沒有不可以,只是你要不要做,要不要把它做好而已。

我們要努力的培養自己習慣去問為什麼要這樣做、有沒有更好的方式可以逹到相同的效應、
努力培養自己習慣性去拆解事物,習慣性去結構化的理解事物;先培養出你的「洞悉力」,你就會發現處處是「潛在機會」。如此一來,你就是那能掌握機會、開創新局的大將之才。」這句話也很棒,共勉之。

相關資料: