2009-11-28

兒童身高收費標準重新定義

行政院消保會本(11)月第171次委員會議提案報告,主要結論如下:

一、關於「兒童」之認定,應依兒童及少年福利法第2條「所稱兒童,指未滿十二歲之人」定義。依教育部所提供之94學年度國小學生平均身高調查資料,訂定參考標準:6歲兒童平均身高為115公分;12歲兒童平均身高為150公分。

二、兒童收費標準原則採以身高為初判,年齡為複判之雙重認定模式;即目測身高超過標準,消費者得出示證明文件證明其實際年齡;惟行業經營上有特殊考量,例如:航空、船舶等,無論其身高年齡,因佔據一個座位,因此無法以身高或年齡作為兒童收費之標準者,則得另作規定。惟應就其差異妥為說明,並充分揭露消費資訊。

三、各中央及地方政府對所屬機關(構)應本於權責援引前述身高規定,修正收費標準。至於一般民間營利事業,則以行政指導方式,積極輔導其配合政策執行,以符合人民期待。

換言之,如果你家小朋友超高的話,就帶著證明文件出門吧。

http://www.cpc.gov.tw/detail.asp?id=1356

2009-11-27

消基會:電子商務網站應提供個資刪除服務

終於有正義之聲了!

網站業者不提供網路帳號(個人資料)刪除服務是違法,不少網站業者提出的會員條款也不合理,例如要求消費者自負帳號密碼遭竊的法律責任。

根據現行的電腦處理個人資料保護法第3與第4條的規範,非公務機關也需要提供當事人請求停止電腦處理及利用,以及請求刪除等權利。

也就是說,網站業者沒有主動提供帳號刪除服務是違法的行為!

不過!怎麼這麼久了都沒人受罰呢?不過我想 新版個資法 如果通過後,這些網站應該也會ㄘㄨㄚˋ勒蛋吧!

再則...
資外洩有可能是因為業者的資安防護動作不夠嚴謹,因此將責任為全歸到消費者身上並不公正,消費者可以透過消費者保護法向業者提告。

文中提到〝Yam天空的會員條款有列出「若您發現帳號或密碼遭人非法使用,Yam天空不負賠償責任」,以及東森購物網路商城則是「倘有外洩而遭他人留用、冒用者,會員應自負法律責任」等。〞

坦白說,很多網站服務大同小異,我早就看到條款就打勾,不然就不能申請入會啊!真的是沒給他注意到有那些內容。

不過這也僅止於由網站業者內部或系統本身造成外洩的責任,如果是你個人疏於保管密碼(如借他人用),或者被釣魚了(請參考:網路釣魚實例解析 ),這是很難把責任推給網站業者的喔!

新聞節取自 http://www.zdnet.com.tw/news/web/0,2000085679,20143045,00.htm?feed=NL:+%AC%EC%A7%DE%B7s%BBD%A4%E9%B3%F8

網路釣魚實例解析

你會被網路釣魚不外乎有兩個壞習慣
1. 貪小便宜!
2. 偷懶!!! 習慣性按【確定】或【Y】!訊息內容都不看的 : 小胖妹 小豬頭 就是實例...

重要補充提醒:第二張圖未必每個網站都會提供相關的警告,瀏覽器本身的提醒也有可能被你關掉!請做好以下兩件事情
1. 要用滑鼠點下任何東西前務必看一下瀏覽器最下面的狀態列,確定要點的連結的網址是你要的網站。
2. 只要是需要 key 帳號密碼的地方,務必確認網址列是正確的!這部分不是"看起來"像就好,有時候 l 和 1、o 和 0 不仔細看就會死人!


一、首先你可能看到一個超便宜的東西,引起你的興趣!腦袋都不想的就按下某個 link,也許不是圖中的案例,但很可能是某個引起你興趣的地方引誘你用滑鼠去點他!


二、最大的壞習慣來囉!訊息飛出來了,卻不經大腦解讀,很多很多很多很多很多人就會習慣性按下〝左邊〞的按鈕(所以最近有些有良心的軟體,都會故意把【我接受】改去右邊,就是要試圖拯救你們!)。


三、你已經踏入賊船了!


四、蠢事正在進行,啊門~~~


五、老天保佑你,願上帝與你同在,啊彌陀佛~~~


六、好囉~你已經死了!所以下次遇到這種狀況,你確定密碼無誤,結果發生密碼錯誤的狀況,趕快去改密碼吧!!!

2009-11-26

鎖定SOHO族 微軟釋出免費軟體工具

