老大,我要參選中和市長啦!

前兩天突發其想,以前立法委員選舉黃牛了,最近三合一選舉靠近了,換個比較容易的中和市長試試,跟女友聊到的時候,她還是百般的不相信我可以做這件事情,所以我今天開始填申請表單,也很認真的打了下面政見(規定是 600 字以內,加標點符號我打了接近 550 字,夠認真吧):

每天會經過華中橋頭,總覺得塞車的問題一直是個困擾,打開窗戶也直接可以面對華中橋上各種車輛的噪音,也許可以藉這個機會積極參與改善的過程。我的專業是資訊技術,俗稱宅男,每天就是面對著電腦過生活,10/7晚上跟女友提到這件事情,她說我不可能,所以我10/8開始打申請表單,某些方面看來這次的參選是基於維護男性的尊嚴,所以男性朋友們一定要支持啊!女性朋友呢?因為一個願意為證明自己而做這件事的男人實在不多,給點同情票也是不為過吧?特別是原本不想投票的朋友,這次有這麼清新的參選人,怎麼可以錯過!‧‧講正經的,台北市有南港軟體園區,也許中和可以在台北縣境內扮演同樣的角色,不確定以這個身份能夠推動到什麼程度,但畢竟自己就具有這樣的專業,相信可以對中和發展軟體產業有些幫助。其次,我所擅長的是將繁雜的行政程序轉換為軟體操作,也許藉著這次實際參與中和市行政運作,可以協助將許多倚賴人工處理的行政程序轉換為電腦軟體來輔助,甚至進一步透過開放原始碼授權免費將程式提供給所有人使用、研究,相信這會是自己身為資訊技術從業人員對社會的最大貢獻之ㄧ。最後,這次的參選並沒有事先安排任何競選的活動,真的有機會當選會努力讓中和市民感覺到有在做事。

就在準備相關申請文件的時候發現,那些證明文件要準備幾份怎麼都沒有寫,所以就打電話去中央選舉委員會問,接電話的人感覺非常有經驗,在得知我有意願參選鄉鎮市長同時,很睿智的問了我是哪個縣市,我說台北縣啊,他立刻回應,台北縣這次沒有選舉啊,以後都是官派的!……我女朋友說對了,我的確不可能參加這個選舉……

發表於 生活點滴, 胡言亂語 | 7 則迴響

日本PHP大會 – 投影片一覽

恩,我還是不會日文,所以很勉強的把這些資料挖出來…

ビジネスデイ 2009/09/04(Fri)

Time セミナールーム
12:00 – 12:30 開場
12:30 – 12:45 [B-1]イントロダクション日本PHPユーザ会 トライコーン株式会社 鈴木則夫
12:45 – 13:30 [B-2]NetCommonsでオープンソース・ビジネスモデルの実現NPO法人コモンズネット理事 OSSコンソーシアム理事兼CMSビジネス部会リーダ オープンソース・ワークショップ 代表 永原 篤
13:30 – 14:15 [B-3]世界標準パブリッシングプラットホーム WordPressWordPress 日本語チーム / Automattic, Inc. マクラケン直子
14:15 – 14:30 休憩
14:30 – 15:15 [B-4]eZ Publish ディスクール
– エンタープライズWebCMSに求められる機能とその実現 –eZ Systems Japan Business Development Manager 藤田 拓
15:15 – 16:00 [B-5]Oracleで加速させよう!PHPのビジネス活用
~スケーラブルで高可用性でクラウドで~日本オラクル株式会社
マーケティング本部
シニアマネジャー
伊東裕揮
16:00 – 16:15 休憩
16:15 – 17:00 [B-6]ソーシャルメディア GREEグリー株式会社 田中 良和
17:00 – 17:45 [B-7]45分で分かる、安全なWebアプリケーション開発のための、発注・要件・検収HASHコンサルティング株式会社 代表取締役 徳丸 浩
17:45 – 17:55 [B-8]クロージング日本PHPユーザ会 トライコーン株式会社 鈴木則夫

テックデイ 2009/09/05(Sat)

Time 小展示ホール (400名) コンベンションホール (150名)
10:00 – 10:20 開場
10:20 – 10:30 [T-100]オープニング日本PHPユーザ会 安藤 祐介
10:30 – 11:15 [T-101]基調講演日本PHPユーザ会 廣川 類
11:15 – 12:00 [T-102]台湾PHPコミュニティの日々Taiwan PHP User Group 江 明宗 [T-202]~PHP初心者講座~ WEB業界で生き抜くために日本PHPユーザ会
有限会社アリウープ 柏岡秀男
12:00 – 13:00 休憩
13:00 – 14:00 [T-103]APCによるハイパフォーマンスの実現Facebook,inc
Brian Shire
[T-203A]はじめてのyiimocapapa

[T-203B]PHPアプリケーションフレームワーク Agavi入門田中康一(MugeSo)

[T-203C]フレームワークCodeIgniterを使ってのアプリケーションプラットフォーム作成による、業務案件、アプリ開発の効率化について辻岡国治(kunitsuji)

[T-203D]Flash 書き換え PHP extension (第二回)山崎義弘(よや)

14:00 – 14:30 [T-104]PHP を見える化する新原雅司
14:30 – 14:45 休憩
14:45 – 15:15 [T-105]CakePHPストーリーCakePHPの何か 安藤 祐介 [T-205A]『PHP逆引きレシピ』とセキュリティのことKenji Suzuki

[T-205B]現役高校生のPHP開発菅礼紗

[T-205C]新しくなったOpenpearsotarokとriaf

[T-205D]PHP初心者勉強会について永原智聡

15:15 – 15:45 [T-106]PHP を「いじり」倒す 10 の方法moriyoshi
15:45 – 16:15 [T-107]Q4MとFlareを使ってスケーラブルなサービスを作る!漢祐介(nowel)
16:15 – 16:30 休憩
16:30 – 17:30 [T-108]Symfony, a web framework for professional websitesFabien Potencier [T-208]マイクロソフトのWebサーバー(IIS)と一緒にPHPを動かそう! ~構築手順 詳細解説と実演~マイクロソフト株式会社 エバンジェリスト 奥主 洋
17:30 – 17:40 休憩
17:40 – 18:15 [T-109]ライトニングトークス
Tokyo Tyrant + PHP小山健一郎

phpall:PHPの全バージョンの挙動を試すhnw

PHP4の現状とセキュリティパッチサービス大垣靖男

