Sziyu@Blogger

Test

2008-09-14T18:34:00.000-07:00

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Google Maps JavaScript API Example

我們已經一起攜手走過...

2008-04-08T18:59:00.000-07:00

基層工作隨身查~找工作、找幫手一次搞定！

2008-04-06T20:31:00.001-07:00

IE被www.888.com綁架解決方法

2008-03-16T18:47:00.000-07:00

詳細原文可看:我的IE被綁架了!!

看來是因為MSN Plus的原因...

GWT RPC 架構

2008-03-13T22:24:00.001-07:00

這誰敢買啊

2008-03-13T21:55:00.001-07:00

[轉貼] 該學那些程式語言2008版

2008-03-13T20:36:00.000-07:00

原文出自:愛德華日誌
文章網址:該學那些程式語言2008版

這主題向來是討論區上常被提出的問題，一言以蔽之，選擇最好的或最受歡迎的…

選擇最受歡迎的，站在你自己的角度來看，它可以提高你在市場上的身價，讓你找的到工作，可以填飽肚子。而站在別人的角度來講，你開發出來的系統容易讓別人接手，開發系統時可用的支援較多，市場的接受度較高，不用重新教育使用者。

選擇最好的，一方面是可以接觸新思維，提供不同的視野。另一方面，則是期望有一天，最好的可以變成最受歡迎的。而早期投入者，多少可以收到 "傳教士" 般的尊崇待遇。還記得以前 XML 剛出來時，大力推廣 XML 的勞虎，在網路上廣泛傳送其免費電子書《無廢話 XML》，而今多少學習 XML 的網民，還是感念其恩德啊!

那麼，以下便是我的選擇。我會說明其主要應用，及個人對它的觀感。

最受歡迎：

C/C ++：這應該是正統資訊工程科系都必修的語言吧，它的應用不但能讓你直指核心(C)，也能讓你站在物件的具像高度(C++)，思考系統的構成。像是系統程式、原生應用程式、軔體、Driver 等，皆是 C/C++ 應用所及之處。尤其台灣電子產業相對發達，在各種掌上型、智慧型裝置不斷推陳出新的今天，對C/C++的人力資源有高度需求。不過這個語言(尤其 C++)因為承載太多歷史包袱，各種實作變體太大，開發時常需用很多 tricks，在應用時需要付出較多心力，在程式語言本身及各種環境歧異的細節上!

Java：如果你唸資工系，但學校 C/C++ 課程非必修，那麼至少 Java 是必修課程吧! Java 除了較少用在系統程式外，其他領域幾乎都占有一席之地。由於 Java 具有良好的物件導向基礎，當代許多企業應用皆採 Java Solution，尤其是在 SOA/ESB/EAI 等領域。採用 Java Solution 的好處是自由度高，但缺點就是很多事情沒有標準作法，或支援標準作法的解決方案太多，往往要花費不少時間在選擇如何架構系統上。

C# & VB.NET：這能讓你賺錢! 可以讓你快速的寫出漂漂亮亮的應用程式! 能讓你與微軟的企業系統做完美的結合。像是 BI(OLAP、Reporting、Data Mining)那一塊，是 Java 在應用上比較需要費心的。而 .NET 相對於 Java 較緊緻的技術堆疊，能讓開發者較專注於應用程式的開發上。缺點是，離開了微軟平台的世界，就幾無用武之地。

PHP/Ruby：如果你想 run 自己的 business，或想建立一個像黑米、放P、挖女孩那樣的網站，相信我，這是一個很好的選擇。不過由於目前這兩個語言主要用途只在 Web 開發上，因此特別要注意典範的轉移，或是其原來專精的部分不再具有優勢。

就典範轉移：我的意思是，PHP/Ruby 除了在 Web 開發上已有成功的 killer apps 之外，其實它們能做的事，其他語言或平台也都能做，除非它們能在別的應用領域一樣成功，否則對其未來發展仍是一項危機。而就 "其原來專精的部分不再具有優勢"，這並非不可能發生，請見以下的 ECMAScript 說明。但好消息是，至少在 2007 年，這兩個語言的排名在 TIOBE 上的排名都是往上升的。

最好的：