台灣微軟表示,將免費釋出軟體工具給專門提供網站設計與開發服務的小型工作室與SOHO族。

員工人數不到10名、且業務範疇是以網站設計與開發為主的小型工作室與SOHO族也可免費使用Windows Web Server 2008、SQL Server 2008 Web、Visual Studio 2008專業版、Expression Web 3與Expression Studio 3等軟體工具3年。

三年後呢?

微軟從學校扎根的計畫非常成功,造就了台灣生產了許多 VB 高手,甚至延伸到現在 .NET 也是市場主流。
這次把腦筋動到市場上的開發者,這是很聰明的策略。如果你擔心三年後!那就直接 study 免費平台就好了,不是嗎?
如禁不起 M$ 家族產品的誘惑,投懷送抱就別後悔 ^.^

不過雲端的時代即將來臨,個人隱私的顧慮瓶頸遲早被突破,M老大有跟上腳步嗎?光是 browser 就老是改不好,要不要考慮 java 還是 google Go 呢?

新聞出自 - http://www.zdnet.com.tw/news/software/0,2000085678,20142956,00.htm?feed=NL:+%AC%EC%A7%DE%B7s%BBD%A4%E9%B3%F8

2009-11-25

[SQL]用 SQL 追殺 SPAM 留言

這種 以己之矛攻己之盾的方法 真的是很高招,目前小惡魔網站應該還沒有被盯上的價值,不過先留下武功秘笈以備不時之需。

重點說明

DELETE FROM `nucleus_plugin_tb` WHERE block=1 and url IN ( SELECT url FROM `nucleus_plugin_tb` where block=1 group by url having count(*) > 10 )

首先作者的 blog 引文是要經過審核的,所以有 block=1 其他如我們一般所認知,但是...

MySQL 不能接受子查詢中用到同一張資料表,這是 MySQL 4.X 的 bug。
目前小惡魔網站用的是 MySQL 5.X 尚未測試是否有相同的問題,不過依然有解法如下:

DELETE FROM `nucleus_plugin_tb` WHERE block=1 and url IN ( select url from (SELECT url FROM `nucleus_plugin_tb` where block=1 group by url having count(*) > 10 ) AS newtb )

順便偏題一下... o.O
這種自包查詢產生虛擬的 table 是我現在經常用到的技巧很實用
尤其像我們公司太多人在維護資料,所以產生很多資料分身相同意義的欄位
不但分散在各個地方,而且欄位名稱各有巧妙
所以我會先寫好可以 reuse 的 SQL 類似如下

insert into ...
from (select 'B121???' [color=blue]as bt_custid[/color], '814' [color=blue]as bt_main_code[/color]) bt
left join ...... on bt_custid = host.id
left join ...... on bt_custid = z84.cust_idn and bt_main_code = z84.main_code
where ...

這是一個補資料(案件)的 SQL 因為每次補充來源不一樣 所以只要在 from (...) 之內改變一下,其餘的 SQL 都可以不變
採取這個技巧 就可以省去來源不一樣時,卻使用到相同的性質欄位,而導致 join 和 insert into 之後的語法可能要跟著改的麻煩。

參考文章

facebook 感覺回來了,原來是交友不慎...

非死不可的感覺又回來了,原來是交友不慎!
http://www.imp.idv.tw/play/forum/viewthread?thread=2088#9695
今年七月看到黃小愷竟然也知道這個社群網站,當時我就覺得這網站有潛力。
於是把今年三月因為研究 http://face.com 的服務而建立的帳號 review 一下,但是很快就被黃小愷玩心理測驗的垃圾訊息灌滿我的首頁。

後來因為開心農場把非死不可炒到臭火乾,從 Google Analytics 看到養蚊子的 facebook.com 也會引導到小惡魔網站 http://www.imp.idv.tw/
這讓我好奇... 於是三不五時會上來思考融合之道,找尋可用之處。
唉...這段期間的心聲是如此
http://www.imp.idv.tw/play/forum/viewthread?thread=2186

不過近兩天有不同感受了^^
感謝柏竣熱情邀情,感謝芳銘神來一筆的建議,終於抓回 facebook fu。
今天認真研究了一下,垃圾資訊有各種解決之道^^

facebook 能在眾多社群網海異軍突出是有他的道理,他打破了網路長久以來匿名的文化。
而這樣的特性讓他成功,但也帶來新的挑戰和社會道義。

如果有名人的姓名被刻意混淆,或者造謠產生經濟損失,如蘋果總裁重病假消息造成股價大跌的事件若發生在這。所以死亡重病之類的關鍵字眼如何管控?

