<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: 無名的 service level 挑戰</title>
	<link>http://2tigers.net/blog/2006/10/06/wretchs-service-level-challenge/</link>
	<description>"It's the end of the world as we know it, and I feel fine." -- R.E.M.</description>
	<pubDate>Sun, 14 Mar 2010 18:10:22 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.2</generator>

	<item>
		<title>by: FOH</title>
		<link>http://2tigers.net/blog/2006/10/06/wretchs-service-level-challenge/#comment-4845</link>
		<pubDate>Tue, 23 Jan 2007 09:54:34 +0000</pubDate>
		<guid>http://2tigers.net/blog/2006/10/06/wretchs-service-level-challenge/#comment-4845</guid>
					<description>我記得前一陣子看到一則新聞，中正大學某教授開記者會發表WEB3.0的新聞。看了之後有個感想，這跟
一堆大學爭先恐後改名成XX科技大學有什麼兩樣??哪天別的學校也來搞個WEB4.0，也開個記者會，好像
自己就是全球網際網路的領航員一樣...

世界上有誰能夠同時精通ASP、PHP、JSP、Ruby....甚至是不知哪冒出來的Erlang，如果有的話
除非他是IQ200，或是他能活200歲，或是他整天就是寫程式，其他什麼事情都不用做，才有可能吧

大家爭先恐後發表一些程式設計師學都學不完的語言，除了表示自己很厲害以外，還有什麼好處??
最後乾脆都不要爭，發展出一種用組合語言來運行的網頁程式，大家通通改用組合語言寫網頁
效能保證一級棒!! 又能展示自己超強的機械語言能力 一舉打回原始時代。

Ruby on Rails，號稱15 分鐘內寫出一個部落格網站,而且整個程式只有58行碼??
這像話嗎? 正牌的程式設計師一看就曉得，RoR不過是小孩子的玩具罷了。
改天又發明一個一行寫出一個部落格，取名叫Fxxking On Hell (FOH)，會不會
也在網路上造成一股炫風??

Erlang，電信業大廠 Ericsson 二十年前所發展出來，效能奇佳，那為什麼沒人用??
答案很簡單，如果每次某某大廠又發展了一套號稱宇宙效能最好的語言，那是不是就
又要去學一次?  每年都有一個最強語言發明出來，那不是一輩子都學不完??

所以正確的反應是，給他拍拍手，好厲害喔!! 效能好好喔!! 要維護的話，應該要自行
培養不少工程師耶??  否則一但有人離職，還真找不到人接手呢。 要花多少錢培養? 研發??
哪有什麼關係，反正是大廠嘛!!  