Python：真正的跨平台，除了跨 Windows, Linux 這類原生作業平台外，它也有 Java 及 .NET 虛擬機器的移植版本。在 Java 與 .NET 競相誇炫平台能力之際，Python 仍能堅守語言本身的原味之美，是令人讚賞的。也因如此，Python 的應用領域眾多，從 Web、文字及檔案處理、科學到研究等，幾乎無所不包。事實上，很多研究平台內定的 scripting language 就是 python，像是用於統計的 SPSS、用於資料探勘的 Clementine 等。

D：被視為是 "C++ done right!" 的一個程式語言，支援了許多 C++/Java/C# 共有的特徵(OOP)，但卻也有些特徵是其他語言所欠缺(或尚在研議中)像 Out function parameters,Nested functions,Function literals,Closures,Resizeable arrays...。在現今 VM 當道的年代，D 仍編譯為 native executable，可見其定位，是比較接近 C/C++ 的。也就是適合拿來撰寫系統程式、原生應用程式、伺服器程式，以及網路應用程式等。不過，對於 D 被廣泛接受仍有重大疑慮，因直至目前為止還不知有任何較大型的專案採用 D 語言開發。相較於 Ruby 也沒有像 RoR 那樣的殺手級應用出現。

最受歡迎+最好的：

ECMAScript/JavaScript/ActionScript：JavaScript 與 ActionScript 都朝 ECMAScript 標準靠攏。本來 JavaScript 是被某些人唾棄的一無是處，以為它只會在瀏覽器上作作表面功夫的語言，但一朝 Ajax 的應用得到普遍的喜愛，JavaScript 的行情也就跟著水漲船高。但如果只是這樣，對於 ECMAScipt 最新標準的推廣倒不見得有多大助益。特別是後來 ActionScript 也遵循 ECMAScript 標準，而且號稱 ActionScript 3.0 是非常遵循，這就好玩了。因為 ActionScript 是應用在 Flex/Flash player 中，而瀏覽器中主要執行的指令語言是 JavaScript，而這兩者都是當代 Thin Client/RIA 的主流，因此我們可以說 ECMAScript Family 幾乎已成為 Universal Client Lauguage。

再者，認為 JavaScript 只會在瀏覽器上作作表面功夫其實並非事實。早期 Netscape Enterprise Server 及 BroadVision One-to-One Server，在 JSP 尚未出現前，伺服器上執行的指令語言就是 JavaScript。而前文提到現在是 VM 當道的年代，現在 ActionScript 的 engine 也已成為一個 VM，叫 AVM，且已貢獻給 Mozilla，成立 Tamarin 專案，將來若用於 Firefox 中，網頁內的 JavaScript 跑起來說不定會跟飛的一樣。

若是真有人拿 AVM 來寫伺服器，說不定會光復 JavaScript 在 Server 端的失土哦 (好吧! 天方夜譚)! 說真的，AVM Server 版若成(例如成為 Apache 的一個 module)，要威脅 Java 或 .NET 既有地位是比較困難，因為這兩個平台既有應用多、進化動力也強；但對其他 Server 端的 Scripting Language 絕對是個威脅。想想看，若你能在 Server 端及 Client 端同時使用 ECMAScript，那使用 Ruby 或 PHP 的誘因是否會漸漸變弱呢！而 Ruby 會紅，並不是語言本身之美所致，而是出了一個 Ruby on Rails Framework，而 framework 裡面的 concepts 是很容易 porting 到別的語言或平台中的。

其他：

看了以上個人挑選出來的清單，看啊看的，現在還是程序導向和物件導向語言的天下。難道沒有其他不一樣思考面向的東西嗎? 有的，而且我們也還滿常用，像是 SQL，或是各式 Markup Language 了(雖然不是程式語言)。還有那些用在工程、模擬、統計分析、人工智慧上的，你沒有那個環境或從事相關職業，是幾乎無從著手的語言，而這些當然就不算在推薦之內。

結語：

一項語言要被廣為接受，在過去，我一直以為大廠的支援是個必要因素，但 PHP(XOOPs, Nuke...) 及 Ruby(RoR) 這種透過 Community 及 Killer Application 來帶動風潮的成功案例，似乎也印證了 "世界是平的" 的論點，在這個網路世代，不只大企業，小企業及個人一樣有機會。Killer Apps 與 Success Stories，可能比大廠背書更有價值。