而這麼真實的雲端資料,和匿名文化不同之處需要被在意的課題是,即使是升斗小民當他死亡後該帳號被終止活動的程序是需要被規範的。應該如何申請?

帳號被宣告死亡確定後,所有帳號產生的資料資產應該歸屬誰,facebook 資方還是家屬呢?

facebook.com 是否還有權利繼續展示亡故作者的生平文章、照片和其他資訊,或者已經準備好接受家屬申請靜態展示了嗎?

facebook 會有有趣的未來...

2009-11-24

自動重新啟動資料庫工作排程

咱家的 MIS 因為上游資料來源(或程式)延遲或失敗,user 都上工了也只能癡癡地等上游資料跑完後,再手動執行 SQL JOB... 或者更慘的是,假日被急摳來處理...
連累小弟轄下的系統資料不夠新鮮以致無法作業,只好吃下問題單 ="=... 接著安排人跟催甚麼時候補好資料庫。
為了能安心休假只好下海找解套......

小弟我只會寫程式解決問題所以 SQL 很弱,不想常常去碰資料庫,連重新啟動 JOB 都覺得痛苦。
可是 MIS 在 JOB 內搞一堆 SQL 跑來跑去,只好配合在這個模式下找出不讓系統開發人員痛苦的未來。

原來用個簡單的 MS SQL 涵式,就可以解決這個惱人的問題了!
SQL 2000 : sp_update_jobschedule
SQL 2005 : sp_update_schedule (建議) or sp_update_jobschedule (為相容 2000 而殘留的)

只要兩個簡單的要素即可高枕無憂
1. 要能判斷是否需重新執行的方法。
2. 要建立一個執行一次的 job schedule。

你的 JOB 應該有兩個 Schedule 如下,第一個是你正常應該要啟動的、一個是當有問題的時候需要被啟動的(disable),這個 shcedule 在以下範例我命名為 reschedule


接著你要依資料庫版本查出重新啟動 schedule 的 key,以下指令請 use msdb 後執行。
如果是 SQL 2005 以上圖為例,ID 506 就是關鍵值 @schedule_id。
如果是 SQL 2000 則需呼叫 exec sp_help_job @job_name = '[JOB NAME]',以上圖為例 @job_name = 'ADM_LETTERS_COUNT (2009-11-20)'。取得 @job_id = '499235D9-4EB1-45C5-A66D-1D4D53BA1C98'

然後我以如果資料更新失敗,則一個小時後重新執行一次為例,如下:


-- 主要資料處理 SQL (建議規劃防重複執行判斷)
INSERT ADM_LETTERS_COUNT SELECT ...

-- 第一要素:設計判斷資料更新失敗的邏輯
declare @adm_data_date_diff int
set @adm_data_date_diff = (select datediff(day, max(ADMLC_DATADATE), getdate()) from ADM_LETTERS_COUNT)

-- 第二要素:判斷需要重新啟動則安排一小時候執行 (以下範例會跑到當天凌晨才停止,建議可再設計停跑時間。)
if(@adm_data_date_diff > 1) begin
declare @today int, @new_datetime datetime, @new_time int
set @today = convert(int, convert(char(8), getdate(), 112))
set @new_datetime = dateadd(hour, 1, getdate())
set @new_time = datepart(hour, @new_datetime)*10000+datepart(minute, @new_datetime)*100
use msdb
/* for SQL 2005 new function
exec sp_update_schedule @schedule_id = 506, @enabled = 1, @active_start_date = @today, @active_start_time = @new_time
--*/
exec sp_update_jobschedule
@job_id = '499235D9-4EB1-45C5-A66D-1D4D53BA1C98',
@name = 'reschedule', @enabled = 1,
@active_start_date = @today,
@active_start_time = @new_time
end

為了易懂以上簡化程式碼,其他加強的機制可以再繼續自行應用。

以下簡單舉例防重複執行判斷並不難,只要把第一要素套上來即可,如下...

declare @adm_data_date_diff int
set @adm_data_date_diff = (select datediff(day, max(ADMLC_DATADATE), getdate()) from ADM_LETTERS_COUNT)

if(@adm_data_date_diff > 1) begin
INSERT ADM_LETTERS_COUNT SELECT ...
end

set @adm_data_date_diff = (select datediff(day, max(ADMLC_DATADATE), getdate()) from ADM_LETTERS_COUNT)

if(@adm_data_date_diff > 1) begin
declare @today int, @new_datetime datetime, @new_time int
...(略)...
exec sp_update_jobschedule @job_id ...
end