クラウド対応型フレームワーク「Monocheros」萩原崇之

初めてのPHP Extensionyokkuns

18:15 – 18:30 [T-110]クロージング日本PHPユーザ会 トライコーン株式会社 鈴木則夫

下面是找到比較完整的記錄,雖然還是看不懂

http://gihyo.jp/news/report/01/phpcon2009/
http://d.hatena.ne.jp/sakaik/searchdiary?word=*[pcj09]
http://hashtagsjp.appspot.com/tweets/pcj09/
http://d.hatena.ne.jp/suno88/20090904/1252030680
http://d.hatena.ne.jp/suno88/20090905/1252030680

發表於 活動感想 | 已標籤 | 迴響已關閉

日本PHP大會 – 第2天雜記

上午太緊張了,所以沒有即時記錄,現在開始慢慢回想那個空白的時光

這兒的主辦單位請了專業的翻譯,所以上午活動開始前,翻譯先約了我到咖啡廳討論演講內容,他的中文是在大陸學的,所以有時候台灣這邊的發音與習慣他也不是很熟悉,不過是個做事很謹慎的長者。

活動剛開始是由 Ando 開場,接著上場的是 mbstring 的開發者之一,他主要是講 PHP 的演變,內容應該很實用,只是當時我在準備席,比較緊張,因為這次日本的活動人數可不輸稍早前參加的 COSCUP 。在上場之後,因為需要講一句、等一句翻譯,所以沒辦法做太多搞怪的事情,不過也因為大部分的聽眾只會聽來自翻譯所講的東西,所以相對我的壓力就沒有那麼重了。後來陸續有人發問下面問題:

1. 在台灣的社群活動是不是也有城鄉差距,我回答,大部分的活動確實都在台北舉辦
2. 日本的網站目前開始有多國語言的需求,想要知道台灣有沒有類似的情況,我回答,在台灣,只要是大一點的網站都會想要試著發展簡體、繁體與英文等三種語言,因為台灣本身的市場狹小,所以這個問題很早就面對了。
3. 有人問到,在台灣常使用的 Framework 有哪些,我回答 CakePHP 有比較多人使用,還有 ZF 與 CI ,當然還有部份的 Symfony ,不過這時候有些人笑了,因為 Symfony 來自法國的講者也在現場,我就立刻說聲 I’m sorry ^^||

這台電腦很爭氣,電池剛好在我的最後一張投影片講完後沒電,系統自動關機,我就進入 Q&A 的時間,還好沒有出糗。無線網路也復活了,也許昨天是過熱吧?我也不知道,希望不會再跟我鬧脾氣。

在我的議程結束後,就是中午吃飯時間,下台後有兩位來自大陸的朋友主動過來打招呼,一位是來日本經營 SNS 社群網站(中日交流)與相關專案開發的,另一位是在日本留學、工作十多年的朋友,跟兩位一起去吃午餐,也很難得的在日本有機會講那麼多的中文。

下午第一個議程是來自 facebook 的講者,他也是 APC 的核心開發人員之一,針對 APC 的細節進行說明,因為我比較晚進入會場,坐比較後面,所以他講的內容基本上沒有聽的很清楚,不過投影片應該很清楚,回到飯店之後再找看看。

接著的講者是日文的講者,他講的內容有提到 xdebug 與 profiling 資料的檢視工具,投影片使用英文,在我回神的時候他就要進行 DEMO 了,看他一直在翻程式碼,但是不知道在講些什麼。原來,他是要展示 Windows 視窗的藍白故障畫面,不知道是攝影的,還是真的可以現場叫出那個經典畫面,現場拍手叫好。

講者部落格: http://1×1.jp/blog/

現在是中場問話時間,題外話,昨天那個美麗的接待小姐,今天化身為美麗的司儀,碰到的時候有問我會不會參加晚上的 party ,有這麼美麗的小姐問,我當然拒絕不了啦!其實兩天晚上都有 party ,昨天晚上是只開放給工作人員與講者的活動,而今天晚上的活動則是開放給所有人參與,可以看到更多美眉的活動當然要去啦!(女朋友還沒來,我單身 ;) )

另外,今天大家的穿著就比較輕鬆了,沒有那麼多的西裝、領帶,也有些妻兒出現,日本的小朋友很可愛 ;)

接著是 Ando 講 CakePHP ,穿著西裝外套裏面配上 CakePHP 的 T恤 感覺還蠻怪的呢…^^||

剛開始展示了從頭開發應用程式與使用 CakePHP 的差異,接著是強調 Model 對於資料庫存取的方便性,可以提高生產性、保守性?強調新手來學也是 OK 的。現場實際展示如何配置 CakePHP 應用,不過網頁伺服器不給面子,出了點狀況(網址打錯?),還好後來 OK 了。

針對進階的使用者, CakePHP 允許透過額外的 Component, Behavior, Helper 與 Plugin 做延伸,也提到了日本國內的 CakePHP 使用狀況,透過 Google Trends 展示逐年的發展情況,以及相關的書籍(有 10 本呢),

線上課程: http://d.hatena.ne.jp/i_ogi/20090418/1240044385

東京 PHP 聚會從 30 -> 50 -> 70 的變化顯示越來越多的人在使用,在國外講者前來的聚會還有到 130 個人呢,當時還帶了典型的蛋糕到現場。 Ando 也展示了自己去德國參加 CakeFest Berlin 的情況。他表示,這是個友善的社群,國內外都一樣,最後談到了 CakePHP 未來的發展,以及 10/30, 10/31 舉辦的東京 CakeMatsuriTokyo, IRC@cakematsuri ,歡迎更多人的參與。

下面這個講者是個瘋狂的人,昨天晚上他在吃飯的時候展示了自己用 PHP 設計的 Python 執行環境,雖然指令操作沒問題,但是執行效能很差,他展示了 用 Python 寫的費式函數, facebook 的講者直接輸入很大的傳入值,程式就出現記憶體片斷錯誤而停止執行,很有趣的互動。

他應該是帶來最多歡樂的講者,在投影片用詼諧的方式陳述了 PHP 這個程式語言,投影片也很華麗。接著講到了外掛部份、TSRM(Thread Safe Resource Manager),以及解釋 ZendEngine 的構造。 Compiler, Lexer, Parser, Opcode emitter, zend_op_array, zend_op, znode, Virtual Machine。接著以 htmlspecialchars() 這個函式的改造來示範如何深入 PHP 的核心,現場操作,感覺風險蠻大的,出現了兩次 compile error ,結果就暫時放棄這個。還有下一個,調整 autobox 這個神奇函式,這個已經事先準備好,所以安全過關。最後時間不夠了,所以關於如何製作 PHP 外掛就快速帶過。