而對於你的選擇，我想，如果要做個尋常的程式開發人員，我會建議你 ECMAScript Family 一定要學，那 Java 或 .NET 再選一種。若你是個不尋常 (開發特殊應用的軟體) 的程式設計師，通常也就沒什麼好選了，因為應用的型式就決定了我們的選擇。

[轉貼] Web 2.0 時代下的幾個 Java Web Framework

2008-03-13T19:25:00.000-07:00

原文來自:愛德華日誌
文章網址:Web 2.0 時代下的幾個 Java Web Framework

在這 Web 2.0 的時代，現今的 Java Web Framework 也與過去第一代的 Java Web Framework 有些不同，先列出我所關注的幾個：

Spring Framework

* Spring Framework - http://static.springframework.org/

輕量級的 Java 應用程式容器，同時支援 Rich Client、Web及 Java EE 應用系統之開發。

* Spring Web MVC Framework - http://static.springframework.org/spring/docs/2.0.x/refer...

Spring Web MVC 是一簡單易用的 web MVC 套件，可讓開發人員把 View, Controller 及 Model 分離，開發出容易維護的 Web 程式碼。由於其 View 端採用 pluggable 方式設計，可搭配 JSP, Struts 或 JSF 展示框架使用。

由於 Struts 架構因限制特定用途且開發動能不足，目前已呈老化之趨勢，開發新專案時，不建議採用。對過去只採用 JSP 的系統來說，採用 Spring Web MVC + JSP 將是最可行而簡易的升級方案。

* 中文版的 Spring Framework 教材 - http://caterpillar.onlyfun.net/Gossip/SpringGossip/Spring...