當噱頭看看就好，然後還是回來寫自己的PHP比較實用。</description>
		<content:encoded><![CDATA[<p>我記得前一陣子看到一則新聞，中正大學某教授開記者會發表WEB3.0的新聞。看了之後有個感想，這跟<br />
一堆大學爭先恐後改名成XX科技大學有什麼兩樣??哪天別的學校也來搞個WEB4.0，也開個記者會，好像<br />
自己就是全球網際網路的領航員一樣&#8230;</p>
<p>世界上有誰能夠同時精通ASP、PHP、JSP、Ruby&#8230;.甚至是不知哪冒出來的Erlang，如果有的話<br />
除非他是IQ200，或是他能活200歲，或是他整天就是寫程式，其他什麼事情都不用做，才有可能吧</p>
<p>大家爭先恐後發表一些程式設計師學都學不完的語言，除了表示自己很厲害以外，還有什麼好處??<br />
最後乾脆都不要爭，發展出一種用組合語言來運行的網頁程式，大家通通改用組合語言寫網頁<br />
效能保證一級棒!! 又能展示自己超強的機械語言能力 一舉打回原始時代。</p>
<p>Ruby on Rails，號稱15 分鐘內寫出一個部落格網站,而且整個程式只有58行碼??<br />
這像話嗎? 正牌的程式設計師一看就曉得，RoR不過是小孩子的玩具罷了。<br />
改天又發明一個一行寫出一個部落格，取名叫Fxxking On Hell (FOH)，會不會<br />
也在網路上造成一股炫風??</p>
<p>Erlang，電信業大廠 Ericsson 二十年前所發展出來，效能奇佳，那為什麼沒人用??<br />
答案很簡單，如果每次某某大廠又發展了一套號稱宇宙效能最好的語言，那是不是就<br />
又要去學一次?  每年都有一個最強語言發明出來，那不是一輩子都學不完??</p>
<p>所以正確的反應是，給他拍拍手，好厲害喔!! 效能好好喔!! 要維護的話，應該要自行<br />
培養不少工程師耶??  否則一但有人離職，還真找不到人接手呢。 要花多少錢培養? 研發??<br />
哪有什麼關係，反正是大廠嘛!!  </p>
<p>當噱頭看看就好，然後還是回來寫自己的PHP比較實用。
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: little fish</title>
		<link>http://2tigers.net/blog/2006/10/06/wretchs-service-level-challenge/#comment-4120</link>
		<pubDate>Mon, 01 Jan 2007 16:08:05 +0000</pubDate>
		<guid>http://2tigers.net/blog/2006/10/06/wretchs-service-level-challenge/#comment-4120</guid>
					<description>網頁技術php的,國內除了無名小站外,樂多的也是...只是這陣子無名風頭太健,也因此被點名的機率大幅提昇了...
個人一直認為google的網頁技術是黃金夢幻級的..在最近一次作專案的經驗裡,運用某種技術,雅虎或其他各網站尚不成問題,唯獨google會有問題...這個時候,也只有打哈哈的說:google的網頁技術太先進了吧:p</description>
		<content:encoded><![CDATA[<p>網頁技術php的,國內除了無名小站外,樂多的也是&#8230;只是這陣子無名風頭太健,也因此被點名的機率大幅提昇了&#8230;<br />
個人一直認為google的網頁技術是黃金夢幻級的..在最近一次作專案的經驗裡,運用某種技術,雅虎或其他各網站尚不成問題,唯獨google會有問題&#8230;這個時候,也只有打哈哈的說:google的網頁技術太先進了吧:p
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Gravatar還要等多久&#8230; &#171; 小白的窩</title>
		<link>http://2tigers.net/blog/2006/10/06/wretchs-service-level-challenge/#comment-726</link>
		<pubDate>Thu, 02 Nov 2006 15:31:17 +0000</pubDate>
		<guid>http://2tigers.net/blog/2006/10/06/wretchs-service-level-challenge/#comment-726</guid>
					<description>[...] 題外話，這些PHP-based的網站，似乎真的比較容易碰到類似擴充性的問題&amp;#8230;我不是說PHP不好，倒是本質上使用PHP是比較要先多想想網站未來的流量與負載，畢竟對PHP來講平行擴充是比較痛一點～:P（其實是又想吹捧J2EE一下啦！:P）當然規劃的好絕不會有問題，我指的是所必須花費的工夫看起來可能值得商榷。瞧瞧勞虎的說法吧！ [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] 題外話，這些PHP-based的網站，似乎真的比較容易碰到類似擴充性的問題&#8230;我不是說PHP不好，倒是本質上使用PHP是比較要先多想想網站未來的流量與負載，畢竟對PHP來講平行擴充是比較痛一點～:P（其實是又想吹捧J2EE一下啦！:P）當然規劃的好絕不會有問題，我指的是所必須花費的工夫看起來可能值得商榷。瞧瞧勞虎的說法吧！ [&#8230;]
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Antony</title>
		<link>http://2tigers.net/blog/2006/10/06/wretchs-service-level-challenge/#comment-719</link>
		<pubDate>Thu, 02 Nov 2006 09:53:28 +0000</pubDate>
		<guid>http://2tigers.net/blog/2006/10/06/wretchs-service-level-challenge/#comment-719</guid>
					<description>其實安東尼在接觸Java之前都是寫PHP的，所以對於PHP和Java在伺服器端的運作模式也還算勉強懂一點點啦！

當然網站的流量負荷並不是由技術來決定的，固然有像是digg.com, sourceforge.net這樣的網站以PHP來作為平台，但是他們為了系統調校而多花的Effort是很驚人的。

作為完整的開發平台，我認為PHP缺乏了相當重要的Connection Pooling以及Message Queue等機制；作為純Web的展現平台，PHP又缺少了能夠對網頁輸出做Pre-post process的能力，讓以這個平台作為開發的應用在的邏輯架構延伸性、針對效能所需要做的大量取捨。所以你比較常見到的PHP網頁都是內容導向的：不需要處理複雜的交易邏輯。

當然Java本身也是一個平台，開發人員當然可以把這平台豐富的功能自行取用，導致一些比較先進的功能沒有派上用場。所以，開發人員的實力還是決定了一個網站的負載能力，但是純粹從平台的觀點上，Java提供了比較豐富的功能來達到這些目的。

就舉一個很簡單的例子，就目前看到的PHP Package裡頭，似乎還沒有看到HttpSession的Replication。這點不管是Open source或者Commercial的Java Application Server都有支援，但是PHP的部份，似乎還沒有什麼著墨。缺乏這樣的功能，PHP的程式設計師在設計一個以數十台機器作為叢集架構的網站的時候，恐怕只能自己想辦法去客製出能夠將使用者狀態複製到其他台機器的邏輯，而Java的程式設計師則可以透明的享受這樣的好處。過去在做PHP的程式設計的時候，常常看到要為了達成PHP Cluster的功能，而將過多的資料塞在Cookie裡頭，或者將狀態寫到資料庫；像這樣的事情，一個Java的程式設計師是比較不用操心的。

其實安東尼本身是很喜歡Scripting Languages的，尤其最近對RoR有著濃厚的興趣；事實上如果PHP, Ruby on rails等技術有辦法Porting到Java EE的平台上的話，說不定是一件很好的事情。Get the best of both worlds.</description>
		<content:encoded><![CDATA[<p>其實安東尼在接觸Java之前都是寫PHP的，所以對於PHP和Java在伺服器端的運作模式也還算勉強懂一點點啦！</p>
<p>當然網站的流量負荷並不是由技術來決定的，固然有像是digg.com, sourceforge.net這樣的網站以PHP來作為平台，但是他們為了系統調校而多花的Effort是很驚人的。</p>
<p>作為完整的開發平台，我認為PHP缺乏了相當重要的Connection Pooling以及Message Queue等機制；作為純Web的展現平台，PHP又缺少了能夠對網頁輸出做Pre-post process的能力，讓以這個平台作為開發的應用在的邏輯架構延伸性、針對效能所需要做的大量取捨。所以你比較常見到的PHP網頁都是內容導向的：不需要處理複雜的交易邏輯。</p>
<p>當然Java本身也是一個平台，開發人員當然可以把這平台豐富的功能自行取用，導致一些比較先進的功能沒有派上用場。所以，開發人員的實力還是決定了一個網站的負載能力，但是純粹從平台的觀點上，Java提供了比較豐富的功能來達到這些目的。</p>
<p>就舉一個很簡單的例子，就目前看到的PHP Package裡頭，似乎還沒有看到HttpSession的Replication。這點不管是Open source或者Commercial的Java Application Server都有支援，但是PHP的部份，似乎還沒有什麼著墨。缺乏這樣的功能，PHP的程式設計師在設計一個以數十台機器作為叢集架構的網站的時候，恐怕只能自己想辦法去客製出能夠將使用者狀態複製到其他台機器的邏輯，而Java的程式設計師則可以透明的享受這樣的好處。過去在做PHP的程式設計的時候，常常看到要為了達成PHP Cluster的功能，而將過多的資料塞在Cookie裡頭，或者將狀態寫到資料庫；像這樣的事情，一個Java的程式設計師是比較不用操心的。</p>
<p>其實安東尼本身是很喜歡Scripting Languages的，尤其最近對RoR有著濃厚的興趣；事實上如果PHP, Ruby on rails等技術有辦法Porting到Java EE的平台上的話，說不定是一件很好的事情。Get the best of both worlds.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Erlang 及 Yaws at bibliophile.new</title>
		<link>http://2tigers.net/blog/2006/10/06/wretchs-service-level-challenge/#comment-579</link>
		<pubDate>Fri, 27 Oct 2006 00:53:10 +0000</pubDate>
		<guid>http://2tigers.net/blog/2006/10/06/wretchs-service-level-challenge/#comment-579</guid>
					<description>[...] 這趟旅程是從這篇文章開始的，隨即逛了這個 Yariv&amp;#8217;s Blog，裡面對 Erlang 大加讚揚，認為Erlang在Web領域淺力無窮，尤其隨著 Comet 對 server scalable 能力的要求，更可以展現它高度的性能。 [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] 這趟旅程是從這篇文章開始的，隨即逛了這個 Yariv&#8217;s Blog，裡面對 Erlang 大加讚揚，認為Erlang在Web領域淺力無窮，尤其隨著 Comet 對 server scalable 能力的要求，更可以展現它高度的性能。 [&#8230;]
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: 山丘突歐 &#187; [書籤] 山丘20061012</title>
		<link>http://2tigers.net/blog/2006/10/06/wretchs-service-level-challenge/#comment-383</link>
		<pubDate>Thu, 12 Oct 2006 04:32:44 +0000</pubDate>
		<guid>http://2tigers.net/blog/2006/10/06/wretchs-service-level-challenge/#comment-383</guid>
					<description>[...] 勞虎跑得快 » Blog Archive » 無名的 service level 挑戰 10/11 11:40, 2006 引述 :『Web 2.0 網站經營的一大成敗和致勝關鍵 — 誰能運用既便宜、生產力又高的軟體，同時又能設計出一套平行運算的獨門機制，來確保高標準的 service level 和無限的擴充性，誰的贏面就大幅提升。』  service level 在創業階段恐怕沒有比Business Modle還要重要，可是說真的創業成功了要再改 service level ，其實也是很不容易的事情！其中抉擇得好好衡量。 [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] 勞虎跑得快 » Blog Archive » 無名的 service level 挑戰 10/11 11:40, 2006 引述 :『Web 2.0 網站經營的一大成敗和致勝關鍵 — 誰能運用既便宜、生產力又高的軟體，同時又能設計出一套平行運算的獨門機制，來確保高標準的 service level 和無限的擴充性，誰的贏面就大幅提升。』  service level 在創業階段恐怕沒有比Business Modle還要重要，可是說真的創業成功了要再改 service level ，其實也是很不容易的事情！其中抉擇得好好衡量。 [&#8230;]
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: william</title>
		<link>http://2tigers.net/blog/2006/10/06/wretchs-service-level-challenge/#comment-382</link>
		<pubDate>Thu, 12 Oct 2006 03:35:47 +0000</pubDate>
		<guid>http://2tigers.net/blog/2006/10/06/wretchs-service-level-challenge/#comment-382</guid>
					<description>以軟體工程角度來說，很多 nonfunctional requirement 都會影響到程式架構。如果不趁系統亂度還不大的時候及早考慮而預留彈性空間（我說的不是及早實作出來，而是及早預留空間），事後恐怕未必很容易就調整過來。

當然啦，這和 agile development 觀點有些衝突，和 Albert Lai 在 Web 2.0 研討會所講的 &quot;&lt;a href=&quot;http://www.flickr.com/photos/kelvinwang/254498444/in/set-72157594302674327/&quot; rel=&quot;nofollow&quot;&gt;don't waste time pre-scaling&lt;/a&gt;&quot; 也有衝突，但我還是比較認同 Mike Arrington 所講的 &quot;&lt;a href=&quot;http://www.pocketshark.com/blog/page/tempo?entry=future_web_apps_techcrunch_mike&quot; rel=&quot;nofollow&quot;&gt;Shard attributeds of losers: forgot about scaling&lt;/a&gt;&quot;；尤其是當許多 Web 2.0 網站都是急就章地用 LAMP 兜起來，沒有太 solid 的軟體架構思考時。</description>
		<content:encoded><![CDATA[<p>以軟體工程角度來說，很多 nonfunctional requirement 都會影響到程式架構。如果不趁系統亂度還不大的時候及早考慮而預留彈性空間（我說的不是及早實作出來，而是及早預留空間），事後恐怕未必很容易就調整過來。</p>
<p>當然啦，這和 agile development 觀點有些衝突，和 Albert Lai 在 Web 2.0 研討會所講的 &#8220;<a href="http://www.flickr.com/photos/kelvinwang/254498444/in/set-72157594302674327/" rel="nofollow">don&#8217;t waste time pre-scaling</a>&#8221; 也有衝突，但我還是比較認同 Mike Arrington 所講的 &#8220;<a href="http://www.pocketshark.com/blog/page/tempo?entry=future_web_apps_techcrunch_mike" rel="nofollow">Shard attributeds of losers: forgot about scaling</a>&#8220;；尤其是當許多 Web 2.0 網站都是急就章地用 LAMP 兜起來，沒有太 solid 的軟體架構思考時。
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: 山丘</title>
		<link>http://2tigers.net/blog/2006/10/06/wretchs-service-level-challenge/#comment-378</link>
		<pubDate>Wed, 11 Oct 2006 03:39:13 +0000</pubDate>
		<guid>http://2tigers.net/blog/2006/10/06/wretchs-service-level-challenge/#comment-378</guid>
					<description>『Web 2.0 網站經營的一大成敗和致勝關鍵 — 誰能運用既便宜、生產力又高的軟體，同時又能設計出一套平行運算的獨門機制，來確保高標準的 service level 和無限的擴充性，誰的贏面就大幅提升。』 這句成了我一個重要的讀書筆記，也是很多網路創業家需要思考的問題，感謝勞虎。</description>
		<content:encoded><![CDATA[<p>『Web 2.0 網站經營的一大成敗和致勝關鍵 — 誰能運用既便宜、生產力又高的軟體，同時又能設計出一套平行運算的獨門機制，來確保高標準的 service level 和無限的擴充性，誰的贏面就大幅提升。』 這句成了我一個重要的讀書筆記，也是很多網路創業家需要思考的問題，感謝勞虎。
</p>
]]></content:encoded>
				</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.503 seconds -->