接著介紹的是如何透過 Q4M 與 Flare 建立高擴充性的網站,作者是 seasar.org 的開發者,也推出了 vizoo 這個服務, vizoo 的背後就是使用 Q4M 與 Flare ,應用程式部份是使用 Symfony 。

Q4M = Message Queue for MySQL, 有點像是 MySQL proxy 的樣子,導入的環境在 MySQL 5.1 ;Flare = Memcached compatible KVS, 由 GREE 開發?可以使用 Tokyo Cabinet ,可以直接從 Memcached 轉移。簡單的說就是將讀寫分離,只在 master 寫入,接著透過 replication 分散到 slave 伺服器上進行讀取。

一般資料庫應用是直接將資料同步寫入,而 Q4M 的架構中不是同步發生的,資料的查詢都在 Slave 伺服器中進行,每 6 個小時將寫入的伺服器做替換的動作來降低風險。

Flare 的效能在圖表中似乎比 memcache 差?在同時 1,000 個連線時?當連線數量到 10,000 時, Flare 似乎有著比較好的成功率?

接著展示如何在 Symfony 中配置 Q4M 與 Flare ,Q4m 還支援任務的 priority 設定、 multi queue , Q4M timeout 最大 60 秒。

再來是來自 Symfony 社群的 Fabien Potencier ,下面的翻譯人員應該也是翻譯社的。

剛開始講者秀了一段日文, Sensio 公司的創始人,1998 年創業,現在主要使用 Symfony 與 Doctrine 提供服務。Symfony 是個 PHP MVC framework ,使用 MIT 授權,背後有來自 Sensio 10 年的經驗。Symfony 提供了豐富的線上手冊,在日本有 5 本相關書籍,每月有超過 60 萬人訪問官方網站,有超過 700 個外掛,而且每個月增加 1~2 個。它在 2007 年 1 月推出第一個版本時融合了許多專案的成果,也從其他語言學習相關的架構與技巧。 2008 年 11 月推出的 1.2 版,開始分離許多架構,像是 Forms, Routing 等等。預計 2009 年 11 月推出 1.3 版,而 1.4 版會是 1.x 的最後一個版本,主要是將不建議使用的功能都移除。

Symfony 有一般版本,只支援 1 年,也有 LTS 版本支援 3 年,而 1.4 版就是下一個 LTS 版本。SensioLabs 提供了 Symfony 為基礎的商業支援,在 2010 2/15~2/17 會於巴黎舉辦研討會。接著講者介紹幾個主要功能,展示基礎架構圖,可以透過設定檔案進行關聯插入功能。以及切換各種不同的執行環境。 cache, debug, logs, stats 4 個功能可以依據需求做切換,儘量避免在正式環境中顯示一些揭露敏感資訊的錯誤訊息,Symfony 會將這樣的錯誤轉向錯誤說明頁。

講者透過預先錄影的方式展示開啟除錯功能後的畫面操作,接著介紹 XSS, CSRF 與 SQL Injection 等問題在 Symfony 的處理方式,CSRF 只要在設定中開啟 escaping_strategy 功能就會自動處理。再來關於測試,因為你需要經常執行測試,所以它應該要自動化。Symfony 提供了瀏覽器模擬器,用來做功能性操作測試。Symfony 提供了各種格式資料的輸出介面,最新的功能還可以針對 iphone 產生適當的網頁,它也提供 REST 介面。

在 Q&A 的時間有人提到講者的公司是否提供 Symfony 1.x 到 2.x 的轉移服務,講者表示因為 2.x 有許多重大的變動,但是這樣的轉移預期會有許多難題發生。

講者資訊:
講者創立的公司: http://www.sensiolabs.com
Yahoo 使用 Symfony 提供的服務,大概有 20 萬個使用者: http://sf-to.org/bookmarks
許多服務的新版本也會以 Symfony 建立:

http://sf-to.org/delicious

http://sf-to.org/answers <== 大概會有 100 萬個使用者
http://sf-to.org/dailymotion 也是使用 Symfony 設計
明天在東京的 Symfony 活動: http://bit.ly/sf-tokyo

最後就是一系列的閃電秀,因為電池不爭氣,所以就憑印象嚕。

剛開始敲了個鑼,我有被嚇到 …

陸續是 Tokyo Tyrant, 各種 PHP 版本間測試程式的工具, Monocheros 介紹( GAE JAVA + Quercus ), 安全使用 PHP4, php extension 等等

在會議結束後還有個懇親會,也就是俗稱的 party ,講者免費參加 ^.^

這個活動在日本好像是常態,就是一堆桌子,桌子旁邊都沒有椅子,大家就站著吃,問了大陸的朋友,他說這樣子大家才容易交談,事實上也的確如此,場子的氣氛還蠻熱絡的。除了吃東西外,現場還有即時報名的閃電秀,大家都把活潑的一面展現出來,相當歡樂。最後還有猜拳競賽,優勝者可以帶走主辦單位所募得的禮品,大陸的朋友贏得了一本 Zend Framework 專書,感覺真的很棒 ;)

在日本的朋友大多使用 twitter ,有不少人在碰面時就問有沒有帳號,所以我就註冊了一個,應該會以練習英文為主:

https://twitter.com/finjonkiang

發表於 活動感想 | 已標籤 , | 4 則迴響

日本PHP大會 – 第1天雜記

恩,我的英文還需要加強

剛開始在櫃台跟美麗的櫃台小姐說英文時,其實是我自己聽不太懂,她好像誤會成自己講不清楚,真是很對不住她 ^^||

接著跟 Ando 碰面了,他(跟大部分的工作人員)穿著很正式,我穿的比較休閒(好像一直都這樣…),因為我提早到了,我表示說也許我可以先來學著怎麼辦活動,進到會場後就請他可以自己去忙沒關係,我就到處晃了。

活動現場的硬體設施還蠻齊全的,所以不需要太多工作人員,但是各種細節並不會因此顯的隨便。剛開始無線網路一直無法連上,所以請工作人員幫忙,原本以為是自己打錯字,後來才發現原來是白板上的 q 寫成了 g ,同時也發現桌子的電源是沒有接到電力來源的,因此提醒了 Ando ,他也很快的請工作人員修改,並且請美麗的司儀宣導電源線的問題,他跟另外一位工作人員也前來跟我道謝,讓我覺得有些不好意思 ^^||