良葛格寫的，其中對 Spring Framework 有深入淺出的介紹。若對 Spring Framework 不熟悉，建議先看這裡的介紹，大致上看完後對基本的應用就足夠了。若有不足處，可再參考官方參考手冊(http: //static.springframework.org/spring/docs/2.0.x/reference/)。

* Spring Web Flow - http://opensource.atlassian.com/confluence/spring/display...

Spring Web Flow 讓開發人員定義一組態設定檔，透過定義 page 及 action 的 binding，完成 page flow 的定義。令人興奮的是，在 Spring IDE(http://springide.org/project/wiki/SpringideFeatures) 中，提供對 Spring Web Flow 的支援，讓開發人員可以透過視覺化的方式(http://springide.org/project/wiki/WebFlowEditor)，來定義網頁流程。

Echo2

* Echo2 - http://www.nextapp.com/platform/echo2/echo/

支援 Ajax 最徹底的 Web Framework，其特色是 Echo2 將網頁元素完全物件化，透過它所開發出來的網頁程式，不用寫到一行 HTML, javascript 程式碼。如果開發者對 Swing 熟悉，那麼開發 Echo2 程式將會輕而易舉。想要了解 Echo2 所開發出來的程式風格，可參考其 demo(http://www.nextapp.com/platform/echo2/echo/demo/)。看過 Echo2 令人印象深刻的展示程式後，會覺得其他 Web Framework 的展示程式是那麼軟弱無力。

另外，我發現 Echo2 的社群也是非常活躍，像是其 forum(http://forum.nextapp.com/forum/) 或 wiki(http://wiki.nextapp.com/echowiki/) 裡，可以找到不錯的參考資源。而 EndPointNG (http://wiki.nextapp.com/echowiki/EchoPointNG) 則提供了許多額外的元件，像是 Tree, TreeTable, PageableTable 等。

在應用上，把所有 web 元素通通轉換成 Java 資源放在 session 裡面，對於使用者眾多的應用程式將非常不利(但若是像我們公司這類程式由於非訴諸一般 end user，則無所謂)。

Google Web Toolkit

* Google Web Toolkit - http://code.google.com/webtoolkit/

Google 所出品的 Java Ajax Web Framework。其實說它是 Java Web Framework 有些不對，因為它在開發的過程中，採用與 Echo2 類似的 Approach，是以 Java 物件來代表/處理 Web 元素。但是真正佈署前，必須將這些 Java 物件 compile 成 HTML 及 Javascript，再佈署這些轉譯後的 web 資源。因此這些資源極有可能佈署至一般的 web server 內(如 Apache)，而不需要特定的 Java web container(如 tomcat)。

由於 Google 的Ajax 技術已經過實際應用，因此可以確認的是它的效能不成問題。另外由於它的展現層與邏輯層完全分離，兩者之間採用 jscon 或 RPC 的方式進行呼叫，因此 server 端完全免除 UI 的 loading，只要專注於 service 的邏輯即可。再加上它可透過 JavaScript Native Interface (JSNI) 來整合既有 javascript 撰寫的網頁元件，對於 third-party 的元件，將較容易整合與移植。結論是：GWT 是一適用於高負載，運用彈性靈活的 web framework。

Wicket

* Wicket - http://wicket.sourceforge.net/

Wicket 是 web 應用程式中，將 Java 程式與 HTML 源碼切割的最乾淨的一套 web framework。與 JSP 一樣，Wicket 將 view 端的 UI 定義在 HTML 中，但與 JSP 不同的是，它並不是採用 <%%> 這類特殊的 tag 來夾注 server 端的邏輯，而是利用 XML namespace 的方式，在一般的 html tag 中加注 Wicket id 來達到 server 端邏輯連結的效果。

Wicket 與 Echo2 一樣，將所有的 UI 元素都轉換成 Java 物件存在 session 裡，對於流量大的應用程式非常不適用。實際試用 Wicket 之後，發現在使用既有元件的情況下，要完成相同的工作，它所需的程式碼要比 Echo2 來的多。且由於 Echo2 是所謂 "一頁式" 的 web 應用程式，而 Wicket 可支援多個頁面，因此它在 URL 連結及 session 的處理上更為複雜。所得到的益處是，Wicket 同時支援 Ajax 與 refresh based 的 web 應用程式開發，且支援 bookmarkable URL。

另外，由於 Wicket 使用 HTML 作為網頁元素樣版，因此可以在美工人員與程式設計師之間作良好的分工。而既有的 javascript 在整合上，也會較 Echo2 來的簡易。

接下來，我想透過分析以上幾個 frameworks，檢視應用程式框架發展、轉變背後所隱含的意義：

支持輕量級開發

所謂輕量級開發，可以由幾個角度來檢視，一個是元件模型，UI 與 Server 端的邏輯是否容易連結。另一是在開發應用程式的過程中，是否需要採用特殊的工具，如特殊的 GUI Builder 或 configure file editor。最後，則是其執行環境是否單純，或是需要特定的 web 容器。

在第一點上，個人認為 Wicket 及 Echo2 皆有良好的表現。因為它們所採用的方式，是直接撰寫視覺元件的 action listener，與 Swing 的作法一致。而 Spring Web Framework 則承襲第一代 web framework，採用 dispatcher/handler 的作法，在觀念是 request/response 模式。至於 GWT，由於 client 端邏輯純粹由 javascript 負責，它所提供的 javascript 包含 RPC 呼叫程式，用來呼叫 server 端的應用程式邏輯。而 GWT 的 server 端邏輯，是一種特殊型式的 servlet。因此，如果系統中後端邏輯複雜多變，需要多個 server 端元件時，採用 GWT 預計就要維持很多個 servlet，可能會令人相當頭疼。

第二點，應用程式之開發環境，在 GWT, Wicket 及 Echo2 中，都是直接以既有的 Java IDE 即可開發，至於 Spring Web Framework 在這一點上，因為其 View 端採 plugable 設計，基本上是獨立的。不過其 config file，個人認為若有合適的 editor，會較容易使用。最仰賴 GUI builder 的，我想是 JSF，不過也不排除有存在樂於 hand coding JSF tags 的天才。

最後是運行環境，這方面的贏家是 GWT，因為它在運行時甚是不需要 server 環境。至於 Spring、Wicket 及 Echo2 等，則需要(只要)一搬的 java web container, 加上 framework 特有函式庫即可。

另外，這裡我並未強調元件模型是否為 POJO，因為繫結視覺元素與後端邏輯，本身就是 glue code。你只能看它是否夠不夠簡易，而無需用 model layer 的標準來要求，

支援新一代的動態網頁技術

Wicket、 Echo2 及 GWT 都支援所謂的 Ajax 技術。在使用上，Echo2 的方式相當靈活，因為它讓你可以動態的在 clinet 端加入與移除視覺元件。Wicket 在使用上感覺就有些限制，因為它要求 Web UI 元件與後端的處理元件，需存在一對一的對應。

對於標準的支持

這一項有些含糊，因為每個 framework 所重視的標準不一。像是 GWT 重視的是平台的獨立性，而 Spring 重視的是支援既存的各種 framework，達到中立性。Wicket 重視的是 HTML 語法的相容性，而 Echo2 重視的則是瀏覽器的相容性，以及 Swing 風格的設計思路。不過總而言之，新一代的 web framework 在這個面向已進步許多。

視覺元件與程式邏輯更明確的分割

這可分為「看起來是」與「實際上是」，像是 Wicket 就做到看起來是。有趣的是，Echo2 是看起來不是，但實際上卻是。至於 GWT 嗎，由於它的 server 端的邏輯是另外寫成 service，而 client 端的視覺元素在開發時也是以 java 撰寫。兩者採用一致的方式，不過卻必須分開撰寫，可以說它是實際上是，至於看起來是不是，就見仁見智了。

[轉貼] 如果地球上只有100人

2008-03-11T07:27:00.000-07:00

美國史坦福大學醫學研究所 Phillip Marter先生，半年前在網路討論群組發表了一篇文字，引起了許多網友的共鳴，紛紛張貼轉載，歷久不衰，特別介紹給讀者。如果我們把全球人口壓縮成只有 100 人的部落，

而且維持人類的各種比率，那麼我們會得到︰

1..57個亞洲人、 21 個歐洲人、 14 個美洲人、 8 個非洲人

2..52 個男人、 48 個女人

3..30 個白種人、 70 個非白種人

4..30 個基督徒、 70 個非基督徒

5..89 個異性戀者、 11 個同性戀者

6..6 個人將擁有全部財富的59% ，而且這 6 個人全部來自美國

7..80 個人的居家生活不甚理想

8..70 個文盲

9..50 個人營養不良

10..1 個人即將死亡、 1 個人即將生產

11..1 個人 (Yes, onlyONE!) 擁有大專學歷

12..1 個人擁有計算機

當我們從這樣壓縮的角度來看這個世界時，我們會更清楚這個世界需要更多的接納、諒解、和教育。

還有一些值得我們深思的︰如果您今天早上醒來時還算健康，恭喜您，因為有一百萬人將活不過一星期。

如果您不曾經歷戰爭的危險、被監禁的寂寞、被凌虐的痛苦、或是飢寒交迫，恭喜您，您比 5 億人還好命。

如果您可以參加宗教活動而不必擔心被騷擾、逮捕、凌虐、或死亡，恭喜您，您比 30 億人還自由。

如果您的雪櫃裡有食物、有衣服穿、還有地方住，恭喜您，您比全世界 75% 的人還富有。

如果您在銀行有存款、錢包裡有鈔票、還有一些零錢，恭喜您，您是全世界前8% 的有錢人。

如果您的雙親都還健在而且沒有離婚，您算是幸運兒。

您可以讀這篇文章，那是雙重幸運︰有人想到您這個朋友，而且有 20 億人根本不識字。

工作，可以不必要汲汲營營；用心去愛，即使您曾經受傷；

盡情跳舞，引喉高歌，

管別人怎麼想；讓自己活在人間天堂。

很引人注意

2008-03-07T09:45:00.001-08:00

頭有點暈

2008-03-07T09:25:00.000-08:00

可愛

2008-03-07T09:05:00.001-08:00

囧

2008-03-07T09:02:00.001-08:00

沒時間了

2008-03-07T08:57:00.001-08:00

頂到了

2008-03-07T08:07:00.001-08:00

好悶

2008-03-06T21:33:00.001-08:00

芥末

2008-03-05T20:59:00.000-08:00

話說上帝是個很喜歡吃生魚片的人。
他的廚子每天都要為他精心準備好吃的沾醬配合生魚片吃，
但是不管如何精心的調配，上帝還是最喜歡吃醬油沾芥末的原始風味。
但為了不讓上帝每天吃得厭煩，
廚子跟上帝設計了一套一星期的行程，
星期一到日都有不同的沾醬風味，而其中，星期日就是上帝最期待的芥末日。
今天，星期日到了，廚子卻搞錯了，忘記今天是芥末日，
竟捧上有淡淡柚香的柚子醬油給上帝。
上帝非常生氣，他等了一星期才等到芥末日的到來，
於是發脾氣對著廚子大吼：

「今天是芥末日啦！是芥末日啦！」

然後世界就滅亡了。

[面試] 微星科技

2008-01-25T21:33:00.000-08:00

1/25上午十點半前往微星科技面試。

這次會去微星科技面試其實還蠻意外的，當初微星科技的人資管理打電話聯絡我時，我是回答他說我工作已經找的差不多了，但是他是說，還是可以來談談看嘛，我想也是，所以就約好時間前往面試。

微星科技的地點大約在中和中正路跟中山路的交叉口附近，微星給我的第一個印象是它的整個人員進出的管理感覺上還蠻有制度的，我一進大門，門口管制的小姐問了我的名字跟拿了我的證件之後，過一會我就拿到一張單子，上面有我的姓名，我押的證件，我來的目的，跟負責接待我的人是誰，表示他們約誰面試應該都必須要輸入系統來整個做管理，之後到了樓上，櫃檯小姐也直接刷單子上的條碼來辨識。

後來遇到跟我聯絡的人資管理人員之後，才發現他是我高一的同學，真是巧，他先跟我大致聊一聊之後，接下來他就去請主管來跟我做面談。

主管看起來年紀也不太大，人也感覺還蠻不錯的，主管說，目前要找人的職缺，將來會負責一些跟高階主機板相關的Java程式，還有會負責手機上的Java遊戲開發。

主管人很乾脆，中間有問我說其他面試都需要面試幾次，我說蠻多都需要第二次面試或甚至第三次面試，主管就說，嗯，我們這邊不用這麼麻煩，我決定就可以了，後來還帶我大致參觀了一下工作的區域跟座位。

雖然我不一定會去微星，不過微星給我的感覺是真的蠻不錯的。

紙黏土做的小東西

2008-01-17T02:12:00.000-08:00

有很多人都問起我以前做的那個紙黏土小東西，現在做到什麼程度了？

所以我只好放一下做好後拍的照片：

這是剛捏好的時候：

上色及上了透明漆之後：

第一次做，還有很大改進的空間。

[面試] 104人力銀行

2007-12-11T02:08:00.000-08:00

12/11下午五點前往104人力銀行面試。

會投履歷到104人力銀行，其實是同事建議的，因為此時我找工作也有一段時間了，同事有一次跟我聊天時說到，104人力銀行也有在徵Java的職缺，建議我可以去試試看。

經過搜尋，發現104人力銀行真的有很多職缺，跟Java有關的大約有四五個，就投了其中三個，投了不久後，就接到通知面試的電話，於是就安排在今天下午。

104人力銀行的位置在新店，以我住木柵來說，是相當近的，我估計以騎車來說，單趟路程大約20分鐘之內就會到了，很方便。

面試結束了之後，就我個人的感覺，這次面試跟其他的面試有比較不一樣的感覺，這次面試感覺是比較著重於人格特質方面，對於技術層面上來說，相對的問的比較少一點。

希望有好消息。

[面試] PChome Online

2007-12-11T02:00:00.000-08:00

今天下午兩點半前往PChome面試。

PChome在敦化南路上，離遠企中心很近。

這次面試的工作內容大致是撰寫與Skype相關的系統或應用程式。

進去之後直接被帶到一間小會議室裡面，因為小會議室在一進門的位置，所以都沒有看到辦公區域大概是什麼樣子。

大約跟主管談了一個小時左右，結束時，主管說，如有通過會安排第二次面試，而且主管還強調，如果有通知第二次面試，應該就是確定了，第二次面試只是要談其他的一些細節，例如說待遇或福利，但也代表說如果接到第二次面試的通知時，心裡就要有個底了，也要做好決定，因為談完細節就要答覆了。

[面試] 康大資訊

2007-11-05T02:10:00.000-08:00

11/5早上十點前往康大資訊面試。

康大資訊在南京東路上，辦公室是看起來還蠻明亮整齊的，進去先做測驗，再來跟主管談，談了約一小時，結果後來也沒消息了。

後記：後來經過約一個月後，我又接到康大資訊的電話問我要不要去面試，

我說：”康大資訊？我去過了啊，然後後來就沒消息了。“

小姐：”呃，那可能是不同部門喔，那你要不要再來面試看看？“

不過我就沒再去了。