Google總部的工作環境

時代雜誌報導的Google總部的工作環境,這對技術人員來說應該是天堂吧!!



分類: ,

Livedoor社長堀江貴文 樓起樓塌的傳奇

(取材自華爾街日報亞洲版)

在日本警方1月16日晚間突襲搜查Livedoor公司之前,堀江貴文可說是日本企業界最突出、最受爭議的一顆明星。儘管日本媒體與產業界對他的批評不斷,這名33歲的年輕人用10年的時間,藉由併購、股票分割等各種財務手段,不斷擴張他的企業王國。

日本檢察官13日以違反證券法起訴堀江貴文,Livedoor股價崩跌之餘,下市的可能性進一步升高。不過,短短兩個月前的去年12月,Livedoor市值衝上70億美元,幾乎與馬自達汽車(Mazda)相等。而 Livedoor的年營收只有約6.61億美元,不到馬自達的3%。

好出鋒頭 行事招搖

堀江貴文好出鋒頭,和一向行事低調的日本企業界完全不同。他從不穿整齊的西裝,和演藝明星大談戀愛,常常招搖地開著法拉利在各種場合出現。日本企業向來總是步步為營地擴增產品線和工廠,但堀江一手創立的Livedoor卻以追求股票市值為目的,大玩各種令日本業界瞠目結舌的財務手段。而現在,這一切都已成過去,堀江貴文本人在1月23日被捕,日本檢方以違反證交法的罪名起訴他,指控崛江貴文與另外三名主管偽造帳面數字,散布不實消息,以拉抬旗下子公司的股價。

Livedoor的醜聞常被西方媒體拿來與美國世界通訊(Worldcom)的詐欺事件相提並論。堀江貴文講求敵意併購、炒作股票市值的經營風格也極具美式精神。過去三年來,日本層出不窮的併購案為日本經濟注入強心劑,而且這股開放改革的風潮似乎不會因為Livedoor的醜聞而逆轉。

堀江貴文出生於日本南部的農業小城福岡,在他出版的20多本書中,他把他的家庭定位在「中產階級的下層」。堀江貴文從小就不太合群,老師也不看好他,但是他依然考進東京大學。