活動一開始會逐一念出贊助廠商的名字,講者問話時下面的人還蠻配合舉手的,這是跟台灣比較不一樣的地方;當然,最不一樣的地方是他念的東西我都聽不懂,所以只能根據觀眾的反應來猜他講些什麼東西。有些英文可以聽出來,不過有很濃厚的日本口音。

第 1 個議題是 NetCommons ,看起來好像是一個開放原始碼的 CMS ,不過並沒有英文版本,這是基於另一個日本的 Maple PHP framework 所設計,不過 Maple 似乎在 2006 年後就沒有繼續發展了?(不確定)。根據 Wikipedia 取得的資訊, NetCommons 1.x 是基於 XOOPS 開發,使用 GPL 授權,而 2.x 基於 Maple ,改用 FreeBSD 授權,包含許多常見的功能,安裝簡易。好像是某個單位的成果?(看不懂簡報的人…)

恩,第 2 個穿西裝打領帶的講者,下面開始有人在打瞌睡嚕。…恩,網路也在這個時候掛掉了,可能太多人在連線吧

NetCommons 相關連結:
官方網站 – http://www.netcommons.org/
開發單位 – http://www.commonsnet.org/
Maple 網站 – http://kunit.jp/maple/
範例網站 – http://hitsuji.atnifty.com/osws/

http://opensource-workshop.jp

http://ja.wikipedia.org/wiki/NetCommons

講解 WordPress 的是個美女呢,精神突然來了(雖然一樣聽不懂她講什麼) ;)

WordPress 是從 b2 延伸而來,接著發展 wordpress.com 服務,跟 Automattic, Inc. 有關?

Technorati 統計,前 100 大熱門部落格中,有 36% 使用 WordPress ,緊接在後的是 Blogsmith ,而 wordpress.com 也是 Alexa 統計中流量排名第 19 位的熱門網站, 在  Quantcast 的統計,2009 年4月有 12 億次的點擊,2009 年 5 月大約 700 萬不重複的人瀏覽過網站,有 950 個以上的外掛與 6300 個以上的佈景

mixi engineer’s blog, ebay, yahoo anecddtal, wired magazine, tech crunch,

icon dock? p2theme.com, BuddyPress, Tasty Kitchen,

講者的連絡方式:
Happiness Engineer
naokomc@gmail.com

http://detlog.org/

twitter: @naokomc

…好像不是無線網路掛掉,好像是我的無線網路卡掛了,天啊…

剛剛跟隔壁的姊姊聊了一下,她有使用 PHP 的應用程式,也有設計 Flash ,只是想學 PHP 所以前來這個活動,她還熱心的跟我介紹了另一個在台灣的朋友,是玩音樂的,只是我不熟這一塊…^^||

接著是 ezPublish 的講者,使用蘋果電腦

eZ publish 的 API 已經可以跟多種應用連線,甚至包括 SAP ERP 呢!還展示了以 ODT 格式匯入、匯出的功能,也有 AJAX 形式即時排列版面元素的能力。在 4.x 可以使用 CouchDB 作為 Archive 資料的儲存,可以跟 Oracle 結合,而 Oracle XE 是不用錢的(雖然有功能限制),

Dolly Dimples, CMIS, ELLE 在各國的網站都透過 ez publish 進行管理, ezpedia.org, ez-teamroom.de, http://ezpublish.jp

隔壁那個姊姊的力氣比我大,地板的電源線我拔不出來,但是她居然拔出來了 -.-||

接著是 Oracle 的工商服務時間,發現桌子的電源好像有點問題,隔壁的電腦沒電了。這個 Oracle 講者的技巧比較好,只用簡單的投影片,然後全憑一張嘴嚕,現場氣氛變得比較歡樂些。會場後方的電腦螢幕訊號好像也不見了,今天狀況不少。

那個打瞌睡的仁兄又開始了,我想他的點頭頻率可以拿來作為講者的評分工具,至少剛剛美女講話的時候他沒有點頭呢 ;)

Oracle 的 DEMO 是在 Amazon EC 2 上面建置 Oracle XE 的環境,換個人講,也許剛剛那個是業務、這個是工程師吧。登入了 Amazon 的 AWS 介面,從網頁進行虛擬機器的管理。進入後點選 Launch Instance Wizard ,選擇 Community AMIs ,用 oracle-corp 當作關鍵字就可以找到,點選 Select 按鈕就可以開啟。接著輸入使用的 CPU 數量、選擇群組送出後就完成了。可以從左手邊的 instances 找到剛剛新增的項目,將它啟動(跟開機一樣需要一點時間),在項目的資料中有 public DNS 的資料,可以用來做連線。完成後使用 putty 遠端登入進行測試。

1. 切換為使用者 oracle
2. ps -ef 檢視執行中的程序
3. sqlplus /nolog
4. connect sys/oracle as sysdba
5. select * from v$version:
6. url:8080/apex 可以登入到網頁介面的資料庫管理工具

Oracle demo 的 API 編號: ami-7acb2f13

又有一個美女講師上場啦,不過她只是上去測試,希望她不會只是工作人員

GREE
- 個人趣味的經營?
- 2004 年 12 月開幕
- 2008 年 12 月上市
- 108 個員工平均年齡為 29 歲
- GREE 是 SNS 網站,展示釣魚、虛擬人物等遊戲
- 有專門的團隊去監控遊戲內容,避免有惡意的內容出現
- 競爭者包括 mixi ,不過那個統計的時間表有點問題,好像是未來的資訊,應該是 roadmap ,但是會讓人誤會 GREE 跟另外兩個市場先行者的差距不大
- 20090630 的註冊人數 1260 萬人, 20 歲以上會員的比率是 75% ,  2008 年以來增加了 706 萬人
- 2009 年 6 月預估第 4 季收入為 5144 ,收益為 2631 ,單位百萬日幣(看看就好)
- 希望將 SNS 的魅力帶到非電腦領域,像是 NintendoDS 、PSP 等等
- SNS as a platform
- 目標朝 2,000 ~ 3,000 萬人前進,希望未來可以朝著世界性網站發展

講師的中氣很足,聲音比剛剛的講師都來的大些(還是因為音響調整過?)

…看到那個美女在拍照…她應該只是 GREE 的工作人員,真可惜, PHP 產業少了一個生力軍

