Lucene中文斷詞
如果要使用Lucene的斷詞程式,最好看一下 1. Lucene介紹投影片 (推薦) 2. Lucene簡介 (推薦) 3. 當前幾個主要的Lucene中文分詞器的比較 4. Lucene 3.0的中文分詞系統 (推薦) 5. Lucene
如果要使用Lucene的斷詞程式,最好看一下 1. Lucene介紹投影片 (推薦) 2. Lucene簡介 (推薦) 3. 當前幾個主要的Lucene中文分詞器的比較 4. Lucene 3.0的中文分詞系統 (推薦) 5. Lucene
I-List is a very helpful links share platform to share your collected links. It provides
http://www.ithome.com.tw/itadm/article.php?c=81487&s=2 摘錄:「簡立峰表示,為何我們常會覺得自己的機會很少,那是因為我們只從美國市場的角度來看,就會覺得臺灣的機會很少。例如現在很多人提到的Big Data趨勢或是資料科學家的職務,這些都是美國的新趨勢和新職位,但臺灣的時候還沒到。因為臺灣和美國的產業結構不一樣,我們得回頭從臺灣自己的產業特性來看臺灣的機會,以及未來的人才需求。 」 的確,簡總經理提的觀念我們這些IT人員也看到了。我國IT產業向來是硬體、韌體強勢,軟體偏弱。資金也較多流向硬體/韌體。是故難有較多Big Data、Cloud應用。我這幾年來存疑的問題,也得到了一些驗證。那就是「成功模式不能一昧地複製」,美國推展Big Data、Cloud Computing,是因為它的背景環境(需求)形成了,才能推動這些策略跟應用。但是我國不盡然,除非這家公司從以前到現在都是在做國外軟體應用市場,”資料”夠多且累積了很多”開發經驗”,否則在沒經驗的情況下,投錢進去有蠻高的機率造成虧損。 套一句老話:「(潛在)需求在哪裡,機會就在那裏。」
此次參加2013 Hadoop Taiwan Conference,收穫很多。(以下是手動隨便寫寫,請勿拘泥writing format) 業界方面的進展比學界又更加跨出一大步,也代表著我們之後如果要發表雲端相關運算的論文或是發展技術, 要特別小心注意這類工具。 由於Big Data時代的來臨,現在的雲端運算處理偏重於「即時」運算,而非「批次」運算。 我們目前所學的hadoop map/reduce只能算是非常基本而已。 對於即時運算的需求恐怕還不太夠(Hive/Pig 也不例外)。 Google先看到這個嚴重情形,繼2009年以來,陸續發表Google Caffeine
資料庫…,不只是資料庫。 推薦網路資源閱讀清單順序: [SQL SERVER][Memo]淺談SQL Server如何處理查詢陳述句 SQL Server Index介紹 [SQL SERVER][Memo]Clustered VS NonClustered Indexes [SQL SERVER][Memo]再談
各位在使用SQL Server做資料庫轉移還原時,有時候可能會發現原本授權的帳號無法登入使用資料庫(假設原本資料庫上的使用者為admin,而新移植的資料庫使用者也叫做admin,但是移植過去後,無論怎麼授權admin給這個資料庫,都會出現無法授權的情況)。這是因為資料庫的使用者SID不一致所導致的。 此時,只要到這個資料庫,執行兩個步驟: 1. 執行指令:EXEC sp_change_users_login ‘report’; 找出有哪些孤兒使用者(orphaned users)? 2. 執行指令: EXEC sp_change_users_login ‘Auto_Fix’, ‘找到的使用者名稱’;
在許多Javascript MVC的framework中,除了ExtJS、Backbone.js、YUI、EmberJS以外,AngularJS 也是目前最被熱烈討論的Javascript MVC framework之一。他除了有Google大神的支持以外,也使用MIT授權協議,逐漸成為商業產品的熱門選擇。 如果各位有興趣的話,可以先看以下Slides介紹,再搭配Will保哥的介紹文服用。 相關連結: AngularJS: Overview 前端工程的極致精品: AngularJS 開發框架介紹 AngularJS中文電子書 (推薦)
在雲端運算(氾濫)的時代,所有服務都講求加速再加速,傳統的單一伺服器(Server)服務多個用戶端(Client)的方法,在面臨行動網路用戶迅速增多,而造成大量資源索取時,無論是資料的傳輸、服務的回應時間,反而變得「緩不濟急」。 因此,CDN(Content Delivery Network,內容傳遞網路)的技術興起,正是運用雲端運算分散式計算的概念,加速資料的存取與降低伺服器端的負載。 傳統網路服務模式與CDN服務模式(取自Wiki) 我們傳統的網路服務模式如上圖左,所有的用戶端都連線到伺服器上索取資源。但是,當用戶數量成長到百萬數量級時,伺服器的負擔便會開始變得重,回應時間慢,開始發生取不到資源的狀況。而這個現象若發生在向伺服主機業者租賃虛擬主機或是雲端主機的服務提供商(Service Provider, 這邊簡稱SP) 而言,可不是一個好兆頭。因為這些主機商會跟SP依照頻寬、IO數量與CPU運算量計價,代表著錢都還沒進來就開始付出昂貴的費用了,更不用說因為網路服務不穩、回應時間太慢造成客戶流失的慘劇。 因此,CDN的出現變成了這些服務提供商的救星。CDN網路主要是靠著分散在各地的(雲端)主機,就近提供這些服務提供商的用戶資源。 它有著巨量的頻寬與速度,只要服務提供商將主機網址(例如,http://www.example.com) 寄放給CDN,CDN業者的主機便會先到http://www.example.com 抓取靜態的資料(主要是圖檔、影片、一些雜七雜八肥大的線上存取函式庫等等),然後將這些靜態資料派送給這一大群CDN網路內的主機。 因此,過沒多久,所有的CDN主機都有同樣的資料複本(如上圖右),那麼使用者在跟這個SP提供的服務做連線時,在索取圖像、影片等資料時,會「就近」選擇最近的CDN。例如,台灣的使用者,連上某個美國的服務時,會先到新加坡的CDN主機進行存取,由於網路封包路由比較近,速度上會快很多。 這項技術已經被很多雲端服務業者採用,例如FB就是一個例子,它很多照片都是委託給akamaihd.net這個CDN來幫忙做圖床複本,所以大家在載入時便會快很多(但是安全性就…)。
需求分析(RA, Request Analysis): 系統分析(SA, System Analysis): 進行開發前所需的工作: 確認開發工具:IDE選擇,開發函式庫選擇,使用的程式語言。 版本控制:Git or SVN? 版本號命名規則? 程式開發準則:Coding Style、參數訂定