1996年,23歲的崛江貴文還是大學生時,他向親友借得5萬美元開設一家網頁設計公司,名稱來自金屬樂團史密斯飛船的一首歌:刀鋒生活(Livin' On The Edge)。後來併購另一家公司後,改名成Livedoor。

堀江貴文沒多久就從東大退學,專心經營生意。就在這時候,日本政府逐步放寬市場法規,希望能培育更多新創公司與企業領導者。1999年,日本開放以股票交換的方式進行併購。2001年,日本政府解除股票分割的一項限制,好讓投資人更容易購買股票。

堀江貴文找到宮內亮治協助他利用這些法規優勢。宮內亮治是一名沈默寡言的稅務會計師,後來一直擔任Livedoor的財務長,他也在1月23日與堀江貴文同時被捕。

Livedoor在2001到2004年之間進行四次股票分割,包括 2004年2月一次史無前例的1:100分割。理論上,股票分割成十股,每股價格就變成原來的十分之一,但是由於日本股票分割需時約50天,在這段期間內被分割的股票會因為供不應求而不斷上漲,Livedoor藉此大大推升了市值。在2004年2月的那次分割中,Livedoor股票暴漲成原來的四倍。

其他日本公司有樣學樣。一家線上音樂公司New Deal在2004年2月進行一次1:1000的分割,迫使東京證交所去年把股票分割比例限制在1:5。

2004年崛江貴文企圖收購經營不善的日本職棒歐力士野牛隊,因而聲名大噪。2005年,Livedoor向雷曼兄弟公司借資7億美元,突襲日本富士電視台,一度擁有富士電視35%股權,成為最大股東。富士電視後來被迫以投資Livedoor的方式與堀江貴文和解,避免遭受併購的命運。

去年9月的日本國會大選中,日本首相小泉純一郎更選定堀江貴文作為他打擊政敵的「刺客」之一,試圖使堀江貴文選上日本國會議員,不過最後敗選。

Livedoor的股票在遭受檢調突擊後巨量下跌90%,湧進的賣單還一度在1月20日使東京證交所電腦當機。Livedoor股票目前在東京證交所劃歸特殊觀察名單,只能半日交易,並且隨時可能被判下市。

股票大跌 隨時下市

日本證管機關的監督不力被視為Livedoor醜聞的成因之一,日本證券交易監視委員會(SESC)只有307名成員,美國證券管理委員會(SEC)則有3,865名成員。

堀江貴文已經辭去Livedoor社長一職,新任社長平松庚三是名60歲的傳統企業家,目前正極力挽救公司。據熟悉內情的人表示,關在牢裡的堀江貴文特意吩咐他的律師,請人不時去駕駛他的法拉利,以免電池沒電。

分類:

Yahoo! UI Library and Design Pattern Library

Yahoo! Developer Network今天announce Yahoo! User Interface LibraryYahoo! Design Pattern Library

Yahoo! User Interface Library是Yahoo!的Ajax Library,是少數支援JS&Dom Improvement、Ajax Connection Management、Visual Effect 與 UI Widget的Ajax Library

Yahoo! Design Pattern則整理Yahoo! Web2.0網頁設計的Guideline和Pattern,支援Creative Commons



分類:

Google ajax webpage edit

又有新的Google網路傳言,有此一說,Google將推出名為Trogdor的ajax webpage edit,如果屬實,製作ajax網頁將更容易了

分類:

There are Too Many Ajax Calendars

Joel thinks there are Too Many Ajax Calendars

Quote: For all the Ajax calendars that are appearing, it's a shame I can't find one which really meets my needs. ... But anyway, how many Ajax Calendar Companies do you think Yahoo! is gonna buy? You don't build a product for one customer. It's just too risky.

分類: ,

30Boxes Calender

CalendarHubKiko是兩個還不錯的Ajax-based Calendar,最近,又發現另一個不錯的Calendar - 30 Boxes

優點:支援中文、可快速增加event、可分享行事曆、整合Flickr、Yahoo Messager及Google Map、支援iCal匯出、可變換介面(theme)、可顯示各國Holiday(但無台灣)

缺點:速度慢、無iCal匯入功能、介面操作似不如其他Calendar順暢

2.JPG


分類: ,

檢驗網站是否為web2.0的工具

3.JPG


http://web2.0validator.com/ 是一個檢查某一網站是否為web2.0的工具,非常有趣的web2.0網站,輸入要查詢的網址後,它會檢查並回應分數。實際用flickr的網址輸入後,居然只有3分!! flickr不是web2.0網站嗎?? 還是檢查條件太嚴苛了!? 另外輸入這個網站的網址檢查,居然回應Do not taunt happy fun validator. 真是太狡滑了

分類:

專案品質的5點想法

1. 有效且持續的溝通,並排除專案成員的抗拒是首要解決的事
專案經理大部分的時間都在做溝通的工作,但溝通必須是有效且持續的。另外,一些品質控制方法的採用,例如各種測試與審查,常對專案成員現有的工作產生衝擊,甚至抗拒,此時,專案經理首要之務是排除專案成員的抗拒,讓工作能順利執行。


2. 品質控制需要額外資源的投入
因為專案時程有限,而達到完美的品質需投入大量資源,專案經理應有此認知,在品質與時程之間做取捨。


3. 品質管理應從源頭做起
從源頭就控管品質,如果在程式開發或上線前,才發現架構設計疏失,此時的修改成本就比設計階段更大。所以說,及早發現疏失,其修正的成本較小。


4. 文件品質與程式品質一樣重要
文件品質與程式品質一樣重要,甚至更重要,因為文件品質會影響程式品質。例如設計文件沒做好,造成開發人員依錯誤的架構做程式開發。


5. 開發人員是程式品質的守門員
測試個案不見得考慮周詳,系統整合測試不一定完整測試所有功能,所以不能依賴系統整合測試做最終的檢驗。開發人員是程式開發的第一線,應該仔細、反覆(iteration)、徹底的執行單元測試。SA與SD受限於資歷或經驗,可能會有考慮不周之處,所以開發人員在開發時,如果有任何問題(特別是需求不清楚、流程兜不上、架構有問題、邏輯不正確) 隨時提出討論。


分類:

Lessons Learned的重要

有人說最佳實務(Best Practise)是專案執行時的典範,經驗學習(Lessons Learned)則是不好的錯誤,其實不全然是對的。不管是正面或負面的事情,都可以成為專案的Lessons Learned,作為以後專案的參考。

國家地理頻道上曾看過,發現號太空梭發射失敗爆炸,科學家花了很多時間找出失敗原因,居然是一片隔熱板的脫落造成的。另外,例如飛機失事、工安意外等事件,你會發現,外國人急於找出錯誤原因,以免同樣錯誤再次發生。也許是文化差異,老外對於Lessons Learned非常重視,反觀我們,雖然孔子說過"不貳過",但從歷史上,多少朝代(可能也包括現在吧)都發生外戚及宦官干政,導致政局動盪,甚至改朝換代。不從過去失敗經驗中記取教訓,會導致相同錯誤重複再發生。

另外,專案的Lessons Learned並不是只有在結案時才蒐集,等到結案時才蒐集,可能早忘了;也不是只有專案經理能提供Lessons Learned,所有stackhoder在專案執行過程中,都可以提供給專案經理。暸解專案管理的人雖知道Lessons Learned,可是卻往往忽略其重要性。而一個專案團隊沒有過去經驗的累積,或經驗累積於少數key person的記憶中,沒有紀錄下來,這樣的團隊常會重複發生相同的錯誤。

分類: ,

Copyright © Andy Cheng

Distributed By My Blogger Themes | Blogger Theme By NewBloggerThemes Up ↑