隔壁的姊姊熱心的問,如果需要翻譯的話,可以跟她說,我說沒關係啦,有些字看的懂,只要知道部份資訊就好了

這個感覺也是工商服務時間,肚子有點餓了,還好外面有免費的可可能喝,阿不然就這樣溜走應該會被 K 吧 ;)

這個講者一直講,他難道不知道一個只看的懂日文漢字的人是很需要更多投影片的;不過也算了,工商服務的內容應該跟技術沒什麼關係。

議程的安排是一個社群議程搭配一個贊助商議程,這樣子可以避免兩種議程過度分開讓參加者不願意參與贊助商提供的議程,有助於吸引贊助商的參與(如果到了他的議程發現人都走光了,下次贊助應該就不會有他了)

好,可以確定這個講者的內容不是很好聽,因為那位仁兄又睡著了,這種評估指標真方便 ;)

但是隔壁姊姊卻很賣力的打起記錄來,想必這個講者的資訊無法吸引工程師的注意,隔壁那位也許是行銷專長的姊姊。(希望那個姊姊不是在練習打字,或是剛好有人在 MSN 上面敲她…)

開始有些人離開了,可能因為工商服務的內容太多吧

那個美女看來是 GREE 講者的助理或秘書吧

HASH Consulting Corp. ,講網頁介面應用開發的安全性

一開始談的是發案者如何在合約上面寫明,開發者需要為應用程式的安全性負起責任,真是高明…

RFI/RFP 的 3 個重點
1. 提案的要求
2. 功能細節的描述
3. 稽核的提示 – 也許會有第 3 方公司進行檢查

使用 Prepared statement ,避免直接在程式中使用 SQL

這個講者的公司看樣子是以第 3 方稽核者的業務為主,目前的講稿都是在說專案發包的一些注意事項,特別是跟安全性有關的部份,原本以為是要討論資訊安全相關的技術。

專案條件的設計主要考量3個方向,機密性、完全性、可用性

WAF, IDS/IPS 入侵偵測與入侵保護, SSL

相關網址:

http://www.ipa.go.jp/security/vuln/websecurity.html

脆弱性診斷.jp

發表於 活動感想 | 已標籤 , | 1 則迴響

0711, 0712 工作坊 CakePHP 課程

在課程開始前自己有針對課程做了個劇本,原本還擔心這個劇本無法支撐 6 個小時的課程,但經過這兩天實際進行後才發現,我擔心太多了,因為很多劇本以外的狀況,而即使那些狀況都不發生,把那些東西一股腦的塞給來參與的朋友似乎也太多了,因為大部分人對於 CakePHP 都僅是粗淺的認識,也有部份朋友對 PHP 並不是那麼熟悉,所以一直在調整自己的腳步,在第一天就顯得有些渾亂,第二天好一些。

在這兩天開始時都是針對基礎環境的建置做介紹,目的是希望參與的朋友回到家都能夠重建這些環境進行練習,所以上午的步調都明顯緩慢些;在電腦教室的環境也是有許多狀況,因為使用 xampp 的隨身版本,發現它對於環境的兼容性不是很好,而部份電腦因為已經裝過 xampp 的安裝版本,設定也出現混淆的情況,當然,也有些沒有跟著步調進行而出現的設定錯誤或是意外狀況,所以第一天在上午只有把環境建置完成,並且丟了個 hello world 。第二天因為有了些經驗,雖然也是狀況不斷,但進度比較穩定些,上午課程結束時已經完成了第一個範例的實做。

第一天下午只把單一資料表的存取、查詢等功能完成,進一步要介紹檔案上傳的處理時,發現時間已經差不多了,所以就直接打斷,進入 Q&A 的時間;第二天則是調整方向,略過檔案上傳的處理,直接切入兩個資料表的關聯處理,進一步的作到關聯資料編輯流程的修正,算是比較像樣些。在第一天的人數與問答比較多一些,第二天就相對沉默,可能也是人少一點吧。

課程的進行方式就是一步一步推進,我進行一些操作,藉著請參與的朋友在自己電腦進行同樣操作,在後面的實做部份也另外透過 ftp 方式讓所有人可以直接存取我所展示的程式碼,減少因為程式碼繕打所需要的時間。只不過因為程式碼都是現場輸入,所以沒有針對程式碼的細節多做說明,只希望有心的朋友可以拿著疑問去比對官方手冊,畢竟 6 小時要吸收這些東西是有點痛苦。依據過去的經驗,過度著重在概念的陳述時會發現下面朋友持續點頭或兩眼無神的情況,所以這一次大量的進行實務操作,但也相對的在概念的建立上就顯得薄弱,這算是兩難吧。

比較對不起參與朋友的地方是,我沒能夠有太多的前置時間做準備,上個星期還去高等法院洗了個三溫暖,所以準備的部份確實不足,只能希望這兩天參與的朋友能夠有一個開始的印象,藉此作為繼續深入的起點。 ;)

環境建置對於這種短暫的教學活動確實會有不小的影響,有朋友建議使用 VM 建置基本環境,讓教學活動可以聚焦在必要的操作之上,也許未來還有機會時可以透過這樣的形式。這兩天最大的遺憾是有不少朋友報名了卻未前來,這也是在台北辦活動的一個難處,台北人太忙了,所以經常沒辦法照著行程走,降低一些活動舉辦的意願。

這兩天的課程也需要感謝 Openfoundry 提供的機會以及 Freddi 細心的安排與為兩天活動的紀錄開了個頭,有興趣的朋友可以參考:
http://of.openfoundry.org/kwiki/ossfworkshop/index.cgi?WorkShop-0711
http://of.openfoundry.org/kwiki/ossfworkshop/index.cgi?WorkShop-071112

James 也針對第一天上午的環境建置提供了紀錄:
http://code.google.com/p/zf-tw/wiki/SettingUpCakePHPEnv

如果時間允許,也許會找時間做些整理吧;總之,這兩天的活動結束了,好好睡覺去 ;)

發表於 活動感想 | 已標籤 , | 5 則迴響

聊聊平行處理

雲端運算這個新名詞掀起了不少熱潮,但是平行處理的概念很早就存在了,只是很少被廣為討論。

目前比較開放、熱門的就屬 Erlang 與 Hadoop 兩個專案,而許多廠商相繼推出的解決方案雖然使用了相對熟悉的程式語言(GAE 支援 Python 與 Java 、Aptana 支援 PHP ),但是因為各家廠商之間缺乏互通性,轉移不易,急著卡位不知道會不會反而哪天變成被掐著喉嚨 ^^||

