在上面的這段html頁面中，gmail使用了一個table，代碼如下：
<tr>
<td nowrap="nowrap">
<table width="100%" cellspacing="0" cellpadding="0" bgcolor="#c3d9ff" align="center" style="margin-bottom: 5px;">
<tbody><tr>
<td valign="top" align="left" class="bubble tl"><div class="SPRITE_corner_tl"></div></td>
<td style="padding: 5px 0pt; font-family: arial; text-align: left; font-weight: bold;" rowspan="2" class="bubble"><b>歡迎使用 Gmail</b></td>
<td valign="top" align="right" class="bubble tr"><div class="SPRITE_corner_tr"></div></td>
</tr>
<tr>
<td valign="bottom" align="left" class="bubble bl"><div class="SPRITE_corner_bl"></div></td>
<td valign="bottom" align="right" class="bubble br"><div class="SPRITE_corner_br"></div></td>
</tr>
</tbody></table>
</td>
</tr>
為了既考慮UI效果，又能避免帶來速度上的影響，用了最少的圖片來實現彎角效果(圖片在div的SPRITE_corner CSS中)，從而避免設計成一個大的圖片而影響用戶瀏覽器下載資源的速度。
從我這個非UI設計人員的視角來看，不知道GMAIL這樣設計的初衷是否是這樣的，如果不是的話，請高手賜教。
]]>
After receiving a Ph.D. in computer science from MIT in 1979, Jeff joined IBM's Thomas J. Watson Research Center. During his tenure at IBM, he held a wide variety of technical and management positions, including vice president, Systems and Software Research, corporate vice president of technology, and general manager of IBM's SecureWay business unit, where he was responsible for IBM's security, directory, and networking software business.
Jeff then served as president of Bell Labs Research and Advanced Technologies, where he established new facilities in Ireland and India, and served as chairman of the board of the New Jersey Nanotechnology Consortium.
Most recently, Jeff served as the Executive Vice President and Chief Technology Officer for Novell. He was responsible for Novell's technology direction, as well as leading Novell's product business units.
Jeff was appointed by President Bill Clinton to serve on the Advisory Committee for the Presidential Commission for Critical Infrastructure Protection. He has also chaired the Chief Technology Officer group of the Computer Systems Policy Project, and has served on the National Research Council's Computer Science and Telecommunications Board. He is a Fellow of ACM and the IEEE.
Dr. Jaffe holds a BS in Mathematics and an MS in Electrical Engineering and Computer Science in addition to his Doctorate from the Massachusetts Institute of Technology.
]]>
在HTML中，form元素用
W3C的HTML 4.01 specification說，form元素的method屬性用來指定發送form的HTTP方法。 這可以簡單地理解為，get僅僅是拼接一個URI，然后直接向服務器請求數據（需要提交給服務器的數據集包含在URI中）。比如： 這個form在提交的時候，會產生這樣能夠一個get請求：FormGet.aspx?ProductID=1。 而post會把form的數據集，即ProductID=1這個鍵值對包裝在請求的body中，發送給服務器，然后向服務器請求數據。對于： 這樣一個form在提交時，我們將看到一個干凈的URI：FormPost.aspx。因為數據不是拼接在URI中。 如果用get提交一個驗證用戶名和密碼的form，一般認為是不安全的。因為用戶名和密碼將出現在URL上，進而出現在瀏覽器的歷史記錄中。顯然，在對安全性有要求的情況下，應該使用post。 HTML 4.01 specification指出，get只能向服務器發送ASCII字符，而post則可以發送整個ISO10646中的字符（如果同時指定
注意get和post對應的enctype屬性有區別。enctype有兩個值，默認值為application/x-www-form-urlencoded，而另一個值multipart/form-data只能用于post。 HTTP specification并沒有對URL長度進行限制，但是IE將請求的URL長度限制為2083個字符，從而限制了get提交的數據長度。測試表明如果URL超出這個限制，提交form時IE不會有任何響應。其它瀏覽器則沒有URL的長度限制，因此其它瀏覽器能通過get提交的數據長度僅受限于服務器的設置。 而對于post，因為提交的數據不在url中，所以通?？梢院唵蔚卣J為數據長度限制僅受限于服務器的設置。 由于一個get得到的結果直接對應到一個URI，所以get的結果頁面有可能被瀏覽器緩存。而post一般則不能，參考5。 出于和上面相同的原因，我們可以用一個URI引用一個get的結果頁面，而post的結果則不能，所以必然不能被搜索引擎搜到。 在服務端的ASP.NET程序中，對于get，我們用Request.QueryString[control-name]來取得對應的=current-value；對于post，我們用Request.Form[control-name]。 我們也可以籠統地使用Request[control-name]。但這樣做的效率不如前者。我們可以用下面的程序比較Request.QueryString和Request的效率： 同樣的辦法我們可以比較Request.Form和Request。 最后得到的結果（Request.QueryString[control-name] / Request[control-name]和Request.Form[control-name] / Request[control-name]）大多數時候是小于1的。因此，我們因該盡量用Request.QueryString或Request.Form來代替Request。 W3C的官方建議是：當且僅當form是冪等（idempotent）的時候，使用get。冪等是一個數學上的術語，其定義是：對于一個函數f : D -> D，如果D中的所有x滿足f (f x) = f x，那么這個函數是冪等的。HTTP specification（比如RFC 2616）中，將冪等解釋為：多次相同請求產生的副作用，和一次請求的副作用相同。 打個比方，如果你提交一個form會從Google上查詢一個關鍵詞，那么我們可以認為這個form是冪等的，因為1次提交和10次提交的副作用是差不多的（10次查詢可能會多消耗一些電能）；如果你提交一個form是訂購一個終極大黃蜂（Utimate bumblebee），那么這就不是冪等的：要是你不小心多提交了1次form的話，你可能會被老婆亂罵，你不小心又提交了10次的話，你可能就破產了——一次提交和多次提交的副作用明顯不同，所以這不是冪等的。 所以，一般來說，如果提交這個請求純粹只是從服務端獲取數據而不進行其他操作，并且多次提交不會有明顯的副作用，應該使用get。比如： 如果提交這個請求會產生其它操作和影響，就應該使用post。比如： 另一個要考慮的因素是安全性。見2.1。1. get和post的定義
<input type="text" name="ProductID" value="1" />
<input type="submit" value="Get" />
</form>
<input type="text" name="ProductID" value="1" />
<input type="submit" value="Get" />
</form>
2. get和post的區別
2.1 安全性
2.2 編碼
2.3 提交的數據的長度
2.4 緩存
2.5 引用和SEO
3. 服務端的處理
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<script runat="server">
protected void Page_PreInit(object sender, EventArgs e)
{
if(Request["InputString"] != null)
{
int count = 1000000;
DateTime start;
DateTime end;
string value = "";
start = DateTime.Now;
for(int i = 0;i < count;i++)
{
value = Request.QueryString["InputString"];
}
end = DateTime.Now;
double requestGet = (end - start).TotalSeconds;
start = DateTime.Now;
for(int i = 0;i < count;i++)
{
value = Request["InputString"];
}
end = DateTime.Now;
double request = (end - start).TotalSeconds;
compare.InnerHtml = requestGet.ToString() + " / " + request.ToString() + " = " + (requestGet / request).ToString();
get.InnerHtml = value;
}
}
</script>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Request.QueryString / Request</title>
</head>
<body>
<form method="get" action="FormGet.aspx">
<div>
<input type="text" name="InputString" /><input type="submit" value="Post" /><br />
Get: <span runat="server" id="get"></span><br />
Request.QueryString / Request: <span runat="server" id="compare"></span>
</div>
</form>
</body>
</html>
4. 正確地使用get和post
5. 瀏覽器差異
并且，在后退的過程中有可能出現“Page has Expired”（通常是向自己post，然后后退時）：
微軟的技術支持人員號稱“this is not a bug or problem specified to the ASP.NET but a security feature of the IE Browser”，并且說“You can also inform your users of this”，實在是荒唐。另外，IE 7：和IE 6相同；
6. 參考
]]>
http://shaoblog.com/2009/01/22/%e5%86%8d%e8%b0%88%e5%88%9b%e4%b8%9a%e8%80%85%e7%ae%a1%e5%93%aa%e4%b8%aa%e9%87%8d%e8%a6%81/
昨天QQ的馬化騰到我們這邊來聊天，談到了創始人重視產品在企業成功的重要性。即使在QQ已經這么成功，市值近百億美金的今天，他還花很多時間在產品上。聽上去很簡單也很自然，但是我看到很多創始人做不到。
創業者要管的太多了，產品，市場，銷售，財務，技術，找人，炒人，公關。不可能每件事情都事必躬親，一定有些需要交給手下領頭。哪兩件最重要？我覺得是找人和產品。別的事都可能找到好的人代勞，但產品和找人不行。
找到一個好的人太關鍵了。我從前寫了很多：海龜還是土鱉？，招不到稱心的人怎么辦?，招怎么樣的人，今天就不多說了。只加一句：找什么樣的人，決定公司的文化，所以創業者是一定要自己做的。
找到好的人，可以一手代包市場，銷售，財務，技術，公關（找到好的人，能放心的把我的一個部門讓他管，知道他會管的比我更好時，感覺太好了！），但產品是一個公司的靈魂。它需要融會貫通：從市場這邊了解目標用戶是誰和他們的需求，平衡銷售那邊經常和市場部不同的意見，與技術討論什么能做，什么不能做。其中有很多取舍，很多推動，不是創始人CEO，很難做好這個工作。另外，創始人應該是最了解用戶的需求的人，因為他創業的激情就來自于為用戶解決一個問題，增添一個價值。
做易趣時我產品放權太多。雖然我們那時的產品部很不錯，但沒有創始人每天的介入，他們的任務是不可能完成的。我給我們那時候2002年的產品打75分。2003年走了后，平臺遷移到eBay后，分數就慘不忍睹了。網站改個字需要九個禮拜，改個功能需要在總部排隊九個月。（這里的故事很長了，產品只是一部分，文化的變化更致命。以后有空和易趣那些老員工們應該一起寫本書。）
放眼世界上翹楚的產品，AMAZON，APPLE，NINTENDO，他們的CEO或創始人都是注重產品，不放權的瘋子。
上一篇創業，管哪個事情最重要？引起了一些有趣的爭議，關于產品還是市場重要。我覺得這個問題對創業者很關鍵，所以再來寫一篇。ha，這個月寫了兩篇，為前幾個月補過。
首先，問題不是說企業里哪個部門重要。一個企業的成功，是很多因素的乘法。乘法和加法不同：后者如有一個因素是零，對整體不一定有大影響，但前者里如果有個因素是零，結果是零 - 產品，市場做得再好，財務出問題，公司照樣死。當企業成功是乘法時，討論哪個部門重要，沒什么意義。比較有意義的問題是：創業者哪個比較可以放權，哪個需要自己抓。（謝謝keso幫我澄清too。）這個問題太重要了，因為我堅信一個初創的企業，最重要的資源是創始人的時間和精力。我們現在談的，是這個資源的分配問題。
第二，做產品，從來不是（或不應該是）空想的。我覺得產品部是公司最難的工作。它需要綜合權衡各個部門的要求。
a）市場：我們的現有用戶是這么樣的人？他們的需求是什么？我們的潛在用戶是誰？他們的需求是什么？很多時候，人（尤其是經理人）會太注重現有顧客，忽視潛在客戶。人也會太注重用戶能表達的需求（市場調查拿得到得），忽略用戶不知道怎么表達的需求（需要靠創業的自覺來發掘的）。
b）銷售：什么樣的產品賣得掉，容易銷售？在有些公司，市場和銷售的目標用戶是一樣的。在有些公司，用戶（主要用產品的人）和顧客（付錢的人）是不一樣的。如何滿足和權衡他們不同的需求？在易趣那時，用戶是買家，顧客是賣家，他們的需求往往不同，甚至相反。
c）技術：那些產品容易做，那些難做？如何取舍時間vs功能？技術部會經常說：市場部要的功能不可能做，或需要太久。有時技術部有個好點子，能做個眩的新功能，市場部不要。相信誰的判斷？
d）客服：用戶很多的反饋和問題，需要多重視？什么是1%的不重要的用戶提出來的，什么是我們的核心用戶的要求，或是潛在的核心用戶的問題（解決了這個問題，他就成了核心用戶）？
還有很多例子可舉。我的感覺是產品最最需要一個創始者以一個公司總體和長遠的發展為目標，權衡各個部門的利益和偏見（甚至慣性或惰性），最終以創始者的直覺做決定。
]]>
2.精通一門編程語言,如Java,C,Php等
3.精通企業系統集成設計模式
3.對互聯網有深刻認識，對電子商務,SNS,SAAS,支付,CRM,ERP等行業有過從業經驗或有一定理解，熟悉主流電子商務網站的業務模式
4.至少要有一個大型系統的系統分析/設計經驗，有過百萬級別會員數量以上系統的分析、設計經驗者更佳
5.至少有一個產品的完整開發經驗，包括需求分析,產品設計,系統設計,程序開發,3人以上的開發團隊管理,軟件配置管理,質量控制,產品運營等各方面工作都有一定理解及經驗
6.優秀的口語及書面溝通表達能力,能熟練使用Word,PowerPoint,Project,UML工具編寫各種類型文檔,能熟練閱讀英文
7.有自己創業經驗者優先
]]>
http://blogoscoped.com/archive/2005-08-24-n14.html
這篇文章是講為什么好的程序員是既懶有笨的!哈哈!
我記得在看UNIX編程藝術時,里面也有這么段話,說不會偷懶的程序員不是好程序員!
為什么呢!我們可以舉些簡單的例子:
1.只有懶惰的程序員才會去編寫那些可以最終代替自己工作的自動化工具,好的程序員都會有一套自己的代碼自動生成工具,有的是用模板語言,有的是用shell.在開發一個新的系統時,系統基礎框架設計好后,很多業務層代碼基本上都是一個模子出來的,要想讓這些代碼都是從一個模子里出來,那么就需要在底層下很大的功夫才能做到.所以,每個程序員夠應該有,或者會寫代碼自動生成工具,當然,這個工具并不是一個成功工具!它的前提是你必須在底層有足夠的抽象.
2.只有懶惰的程序員才不會去去寫大段的冗余重復的代碼,他們會想出各種方法來避免這種冗余代碼的情況,做的好的,就是在系統的基礎架構層來解決大部分這樣的問題,通過精致的設計模式,高度抽象的模塊,易用的接口,高度可配置的基礎平臺等等來實現,做的一般的會利用各種開源工具來代替自己想要的代碼,做的差些的就是不斷利用refactor重構出那些重復代碼.
3.好程序員怎么可能"笨"呢!哈哈!俺們可都是天之驕子啊!小心我扔你雞蛋啊!
很聰明的程序員一般比較自信,難以聽進別人的意見,在一個團隊中,最怕的并不是怕沒有技術好的人,而是怕那些很聰明的人不跟你團隊保持一致,舉個例子,可能團隊里有一套通用的數據存取方法,但聰明的程序員會堅持己見,自己發明出一套新的方法來!聰明的程序員會認為自己更懂客戶的需求,而不顧市場人員提出的需求.這也是為什么很多人會說"要對團隊中聽話的人委以重任",我當然不同意這種看法,但是,既聰明團隊意識又好的人,就比較少見了.團隊不行的話,一個人再聰明又有什么用?
4.聰明的程序員喜歡自己重新發明輪子!笨的程序員喜歡利用聰明的程序員寫出的代碼!
5.聰明的程序員一般有自己思維的定勢,笨的程序員因為什么都不懂,所以他的眼里什么都是可能,什么都是不可能!查找代碼問題的時候,聰明的程序員首先會說:這是系統的bug,笨的程序員會看看自己的代碼是不是有拼寫錯誤!笨的程序員跟容易換位思考,下面有個例子:
一段關于web開發問題的程序員和客服人員的對話:
“從昨天開始我們的用戶就看不到我們站點上的Logo了。”
“他試過重啟瀏覽器么？”
“是的。”
“他試過重啟電腦么？”
“是的。”
“他清空過瀏覽器Cache么？”
“是的。”
“他的瀏覽器版本是IE6么？”
“是的。”
“他確信是真的看不到Logo了么？”
“是的。”
“他是在電腦顯示器屏幕上看我們的站點么？”
“什么？”
“比如說，它可能是打印出來看不到？”
“不。他是在顯示器上看的。”
“除了站點Logo之外，他是不是其他的圖片都看不到？”
“什么？哦。我再問問他。”
也許,聰明的程序員遇到這個問題的時候,甚至可能去找個圖形算法分析下這個圖片是否有問題!
最后,以http://blogoscoped.com/archive/2005-08-24-n14.html中的故事結尾,,以博列為看官一笑^_^
It’s like the story of the centipede(蜈蚣). The centipede was very good at walking with its hundred legs. It never spent a thought on just how it could walk. Until one day, when a big black bug(臭蟲) asked the centipede “How can you manage to walk with all those feet? Don’t you find it hard to coordinate their rhythm?” The black bug already left, when the centipede was still sitting down, pondering how it could walk, wondering, and (for the first time in his life) even worrying a little bit. From that day on, the centipede couldn’t walk anymore.
So you better not think too much if you want to achieve something. And of course this is only half the truth, too...
]]>
alert("偶要吃意大利面!");
alert("偶要吃巧克力慕思!"); 嗯，這個例子碰巧是用javascript寫的，不過你就算不懂JavaScript，應該也能明白它在干什么。
拷貝代碼不好。于是，你創建了個函數
alert("偶要吃" + food + "!");
}
SwedishChef("巧克力慕思");
現在你留意到有另外兩段代碼幾乎跟它們一模一樣，除了一個反復調用一個叫BoomBoom的函數，另一個反復調用一個叫PutInPot的。除此之外，這兩段代碼簡直沒什么兩樣:
PutInPot("龍蝦");
PutInPot("水");
BoomBoom("雞肉");
BoomBoom("椰子醬");
alert("拿" + i1);
f(i1);
f(i2);
}
Cook( "雞肉", "椰子醬", BoomBoom );
你的編程語言能辦到嗎？
等等……假如我們已經有了PutInPot和BoomBoom這些函數的具體實現代碼（而且又不需要在別的地方重用它們），那么用內聯語法把它們寫進函數調用里面不是比顯式的聲明這兩個函數更漂亮嗎？
"水",
function(x) { alert("pot " + x); } );
Cook( "雞肉",
"椰子醬",
function(x) { alert("boom " + x); } );
當你一想到作為參數的匿名函數，你也許想到對那些對數組里的每個元素進行相同操作的代碼。
a[i] = a[i] * 2;
}
alert(a[i]);
}
for (i = 0; i < a.length; i++){
a[i] = fn(a[i]);
}
}
map( alert, a );
var s = 0;
for (i = 0; i < a.length; i++)
s += a[i];
return s;
}
function join(a){
var s = "";
for (i = 0; i < a.length; i++)
s += a[i];
return s;
}
alert(sum([1,2,3]));
alert(join(["a","b","c"]));
var s = init;
for (i = 0; i < a.length; i++)
s = fn( s, a[i] );
return s;
}
function sum(a){
return reduce( function(a, b){ return a + b; }, a, 0 );
}
function join(a){
return reduce( function(a, b){ return a + b; }, a, "" );
}
如 果你想將函數視為一類對象，Java要求你建立一個有單方法的對象，稱為算子對象。許多面向對象語言要你為每個類都建立一個完整文件，像這樣開發可真叫 快。如果你的編程語言要你使用算子對象來包裝方法（而不是把方法本身當成對象），你就不能徹底得到現代（動態）編程語言的好處。不妨試試看你可否退貨拿回 些錢？
不用再寫那些除了經過一個數組對每個元素做一些事情之外一無是處的函數，有什么好處？
讓我們看回map函數。當你要對數組內的每個元素做一些事，你很可能不在乎哪個元素先做。無論由第一個元素開始執行，還是是由最后一個元素執行，你的結果都是一樣的，對不？如果你手頭上有2個CPU，你可以寫段代碼，使得它們各對一半的元素工作，于是乎map快了兩倍。
或 者，發揮一下想像力，設想你在全球有千千萬萬臺服務器分布在全世界的若干個數據中心，你有一個真的很大很大的數組，嗯，再發揮一下想像力，設想這個數組記 錄有整個互聯網的內容。還了，現在你可以在幾千臺服務器上同時執行map，讓每臺服務器都來解決同一個問題的一小部分。
那么在這個例子里面，編寫一段非?？斓拇a來搜索整個互聯網這個問題，其實就和用一個簡單的字符串搜索器（算子）作為參數來調用map函數一樣簡單了。
希 望你注意到一個真正有意思的要點，如果你想要把map/reduce模式變成一個對所有人都有用，對所有人都能立刻派上用場的技術，你只需要一個超級天才 來寫最重要的一部分代碼，來讓map/reduce可以在一個巨大的并行計算機陣列上運行，然后其他舊的但是一向在單一個循環中運行良好的代碼，仍可以保 持正確的運行，惟一的差別只是比原來單機運行快了n倍。這意味著它們都一不留神突然變成可以被用來解決一個巨大的問題的代碼。
讓我再啰嗦一下，通過把“循環”這個概念加以抽象，你可以把用任何你喜歡的方式來實現“循環”過程，包括可以實現讓循環迭代速度隨著硬件計算能力保持令人滿意的同步增長。
你現在應該可以明白不久為何對那些對除了Java之外什么都沒被學過的計算機系學生表示不滿了：
( http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html ) ：
Without understanding functional programming, you can't invent MapReduce, the algorithm that makes Google so massively scalable. The terms Map and Reduce come from Lisp and functional programming. MapReduce is, in retrospect, obvious to anyone who remembers from their 6.001-equivalent programming class that purely functional programs have no side effects and are thus trivially parallelizable. The very fact that Google invented MapReduce, and Microsoft didn't, says something about why Microsoft is still playing catch up trying to get basic search features to work, while Google has moved on to the next problem: building Skynet^H^H^H^H^H^H the world's largest massively parallel supercomputer. I don't think Microsoft completely understands just how far behind they are on that wave.
不理解函數式編程，你就發明不了MapReduce這個讓Google的計算能力如此具有可擴展性的算法。Map和Reduce這兩個術語源自Lisp語言和函數式編程……（這是另一篇文章的內容，emu也不是很理解其中的各種說法的來龍去脈，就不翻譯了）
我希望你現在明白，把函數當成基本類型的（動態）編程語言能讓你在編程過程中更好的進行抽象化，也就是使代碼精悍、功能更內聚、更具可重用性及更具有擴展性。很多的Google應用使用Map/Reduce模式，因此一有人對其優化或修正缺陷，它們就都可以從中得益。
我 準備要再羅嗦一下，我認為最有生產力的編程語言莫過于能讓你在不同層次上都可以進行抽象化的。老掉牙的FORTRAN 語言以前是不讓你寫函數的注。C 有函數指針，可是它們都非常丑丑丑丑丑丑丑丑陋，不允許匿名聲明，又不能在用它們時實現它們而偏偏要放在別處去實現。Java讓你使用算子對象，一種更丑 陋的東西。正如Steve Yegge所述，Java是個名詞王國
( http://steveyegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html )。
作者注：這 里提起了FORTRAN，不過我上次使用FORTRAN是27年前的事了。FORTRAN是有函數的，我碼字那會兒腦子里面想的大概是GW-BASIC語 言。（emu注，basic確實只有所謂的子程序和go-sub語句，作用只是重新組織代碼結構而已，沒有參數和調用堆棧，因此沒有真正的函數調用）
譯者注：原作者起了《你的編程語言可以這樣做嗎》這個標題其實并不是這篇文章的真正價值所在，我轉這篇文章也不是因為原作者可以把語言的初級技巧玩得轉，而是因為這是一篇map/reduce模型的示范。
]]>
我一直堅定自己從事互聯網行業的工作,就是因為在這個舞臺上,每個人都可能有機會,每一個人都更加能夠發揮自己的主觀能動性,而且更加容易.作為互聯網企業中最前線的員工---開發人員,如果企業不能提供一個有效的機制來激發他們創作的激情,而只是把他們當作工具來使用的話,那么很難想像企業的前途.又聯想到現在google大量高級開發人員,甚至管理人員都紛紛出走,究其原因,是因為這里限制了他們的創造性.我相信,沒有一個其它的行業能比處在互聯網行業這個時代的浪潮之尖的行業中更能體會到創造的樂趣!
所以,我認為,互聯網企業中,公司與開發人員的關系這個問題,應該要被提到公司的戰略管理的高度來重視這個問題.
]]>
]]>
剛看了序言,把里面精彩的兩段摘錄下來:
Web2.0...Getting users to participage is the first step.Learning from those users and shapping your site based on what they do and pay attention to is the second step.
在web2.0中,讓用戶參與到你的系統中來只是其中的第一步,更多的是要從這些用戶的行為中不斷學習,并在這些經驗的基礎上優化你的web站點
It's not longer enough to know how to build a database-backed web site.If you want to succeed,you need to know how to mine the data that users are ading,both explicitly and as a side effect of their activity on your site.
如果你想成功的話,僅僅局限于知道怎么構建一個基于數據路的web站點還是很不夠的,你需要知道怎么從用戶增加的web內容中提煉出有用的數據.
]]>