平行處理所帶來的好處對程式設計師而言是非常具有吸引力的,因為執行效能會隨著節點的增加而線性成長,而且基本上不需要改寫程式;目前一般的程式開發都會遇到類似問題,剛開始為了方便而將大部分的服務放在同一台主機,在效能遇到瓶頸時就開始把各種服務分離來提升執行效能,接著就是各種形式的快取,或是各種複雜、交錯的解決方案,令人感到沮喪的是每個轉換過程都意謂著大量的程式改寫,對程式開發單位而言可以算是個夢靨。

平行處理是否是萬靈丹?好像也沒這麼神奇,畢竟平行處理領域像是個蠻荒地帶,一些在傳統程式語言唾手可得的資源,在平行處理的世界中好像都得自己來,所以很難去比較說到底是一直重構傳統程式快還是直接以平行處理的環境進行開發快。

平行處理的需求也讓硬體的發展出現變化,以知名的超級電腦為例,台科大靠152 台DL 145 G5 Server 才做出 0.92 teraFLOPS 運算速度 ( http://www.cc.ntust.edu.tw/front/bin/cglist.phtml?Category=88 ),而昇陽 Sun Blade X6275 可以在42U機架上透過 48 台伺服器主體支援總計768個處理器核心,最高效能可達9 teraFLOPS。NVIDIA Tesla S1070 更是基於 GPU 技術的突破,在 1U 主機上就可以提供 4 teraFLOPS ,具有 960 個運算核心,同樣的機架可以提供超過 168 teraFLOPS 運算能力。

從硬體的發展看來,軟體開發走向平行處理是必然的趨勢,就看自己什麼時候覺醒了 ;)

發表於 胡言亂語 | 已標籤 | 迴響已關閉

當幸福來敲門 – The Pursuit of Happyness

當你覺得自己的人生糟透時,可以試著看看這部電影,你會發現自己還算是幸運的。 ;)

主角是一個經濟不是很寬裕的黑人,將自己畢生的積蓄壓在數十台的醫療機器上,希望能夠改變自己的生活。但現實沒那麼理想,那樣的機器不是很容易賣,因此反而讓他們的生活陷入困境;在這個期間,他跟妻子有了孩子,經濟負擔更加沉重,也讓兩個人經常為了經濟問題發生爭執。

在他努力販賣機器的過程中,偶然遇到了一個開著時髦跑車的成功人士,向他請教,得知他是基金經紀人,於是留下了深刻的印象;在業務狀況沒有起色時,他試著要去應徵基金經紀人的工作,這時才得知培訓過程是沒有任何薪水的,加上錄用機率不高,因此他猶豫了。

現實狀況越來越嚴峻,但當他發現以現有的方式即使再怎麼努力也無濟於事,他渴望改變。

他接受這個培訓過程,但是培訓過程他還是儘量爭取時間去販售機器,另外,他老婆也在這個過程離開了,他爭取將孩子留在身邊,於是他還得在極為緊湊的行程中撥出時間來給孩子。最大的低潮莫過於政府強制從銀行剝奪了他好不容易累積的一點積蓄,他幾乎瀕臨破產,他跟孩子過著像個遊民一樣的生活,即使是這樣的情況,他還是盡自己所能的去維持自己在基金經紀人的培訓成績,那種幾乎看不到明天的生活,他還是抱著積極的態度面對。

最後他被錄取了,這是人生最大的轉折,影片也接近尾聲。他後來的確成了成功人士,但是如果這段過程他有一絲絲鬆懈,恐怕會讓低潮的情況更加嚴重。

努力不一定會那麼快看到成果,但是一旦放棄努力,就等於失敗吧。

發表於 電影欣賞 | 2 則迴響

[翻譯]Git 與 Mercurial 的分析

本文翻譯自下面網址:
http://code.google.com/p/support/wiki/DVCSAnalysis

注意:這個分析在 2008 年夏天進行,起因於 Google Code 評估加入分散式版本管理功能

摘要

這份文件總結了 Google Code 在希望加入分散式版本管理功能所做的初步研究,基於普及性,只考慮了兩個分散式版本管理系統: Git 與 Mercurial 。這份文件說明了兩個系統的功能,也提供一個將它整合進 Google Code 所需要進行的工作。

分散式版本控制

在傳統的版本控制系統,一般會有一個集中的資料庫控管所有記錄,用戶必須與這個資料庫互動來驗證檔案的記錄、檢視其他分支與提交異動。通常用戶端會複製一份資料進行處理,但是這個版本並不會儲存早期版本與其他分支的資料。

分散式版本管理系統(以下簡稱 DVCS)使用了不一樣的結構,使用 DVCS 時,每個使用者會有一個本地端的資料庫、完整的專案異動記錄、分支等等,切換到不同的分支、檢驗檔案異動記錄或甚至提交異動都是在本地端進行操作。而個別的資料庫間可以透過推(push)與拉(pull)操作進行資訊的交換,一個推的操作會將本地端的部份資訊傳送到遠端資料庫,而拉的操作則會將遠端的資料複製到本地端資料庫。需要注意的是,沒有任何一個資料庫具有較高的權威性,兩個資料庫也許都會有些本地端的記錄還不會出現在另一端,任何的 DVCS 系統都有一個關鍵性功能,就是讓資料庫可以清楚傳達本地端所擁有的記錄(以及它所需要的記錄),而 Git 與 Mercurial 兩者都是透過 SHA1 雜湊值來檢驗資料(檔案、目錄結構、版本異動等)。

DVCS 讓開發者在工作流程上有更多的彈性,他們可以用傳統版本控制系統的習慣進行操作,也就是透過一個集中、具有權威的資料庫讓開發者進行同步;而對於比較大的專案,它也可以提供具有階層關係的資料庫,只要每個資料庫的維護者允許來自下層開發者的異動以及將這些異動提交給上層。 DVCS 還允許開發者彼此間分享工作成果,例如兩個開發同樣功能的開發者可以在相同的分支上進行開發,但是兩者之間成果的分享不需要透過一個權威性的伺服器;當他們完成了開發,就可以將成果推到公開的資料庫,讓更多人使用。

因為沒有集中的資料庫,所以不會有所謂的主從架構,當談論到兩個資料庫時,一般是指本地端與遠端,而不是伺服端與用戶端的關係。不過在 Google Code 實作的概念中,在 Google 的資料庫還是會被當作伺服端,而使用者的資料庫會被稱為用戶端。

功能比較

事實上, Git 與 Mercurial 有許多相仿之處,因此在這裡不會提供兩者都有的冗長功能清單,這個部份希望點出兩者間顯著的差異。

Git 的優點

* 用戶端儲存管理, Git 與 Mercurial 都允許使用者選擇從其他資料庫拉回分支,這提供了一個前端結構來減少本地端儲存的異動記錄。除此之外, Git 允許捨棄較早拉回的分支, Git 還允許從本地端資料庫將舊有的版本異動刪除(同時仍然會保留這些分支的最新版本資料)。而在 Mercurial ,如果一個分支是儲存在本地端資料庫,所有版本異動(從最初提交的版本)都必須存在,除了建立一個新資料庫選擇性將分支推進資料庫外,沒有辦法刪除分支資料。雖然他們正在開發這個部份,但是還沒正式推出。

* 父階層的數量, Git 在合併時支援無限數量的父階層版本異動,而 Mercurial 只允許兩層。如果希望在 Mercurial 做到 N 階層合併,使用者必須執行 N-1 次的兩層合併,雖然一般合併 N 個父階層資料時會建議採用 Mercurial 的作法,但使用 Git 時使用者可以一次完成。

* 分支點變更(Rebasing), Git 提供一個 rebase 指令,可以在一個本地端分支修改分支點到一個較新的版本,例如某個人在開發一個產品的新功能,本地端分支也許已經從 1.0 版開始,而如果開發過程主要的產品線已經更新到 1.1 ,也許需要將 1.0->1.1 的異動拉回本地端功能開發中的版本,並且將分支點從 1.0 改為 1.1 。在其他系統中,會透過合併 1.1 的異動進入分支,合併也是從版本控制系統角度看來正確的事情,如果將焦點放在"過去狀態的重製能力"。不過如果焦點是 "製作一個簡潔的軟體改版記錄" ,分支點變更有時會比較好。 git-rebase 允許讓一個過去未連續的異動記錄能夠連貫,讓異動記錄可以簡潔些。正確的說,這個功能其實是將 1.0 版的所有異動個別提交到 1.1 版,分支點變更功能是安全的執行這些操作,並且刪除 1.0 版,因此不會讓樹狀結構變得混亂。

備註: Mercurial 在這份文件完成後已經有加入了分支點變更功能。

Mercurial 的優點

* 學習曲線,基於許多的事實, Git 跟 Mercurial 比起來有著比較陡峭的學習曲線。 Git 有比較多的指令與選項,這些功能的說明可能會讓新使用者備感威脅。 Mercurial 的文件對於新手來說相對完整與容易閱讀,Mercurial 的用詞與指令也比較接近 Subversion 與 CVS ,因此對於從那些系統轉移的人們來說會比較親切。

* 支援 Windows , Git 有著強大的 Linux 包袱,在 Windows 執行它的正式作法是透過 cygwin ,對於一個 Windows 使用者來說不是非常理想。一個使用 MinGw 改寫的 Git 漸漸受到歡迎,但是 Windows 在 Git 世界中仍然是一個次等公民。在有限的測試中, 使用 MinGW 改寫的版本看來提供了完整的功能,但是有點遲鈍。一些在  Linux 或 Mac OS X 幾乎是即使反應的操作,在 Windows 中可能需要十幾秒。 Mercurial 是使用 Python 開發,而且正式版本在 Windows 下執行順暢(在  Linux, Mac OS X 等系統也是)。

* 維護, Git 需要定期維護資料庫(例如 git-gc),而 Mercurial 不需要。不過需要注意的是, Mercurial 對於用戶端磁碟空間的管理也比較沒那麼複雜(可以參考上面關於用戶端儲存管理的說明)。

* 記錄是不容侵犯的, Git 非常強大,可以執行任何你想做的事情,不幸的是,這也意謂著 Git 也很容易遺失記錄。舉例來說, git-push –force 會讓遠端資料庫的版本異動消失;Mercurial 的資料庫結構比較像是不可變物件持續成長的集合,雖然在部份情況下 (像是 rebase) ,改寫記錄是有優點的,但這也很危險,可能會導致無法預期的結果。不過需要注意的是, Git 伺服器可以透過設定來避免遺失資料,所以 Mercurial 這個優點並不是那麼明顯。

其他差異

* 檔名更改/複製的追蹤, Git 並不會明確的追蹤檔名更改與複製,取而代之的是像 git-log 指令用來比對資料庫記錄中是否有同樣的檔案來推論檔名更改或複製。 Mercurial 以比較熟悉的形式,提供明確的檔名更改與複製指令,並且將這些操作儲存到檔案的記錄中。 兩種方式各有其優缺點,哪個比較好並沒有比較明確且普遍的答案。

* 架構, Git 原本是以 C 設計的大量 shell scripts 與 unix 指令,隨著時間推演,在指令間共用的函式庫已經開發完成,許多指令已經內建在主要的 git 執行檔。 Mercurial 大部分是用 Python 設計(少部份使用 C),包含一個外掛的應用程式介面,允許透過自行設計的 Python 模組加強 Mercurial 功能。

* 私有記錄,在 Git ,開發者操作的預設模式是使用自己本地端(與私有)的標籤、分支與版本異動,而且在公開後可以運用許多控制。而 Mercurial 強調另外一種方法,預設的推/拉行為會共享所有資訊,如果只想共享一部份就需要額外的步驟。這沒有列在任一系統的優點,因為兩者都支援另外一種操作。

* 分支命名空間,在 Git ,每個資料庫有自己的分支命名空間,使用者可以設定本地端分支名稱與遠端對應情形。在 Mercurial ,所有資料庫共用一個分支命名空間。

實作考量

資料儲存

Git 與 Mercurial 內部使用非常相近的資料:檔案版本異動與少量的後設資訊(父層資料、作者等),兩者都有代表整個專案提交的物件,這些物件也都有版本記錄。兩者都有記錄每次提交所有檔案的版本。在 Git 使用的是一個樹狀物件 (一個樹狀結構,包含目錄的樹狀物件與檔案版本參考的樹葉結點)。在 Mercurial ,使用一個物件清單(一個對應路徑名稱到檔案版本物件的清單)。除了物件清單與樹狀結構的差異外,兩者在物件的搜尋與走向都相當接近。

Git 直接在檔案系統使用一個儲存物件的集合 (透過 SHA1 雜湊索引) 並且將多個物件打包成更大的壓縮檔;而 Mercurial 使用一個改版記錄結構 (基本上是一個連續的改版差異,加上定期的完整版本備份)。在實作時都不會使用原本的儲存方式,物件都會儲存在 Bigtable 中,基於 Git 與 Mercurial 在基礎資料物件的相似情形,無論使用哪個應該花費的時間一致。

在資料儲存時的唯一主要差異是使用的語言,如果要重複運用大部分 Git/Mercurial 的程式碼, Git 的部份需要使用 C ,而 Mercurial 則是使用 Python (或也許是 C++ 與 SWIG 的結合)。

Mercurial 整合

Mercurial 在遠端資料庫的推拉操作提供基於 HTTP 不依賴狀態特性的良好支援,開發者花費了許多精神在減少用戶端與伺服器間往返檢查需要交換的資料,且一旦完成檢查,所有相關資料會集合起來一次大量傳輸,這符合了 Google 的架構,所以在用戶端不需要任何改變。

Git 整合

Git 包含了推向 HTTP 的功能 (與推向 WebDAV ),但是程式假設伺服器端對於 Git 沒有任何準備,它的設計是以 Apache 將 Git 資料庫當作靜態檔案的情況下,這個方式需要大量為了同步化的請求往返,不適合用在 Google Code 。

Git 也提供了一個自訂的、依賴狀態的協定,支援比較快速的資訊交換,但是不符合 Google 的架構,因為 Google 非常需要不依賴狀態的 HTTP 協定,因為已經在這個架構上投入了大量資源讓它穩定且有效率的執行。

備註: 在這份文件完成後 Git 社群已經開始有些改善 HTTP 支援的討論。

總結

基於實作上的差異, Mercurial 有著明顯的優勢,因為它對於 HTTP 傳輸協定的支援。

不過就功能性而言, Git 確實比較強大,但也相對意謂著使用上更加複雜。

發表於 程式設計 | 已標籤 , , | 12 則迴響

4/25 Google Taiwan 辦公室半日遊

因為老師的關係, 4/25 有幸可以參觀 Google 在 101 大樓上的辦公室,為了要紀念這難得的一刻,我把之前在 YDN Open Party 拿到的 Yahoo 短 T恤跟電腦背包都穿在身上,一整個就是挑釁的味道,可惜現場只有 Google 台灣區的業務總經理,沒有看到其他員工,效果大打折扣。 ;)

其實老天真是有眼的,知道我的心態有問題,所以賞了一個莫名其妙的濕冷天氣,讓我感受一下寒風中穿著短袖排汗 T 是什麼滋味;原本打的如意算盤是可以停在新光三越 A8 館地下停車場,然後透過大樓間的空橋乾爽的走進 101 大樓,誰知道停車場的管理員在我停好車想要找電梯時告訴我"先生,現在管制中,如果不是員工就得麻煩您離開",原來,他們在 11 點之前是不給人停車的…

雖然後來在 101 大樓附近也找到一個地下停車場,但是這個停車場離目的地還有一段距離,我沒帶傘、沒穿外套,那個雨衣沒有雨帽,所以完整的防護必須要連同唯一的安全帽,加上…你知道的,放在車廂裡、偶爾才洗一次的雨衣總是會有那麼些味道,我完全放棄了唯一能夠擋雨、禦寒的方案,帥氣的維持短袖上衣走出停車場,…真的很冷。

在一樓等待人們到齊的時候,意外發現原來 Ubuntu 背後的 Canonical 公司在這兒也有租用辦公室,不過游總驕傲的說,目前這棟大樓最高的辦公室就是 73 樓的 Google Taiwan ,再上去到觀景樓層間沒有其他辦公室(是價格問題?)。

剛進去辦公室就看到手足球檯,應該很少有公司會把這東西放在接待空間吧。據說每個員工都可以看到窗外的美景,能夠天天從 73 樓往窗外看的感覺還蠻不賴的,某個窗邊還放著高倍率的望遠鏡,無論想要看淡水河出海口還是某個高級住宅的貴婦生活起居都是輕而易舉,我想它有激勵 RD 部門加班的效果。

當天的活動主要是展示一些一般人比較少見的 Google 應用,不過對我好像沒那麼陌生,只有在結束時問了個問題,就是接下來會不會在校園間舉辦些 Android 的推廣活動,他表示目前沒有這樣的計劃,人力很難撥出來做這種事情,加上連鴻海都主動找上門時,他們似乎也不需要什麼推廣活動。

游總也透露, Google 的人事任用需要經過層層關卡,中間最長會需要 1 年半左右(他說他是 1 年的那個),所以收到 Google 的面試訊息時不要急著辭去現在工作,也許要經過相當漫長的關卡。他們將世界所有學校區分為 3 個等級,畢業的學生要想進入 Google , A 級學校平均要有 A 的成績,而 B 級學校要有 A+ 以上的成績,至於 C 級學校目前人事緊縮的情況應該不會考慮。仔細想想,我畢業的那間應該是 C– 吧 -.-||

總之,去逛過了,沒有機會在最高的辦公室工作,至少也看過裏面長什麼樣子了,接下來就看看自己的努力能夠把距離拉的多近 ;)

發表於 活動感想 | 已標籤 | 迴響已關閉

曾經在單車小站消費過的朋友請小心詐騙電話

剛剛接到一通自稱是單車小站服務人員的電話,大致內容是說要取消分期刷卡簽單,雖然想也知道是詐騙,我就多跟她互動了一下,發現她對於我的交易內容還蠻清楚的,只是她並不知道我回答的內容有刻意造成的錯誤,因為飯已經送上桌了(我在便當店接到),所以就揭穿她是詐騙的事實,她還回覆說"你確定嘛?你有證據嘛?如果不是你要負責喔!",看來他們的講稿已經可以包容各種不同的回應,聽口音也不像是大陸人。

來電顯示是台南的號碼沒錯,只是現在這個號碼是可以變造的,所以打回去的意義不大。

大致可以猜出資料外流的兩種途徑: 經手的員工或是帳號被入侵 ,因為我是直接透過 Email 完成交易的。

回到家之後就打電話給單車小站的人員,要他們趕緊修改密碼;也把資訊提供給 165 反詐騙專線。只是基於不希望真的有人受騙,加上單車小站確實沒有做好個人資料保護的工作,所以選擇把資訊公開。我的 Mobile01 帳號好像已經被鎖很久,有帳號的朋友就麻煩將資訊轉到那上面吧。

發表於 生活點滴 | 迴響已關閉