搜索常見的算法以及模型思考

寫這篇文章,緣自于前幾天部門內部成員們進行了一次部門內部現有涉及的一些算法的review以及整理。不過比較囧的就是,由于boss不在,我們討論討論著就成了吐槽大會,倒是有一半時間在吐槽產品以及業務部門了~~

不過這也算是一件可喜可賀的事情了,這也可以看做是我們數據部門,已經由開輕型挖掘機向深挖階段邁步了。

挖掘算法

因此,借此機會,也對自己接觸過的,了解過的,或者做過的一些勉強稱得上算法的東西做一個梳理。其實,就個人來說,本身就不是做算法出身的,在大學時代,學習的反倒是網絡方面多一些,更不知數據挖掘算法為何物。

其實,就所謂算法而言,個人認為,我有個同事說的很對:所謂算法,并不是說那些復雜的數學模型才是算法,哪怕是你寫的一個簡單的計算公式,只要能夠解決現有業務的痛點,有了自己的模型思路,它就是一個算法,只是它可能不夠通用,只能解決特定業務需求而已。

在大規模的數據前提下,其實很多復雜的算法過程,反而效果沒有這么好,或者說,我們會想方設法去簡化其過程。

舉個簡單栗子:假設有一批大規模數據集,就以近千萬篇博文為例。如果提供一篇博文,讓你去查詢與其相似度最高的top N,那我們的通常思路是什么?通常的做法是計算這篇博文與其他博文的相似度,至于相似度的計算方法就很多了,最簡單的就是計算其向量夾角,根據向量夾角判定相似程度。OK,就算你用最簡單的計算過程,你試想一下,運算近千萬次需要多久?或許,有的人說,俺使用hadoop,利用分布式的計算能力來完成這個任務,但如果實際操作起來,你就會發現這是一個多么蛋疼的事情。

再舉一個簡單栗子(好吧,多吃點栗子):比如SVM,這是一種難以收斂的算法,在大數據的前提下,有些人希望使用它,但又希望使用更多的數據來訓練模型,畢竟手里數據量太大,很多人還是希望使用盡量多的數據訓練的,以達到模型更準確的目的。但是,隨著訓練數據量的增大,像SVM這種難以收斂的算法,其耗費的計算資源還是很巨大的。

東拉西扯說了這么多,自個的梳理工作還沒有完成呢!

一、這些年,我開過的挖掘機

(1)最早接觸的應該是貝葉斯的分類了

貝葉斯算是分類算法中最簡單的算法了,初學挖掘機算法的人十有八九第一個愛上的絕對是它。其實,貝葉斯的原理真的很簡單,就是依據統計學的最大概率原理。這么簡單,但是就是尼瑪這么好用,多年依然屹立不倒。

訓練過程就缺乏可陳了,基本上貝葉斯的都這樣,由于是文本,所以一套流程下來,分詞,去停詞,作為最基本的知識點向量,然后就計算模型概率了。不過比較有趣的是,分類過程是放在Storm里頭做的,相當于這是一個實時的分類業務。

(2)說到了文本,自然少不了分詞算法了

其實說到分詞算法,反倒沒啥可說的。如今互聯網上各種開源的分詞工具,都已經做的很好了,效果也差不了多少,想進一步改進的話也夠嗆。至于說深入到分詞算法的內部,涉及上下文法分析,隱含馬爾科夫模型等東西,如果是個人出于興趣去研究,那我沒話說;如果是小公司,花費人力物力去優化分詞效果,我只能說他們閑著蛋疼;如果是大公司,人家金多任性也是可以理解的。

所以,至今來說,個人對于分詞方面的東西,也僅限于初步了解分詞算法的衍變,內部大概涉及的算法,以及幾種分詞工具的使用。

其實,在文本挖掘方面,僅僅針對于文本的分詞是不夠的,因為我們使用分詞拆分出來的單詞,往往很多跟業務都是沒有關系的,通常做法是,建立對應業務字典,至于字典的建立,當然也是需要分詞的,再進行進一步的加工,甚至可能會加上一些人工的工作。

(3)下一個就是實時熱點分析了

我也不知道這算不算是算法,說到實時,自然跟Storm又有關系了(好吧,我承認我是搞這個之后開始接觸數據的)。說到實時熱點,可能大伙兒都摸不著頭腦,舉個簡單栗子就明了了。

玩hadoop的童鞋都知道WordCount這個經典栗子,MapReduce在Map到Reduce的過程中,自動將相同的Key通過類似hash的方法聚合到一起了,所以,統計單詞這個需求通過MR來做是辣么的簡單。

那Storm的實時WordCount呢?好吧,這也是一個能夠記錄到實時技術領域史書上的經典案例(好吧,其實它就是一個Storm的HelloWorld)。Storm雖然沒有類似MR那種自動Hash的功能,不過它也提供了一種數據分組流策略,也能達到類似的效果,并且它不像MR那樣是批量的,它是實時的、流式的,也就是說你能動態的獲取到當前變換的單詞詞頻。

實時熱點分析,如果我們把熱點映射成單詞,那我們是不是就可以實時的獲取到當前Top N的熱點了。這個方向可是有很大的研究價值的,實時地掌握了用戶的熱點導向,我們就可以動態的調整業務策略,從而衍生更大的數據價值。

不過,總體來說,這個數據模型更多依靠的是Storm這個實時工具的本身功能,模型設計上的東西反倒是少了。至于說算不算是算法模型,就跟前面所說的那樣,看個人看法吧,你說是就是了~~

(4)國內很成熟的一種建模--推薦

就目前在國內做數據挖掘的來說,可能分類與推薦是做的最多的兩種方向。分類就不多說了,就比如剛才所說的貝葉斯,簡直就是分類中的鼻祖算法了。

可能一說到推薦算法,有人腦海里立馬就閃現出關聯規則、協同過濾、余弦相似性等這些詞。這是沒錯的,但我要說的不是這個。其實個人想說的是推薦就兩個方向:基于用戶,基于內容。

我們需要注意兩點,我們推薦的對象是用戶,或者說是類似用戶這種有動作行為的實體;而推薦的東西則就是內容,他沒有動作行為,但是他有不同的屬性,或者用更磚業說法描述就是他必然有知識點。

基于用戶推薦,我們看重的不是內容這個實體,而是用戶本身的行為,我們認為用戶的行為必然隱含著一些信息,比如,人的興趣導向,那么既然你有了相關的行為,那么我按照你的行為去給你推薦一些東西,這總是有一定道理的。

基于內容的推薦,我們的側重點則是內容,這就跟用戶的歷史行為無關了。我們潛意識的認為,既然你會看這個內容,那么跟這個內容有關系的內容,你是不是也感興趣呢?或許這樣說有失偏頗,但是大體方向是對的。

至于之前說的那些關聯規則也好,協同過濾也好,余弦相似性也好,其實就是研究知識點與知識點之間關系所建立的模型。

針對于基于內容推薦,其知識點就是內容之中的各種屬性,比如影片推薦,其知識點可能就是各種評論數據、點播數據、頂踩數據、影片類型、演員、導演以及其中的一些情感分析等等;又比如博文,其知識點可能就是一個個帶權的詞,至于這個詞就涉及到詞的抽取了,再說到詞的權重,可能就會涉及到TFIDF模型、LDA模型了。

而針對基于用戶,其知識點最直接的體現就是用戶的行為了,就是用戶與內容之間的關系,不過深究下去,又會發現,其實跟內容的知識點也緊密聯系,只不過這可能不止一個內容實體,而是多個內容實體的集合。

(5)文本單詞的加權模型

前面正好提到了TFIDF以及LDA模型,所以順帶也就講講文本單詞相關的加權模型吧。

說到文本挖掘,可能大部分人都熟悉TFIDF模型,既然涉及到了,那就簡單的說一說。我們知道,文本的知識點就是一個個的單詞,雖然都是單詞,但也總有哪個詞重要程度高一點,哪些詞重要程度會低一點吧。

或許有人會說,出現多的詞就重要。沒錯,那就是詞頻,簡單的來想,這種思路并沒有錯,并且,早期的文本挖掘模型就是這么做的。當然,效果肯定是一般般的。因為那些經常出現的詞往往都是一些沒用的常用詞,對文章的作用并不大。

直到TFIDF模型的出現,才根本性地解決了文本挖掘知識點建模的問題。如何判斷一個詞的重要程度,或者專業點的說法就是判斷其對文章的貢獻度?TFIDF通過詞的詞頻來加大詞在文章中的權重,然后通過其在多個文章中的文檔頻率來降低其在文章中的權重。說白了就是降低了那些公共詞的權重,把真正貢獻度大的詞給暴露出來。這基本就是TFIDF的基本思路了,至于詞頻權重怎么加大,文檔頻的權重怎么降低,這就涉及到具體的模型公式了,根據不同的需求進行調整就OK了。

關于文章知識點主題建模的另外一種很重要的模型,那就是LDA模型了。它是一種比較通用的文章主題模型,它通過概率學原理,說白了就是貝葉斯,建立起知識點(也就是詞),主題和文章的三層關系結構。詞到主題有一個概率矩陣,主題到文章也有一個概率矩陣的映射關系。

好吧,LDA不能再說下去了,再說下去就露餡了。因為,俺也不是很懂啊。對于LDA,雖然部門內部有在使用,但是我沒有做過具體的模型,只是和同事討論過它,或者更確切的說向同事請教過它的一些原理以及一些設計思路。

(6)相似度計算

相似度計算,比如文本的相似度計算。它是一個很基礎的建模,很多地方就用的到它,比如剛才我們說到的推薦,其內部關聯的時候,有時候就會涉及到計算實體間的相似度。

關于文本的相似度,其實方法有很多。通常會涉及到TFIDF模型,拿到文本的知識點,也就是帶權的詞,然后通過這些帶權的詞去做一些相似度的計算。

比如,余弦相似模型,就是計算兩個文本的余弦夾角,其向量自然就是那些帶權的詞了;又比如,各種算距離的方法,最著名的歐式距離,其向量也依然是這些詞。還有很多諸如最長公共子串、最長公共子序列之類的模型,個人就不是很清楚了。

總之,方法很多,也都不是很復雜,原理都很像。至于哪個合適,就得看具體的業務場景了。

(7)文本主題程度--信息熵

曾經和同事嘗試對數百萬的博文進行領域劃分,把技術博文劃分成不同的領域,比如大數據領域、移動互聯網領域、安全領域等等,其實說白了還是分類。

一開始我們使用貝葉斯進行分類,效果還行,不過最終還是使用SVM去建模了。這都不是重點,重點是我們想對劃分到某一領域下的技術博文進行領域程度判斷。

我們想了很多辦法,嘗試建立了數據模型,但效果都不是很理想,最終回歸到了一個最本質的方法,那就是使用文本的信息熵去嘗試描述程度,最終結果還是不錯。這又讓我再一次想到同事說過的那句話:簡單的東西不一定不好用!

信息熵描述的是一個實體的信息量,通俗一點說就是它能夠描述一個實體的信息混亂程度。在某一個領域內,知識點都是相似的,都是那些TFIDF權重的詞,因此,是不是可以認為,一個文本其信息熵越小,其主題越集中越明顯,信息的混亂度越低,反過來說,有些文本主題很雜亂,可能包含了多種領域的一些東西,其領域的程度就會降低。

最起碼表面上,這種說法是行得通的,并且實際的效果還不錯。

(8)用戶畫像

用戶畫像這個方向可能是近兩年比較火的方向了。近年來,各大互聯網公司,各大IT企業,都有意識的開始從傳統的推薦到個性化推薦的道路衍變,有些可能做的深一些,有些可能淺一些。

商業價值的核心是用戶,這自然不用多說。那么如何結合用戶進行推薦呢,那就是用戶的屬性,那關鍵是用戶的屬性也不是一開始就有的,我們所有的只是少量用戶的固有屬性以及用戶的各種行為記錄。我們連用戶是啥子里情況都不清楚,推個毛啊!

所以,我們需要了解用戶,于是對用戶進行用戶畫像分析就很有必要了,其實就是把用戶標簽化,把用戶標記成一個個屬性標簽,這樣,我們就知道每一個用戶大概是什么情況了。一些商業行為,也就有了目的性。

至于說如何對用戶的每一個畫像屬性進行填充,這就看具體的情況了。簡單的,用幾個簡單模型抽取到一些信息填充進去;復雜的,使用復雜的算法,通過一些復雜的轉換,給用戶打上標簽。

(9)文章熱度計算

給你一大坨文章,你如何判斷哪篇文章比較熱,哪篇文章比較矬,換個說法就是,我進入一個文章列表頁,你能給我提供一個熱文章的排序列表嗎?

可能大部分的思路都很直接,拿到文章能夠體現熱度的屬性,比如點擊率、評論情感分析、文章的頂踩情況,弄個簡單加權計算模型,咔咔就出來了。

本質上這沒錯,簡單的模型在實際的情況中不一定不好使,部分屬性也的確能夠體現出一篇文章的熱度,通過加權計算的方式也是對的,具體的權重就需要看具體情況了。

但如果這么做的話,實際上會出現什么情況?今天我來了,看見了這個熱度推薦列表,明天我來了,還是看到這個列表,后天我來了,依然是這個列表。

尼瑪,這是啥情況,咋天天都是這個破列表,你要我看幾遍?!不錯,這就是現實情況,造成的結果就是,越熱的文章越來越熱,越冷的文章越冷,永遠的沉底了,而熱的文章永遠在前頭。

如何解決這個問題?我們把時間也加入參考,我們要把老文章通過降權的方式,把他人為的沉下去,讓新文章有出頭的機會。這就是說,需要我們把創建時間也加入權重中,并且隨著時間推移,衰減其熱度權重,這樣,就不會出現熱的一直熱,冷的一直冷了。至于衰減的曲線,就需要看具體業務了。

這樣就能解決根本問題了嗎?如果文章本身信息量就不夠呢,比如,本身大部分就是新文章,沒有頂踩,沒有評論,甚至連點擊曝光都很少,那用之前的模型就行不通了。

那是不是就無解了呢?方法還是有的,比如,我們尋找到一個相似的站點,他也提供了類似最熱文章推薦的功能,并且效果還很不錯。那么,我們是不是就可以借助它的熱度呢?我們通過計算文章相似度的方法,復刻出一個最熱列表出來,如果站點性質相似,用戶性質相似,文章質量不錯,相似度計算夠準確,相信這個熱度列表的效果也是會不錯滴(這方法太猥瑣了~~)。

(10)Google的PageRank

首先,別誤會,我真心沒有寫過這個模型,我也沒有條件去寫這個模型。

認識它了解它,緣自于跟幾個老同學合伙搞網站(網賺客www.wzk001.com,有興趣的可以去看看)。既然搞網站吧,作為IT人猿,一些基本的SEO的技術還是需要了解的。于是,我了解到:想要增大網站的權重,外鏈是不可缺少的。

我跟我幾個老同學說,你們去做外鏈吧,就是逮住網站就放咱網站的鏈接。他們問到:一個網站放的鏈接越多越好嗎?放的網站越多越好嗎?啥網站放比較好?這都不是重點,關鍵是他們問:為毛啊?

把我問的那個是啞口無言啊,于是我一怒之下就去研究PageRank了。PageRank具體的推演過程我就不說了(況且憑借我這半吊子的水平也不一定能說清楚),其核心思想有幾個:當一個網頁被引用的次數越多時,其權重越大;當一個網頁的權重越大時,其引用的網頁權重也隨之增大;當一個網頁引用的次數越多時,它引用的網頁給它帶來的權重越低。

當我們反復迭代路上過程時,我們會發現某個網頁的的排名基本就固定了,這就是PageRank的基本思路。當然也有個問題需要解決,比如,初始網頁如何給定其初始權重,高計算迭代過程如何簡化其計算過程等等。這些問題,在Google的實際操作中,都做了比較好的優化。

(11)從互聯網上定向抓取數據

其實我估摸著這跟算法沒很大關系了,不過既然有數據的獲取設計流程,也勉強算是吧。

之所以有這個需求,是那段時間搞網站搞嗨了,給自己整了個工作室網站,想給別人尤其是一些小企業搭建包括輕度定制企業網站(是不是挺瞎折騰的-_-),也確實是做了幾個案例(我的工作室網站:www.mite8.com,有興趣去看看)。

于是乎,俺就想啊,如何給自己找客戶?工作室的客戶應該是那些小企業的老板,并且還必須是目前沒有企業門戶的。作為一個搞數據的程序猿,并且還是開挖掘機的,雖然是半路出身非藍翔畢業且無證上崗,但好歹是挖過幾座山頭的呀。

如今是互聯網橫行的時代,他們總會在互聯網上留下一些蛛絲馬跡,我要把它給逮出來!我的目標很明確,我要拿到那些無企業網站的企業郵箱,然后做自己EDM營銷(電子郵件營銷)。

1)我先從智聯檢索頁面,抓取了企業規模小于40人的企業名稱,事實證明智聯招聘的頁面還是很好解析的,都是靜態的,并且格式很規整,所以很容易就分析出一批小企業的企業名來了;

2)拿到了企業名,我如何判斷這個企業已經有了獨立的企業官網?通過分析,我發現通過搜索引擎檢索這個企業名的時候,如果有企業官網的話,一定是在首頁。并且其頁面地址也是有一定規律的,那就是:獨立官網的開頭通常是www開頭的,長度一般不會太長,收尾通常是index.html、index.php以及index.asp等等。

通過這些規則,我就可以將那些有企業官網的企業名給pass掉了。其中遇到了兩個難點,一個就是搜索引擎的很多頁面源碼都是動態加載的,于是我模擬了瀏覽器訪問的過程,把頁面源碼給抓取下來了,這也是爬蟲的通用做法;第二個就是,一開始我嘗試的是通過百度去獲取,結果百度貌似是有放結果抓取的一些措施,導致結果不如人意,于是我換了目的,使用的是360的檢索,問題就解決了(事實證明百度在搜索引擎方面比360還是強了不少的),并且效果也差不多。

3)解決了排除的問題,那根本的問題就來了,我如何拿到企業的企業郵箱?通過分析搜索引擎的返回結果,我發現很多小企業喜歡用第三方網站提供的一些公司黃頁,里頭包含了企業聯系郵箱;還有部分公司發布的招聘信息上會帶有企業郵箱。

通過數據解析,終于拿到了這部分數據,最后還做了一些類似郵箱是否有效的基本解析等等。最終拿到了大概3000多個企業郵箱,有效率達到了80%以上。

問題是解決了,但還是有些地方需要優化的:首先就是效率問題,我整整跑了近12個小時,才把這3000多個郵箱給跑出來,太多需要解析的地方,并且模擬的瀏覽器在效率上不高;其次就是對郵箱的有效不是很好判斷,有些郵箱根本就是人為瞎寫的;還有就是部分網站對郵箱進行了圖片化混雜處理,即做成了類似的驗證碼的東西,防抓取,我沒有對圖片類的郵箱數據進行解析,其實這個問題也是有解決辦法的,我們拿到一些樣本圖片,進行圖片字母識別的訓練,這樣就能解析出其中的郵箱了。

總體來說,這次體驗還是挺有成就感的,畢竟在業余的時間解決了自己實際中的一些痛點,熟練了一些所學到的東西,或者說實施的過程中學到了很多東西。

ps:github上檢索webmite就是這個項目了,我把代碼托管到了github上,或者從我的博客上進入。

二、對自己做一個總結吧

其實個人的缺點很明顯,首先就是沒有經過系統的數據挖掘學習(沒去過藍翔,挖掘機自學的),也就是野路子出身。因此對很多算法的原理不夠清楚,這樣的話,對于有些業務場景,可能就提不出有建設性的意見了。并且,對于很多算法庫的使用,還是不夠了解的。

其次就是在數學功底上有所欠缺。我們知道,一些復雜的算法,是需要有強大的數學基礎的。算法模型,其本質就是數學模型。因此,這方面也是我的短板吧。

由于個人是由做大數據偏向挖掘的,基于大數據模式下的數據挖掘過程,可能跟傳統的數據過程有很大的不一樣。比如,數據的預處理過程,大數據挖掘的預處理很多依賴的是目前比較流行的分布式的一些開源系統,比如實時處理系統Storm、消息隊列Kafka、分布式數據收集系統Flume、數據離線批處理Hadoop等等,在數據分析存儲上可能依賴的Hive以及一些Nosql會多一些。反倒對于傳統的一些挖掘工具,比如SAS、SPSS、Excel等工具,個人還是比較陌生的。不過這也說不上是缺點吧,側重點不一樣。總體而言,大規模數據的挖掘將會是趨勢。

三、給小伙伴們的一些建議

說了這么多,前面的那些東西可能對大伙兒的用處并不是很大,當然對于開挖掘機的朋友還是有一定幫助的。現在我想表達的東西可能跟挖掘就沒有直接的關系了,更多的給動物園動物(程序猿,攻城獅)的學習以及自我進化的建議。

(1)為了學到東西,臉皮是毛玩意兒?

對于這點,個人可是深有體會。想當年(好吧,這個詞還是很蛋疼的),大學那會兒專業是信息安全,偏向于網絡多一點,因此在語言方面更多的是c和c++,對于java可是連課都沒有開的,說白了就是用java寫個HelloWorld都不會。

剛畢業那會兒,興沖沖地跑去公司寫c,結果不到一個月,新項目來了,需求變了(尼瑪,開發最怕的就是這句話),變了就變了吧,尼瑪要研究大數據,用c能干毛啊!一些個開源系統工具,十個倒是有九個是java寫的。當時我就哭了!

于是就糾纏著一個同組的伙伴,逮住時間就問他問題,有些問題在熟悉java的人看來,絕對是白癡又白癡的。但是對于初學者來說,絕對是金玉良言,人家一句話的事,如果自己去查找,可能是幾個小時都搞不定。一個月之后,總算入門了,后面就輕松多了。

往后的一些日子里,遇到了一些問題,總是會厚著臉皮纏著交流群中的一些大拿們死問,慢慢地就進步了。近段時間,開始學習scala,幸好旁邊有個scala小高手,哈哈,可苦了他了~~

所以,遇到自己不懂的東西,不要怕自己的問題簡單不好意思問,一定要臉皮厚!你連這么簡單的問題都不懂,你還有資格擔心自己的臉皮?!

(2)交流與分享

對于交流與分享這點感想,緣自于2012年末研究Storm的那段時間。Storm在2012年那會兒,并不像今天這樣火,研究的人也不多,無處交流,可用的資料就更少了,所以解決起問題來很費事。

當然其中有幾個博客給我的幫助還是很大的,包括了“大園那些事兒”、“莊周夢蝶”等幾個博客,都是早期研究Storm并且分享經驗技術的博客。當時我就萌生了寫博客的想法。

在往后的時間里,我花費了很大一部分精力,將我學到的Storm相關的東西整理了出來,并且由于當時感嘆沒有一個很好的交流平臺,創建了“Storm-分布式-IT”技術群(群號191321336,主要搞Storm以及大數據方面的,有興趣的可以進來),并把整理的資料、代碼、經驗分享到了平臺以及博客中。

由于我一直主張“進步始于交流,收獲源于分享”這個理念,不斷有搞技術的朋友加入到這個大家庭中,并且不斷的把一些經驗技術反饋到群貢獻中,達到了一個良性的循環。 短短不到兩年的時間,群已經發展到了千人,并且無論是技術氛圍還是群員素質,在IT技術群中絕對可以算的上名列前茅的。

就個人從中的收獲來看,這種交流是能夠學到很多的東西的,你要相信三人行必有我師,這句話是有道理的。而分享則是促進交流的基石,只有讓大家意識到自己所收獲的東西是源自于別人的分享,這樣才能讓更多的人參與進來。

兩年多來,我也一直堅持自己寫博客,分享一些自己的經驗技術,或者沒有這么高大上,哪怕是對自己涉及到的一些技術做一個備份也好啊。我的個人博客站SEO學堂www.wocaoseo.net如今也有不少文章了,其他人能用到就最好,用不到,權當自己做的一個技術文檔的備份(博客蟲中已經有不少搞技術的朋友分享自己技術了,有想法有分享意向的朋友也可以找我哦)。

其實說了這么多,想表達的意思就兩點:多多與他人交流,聽取他人的意見;至于分享自己的所得,這就是屬于良心發現了。

(3)多看書,隨時給自己大腦補充營養

其實這點也不止是給大伙兒的建議,也算是給自己的一個告誡吧。

個人在這方面做的也不是很好,很久之前給自己定了一個目標:一個月看完一本書。結果工作的問題,其他雜七雜八的事情很多,這個一直沒有落實下來,至今買來的《我的互聯網方法論》才看了前幾章。最好的案例算是上上一個月,我花費了近一個月上下班等地鐵、倒地鐵的零碎時間,終于把《構建之法:現代軟件工程》給看完了。

書中有沒有顏如玉我不知道,但書中肯定有黃金屋。平時多看一些書,多學一些,跳槽時跟面試官總是能多嘮一些的,哈哈,提薪酬的時候是不是底氣就足了些?!

關于說看書的內容,工作中涉及的一些必須了解,必須看的我就不多說了。如果業余時間比較多,還是推薦多涉獵一些其他相關領域,畢竟,人不可能一輩子就只窩在自己那一畝三分地上的;就算你一直堅持某個技術方向,隨著時間的推移,技術的升華也必然會涉及到其他很多的相關知識。

所以,多看書,多充實一下自己,這一定是對的!

(4)經常梳理一下自己,整理一下自己

經常給自己做一下梳理工作:自己目前掌握了哪些東西,目前自己缺乏什么東西,掌握的東西夠不夠,缺乏的東西如何去彌補。這些都是需要我們經常去反思的,只有整理清楚了自己,才知道自己要干什么,才有目標。

當然梳理完了,你還需要去實際操作,不然的話,你會發現,每一次梳理,結果都是一樣的。我們需要在每一次梳理過后,進行對比,了解自己進步了多少。當然每一次梳理,都是為了給自己做一個計劃,計劃自己大概需要在哪些方向進行加強。

其實很多人一到了跳槽季就猶猶豫豫,其實他們對目前的工作已經是有所不滿的了,但是總感覺自己能力不夠,可能辭了也難找工作。這是因為他們對自己認識的不夠,連他自己都不明白自己到底有多少料,那么,請問面試官會知道嗎?

如果,你對自己掌握了多少東西都一清二楚,核心領域已經熟悉了,相關領域也有所涉獵,那么你還在擔心什么呢?如果真有面試官對你說no,你可以說:hi,剛好我也沒什么時間,我還回去挑選offer呢!

(5)善于在實際生活中尋找學習的動力

人是懶惰的,很多時候,有些事情可做可不做的,往往人都是不去做的,也不愿意去深根究底。

這個我很想學,那個我也很想了解,關鍵是一到大周末,我更想躺被窩!說到底,就是沒有學習的動力!

也就是說,我們要善于在實際的生活中,尋找到推動我們取學習的理由。

舉幾個簡單的栗子:

1)之前也說過,有段時間在研究網站。為了讓網站推廣出去,各種去研究SEO,現在來看,自己雖然遠遠達不到一個SEO專業人員的標準,但最起碼是知道了為毛通過搜索引擎檢索,有些網頁就排在前面有些就排在后面(PageRank算法);也知道了怎么去編譯一篇文章,更好的方便搜索引擎收錄(等俺失業了,不搞挨踢了,去做網編估計也是行的,又多了一條活路,哈哈)等等。

2)為了給EDM尋找目標,我自己使用業余的時間去分析互聯網上的數據,然后寫代碼,跑數據,測試數據等。其實,在那之前,我對爬蟲的了解是不多的,對于網頁數據的解析也不在行,這完全都是通過“從互聯網抓取有用數據”的個人需求上去驅動的。還不止如此,拿到郵箱之后,為了讓EDM郵件看起來更“磚業”一點,我開始自學如何使用html來制作好看的電子營銷郵件頁面。

3)曾經有一段時間,工作很是清閑,突發奇想的把大學時想寫小說的夢給圓了。于是就開始在縱橫小說網上寫小說。不過,這都不是重點,重點是縱橫要求每一個作者給自己的小說配小說封面。我去問了一下,尼瑪一張破封面需要20多大洋。心想,一張破封面就要20大洋,自己都是搞IT的人,干脆不自己P一個呢。于是,我開始撿起了大學時期放棄的PS學習計劃,只用了兩個星期,PS基本功能就熟練了。后來的話,自己的封面當然是搞定了,并且還服務了至少數十位作者朋友們。當然,這都是題外話了。至于小說,哈哈,不但簽約了,稿費還是掙了上千大洋,關鍵是過了一把寫小說的癮。在PS技術方面,雖然跟專業的前端人員比不得,但是改改圖、修修照片還是木有問題滴。

4)遠的太遠,說一個近一點的事吧。前一段時間開始學習scala,其實就個人需求來說,寫那個項目用java來寫也完全能夠搞定,但關鍵是我對我自己說,錯過了這次機會,下次說不定啥時候才有決心去學習這個很有前途的語言了。于是,狠下心使用這個全新的語言去開發,過程雖然磕磕絆絆,畢竟馬上使用一種陌生的語言去敲代碼是很蛋疼的事,但一個星期來,結果還是不錯的,最起碼一些基本的用法是會了。完事開頭難,熟悉了一些基本的東西,剩下的就是累積的過程了。

其實這些歸結起來就一個觀點:我們要適時的給自己找一些理由,逼著我們自己去學習,去獲取新的東西,去提升自己。

或許有人會說,哥我天天加班,還有毛線時間去問問題、去交流、去看書,大周末的好不容易有假期了,吃飽了我不去睡覺去給自己找動力干不給錢的活,我腦抽啊?!好吧,如果你是這么想的,抱歉耽誤了你這么多睡覺的時間。

其實上面說了這么多零碎的栗子,關鍵還是在于態度!你有沒有想學習的欲望,有沒有提升自己、升華自己的想法,有沒有升職、加薪、當上UFO、迎娶白富美的念頭。是的,這些東西都是自己去做的,沒人逼你。如果你有這些想法的話,那么這些東西多多少少還是有一些幫助的。

除了對待事情的態度,我們的心態也很重要,看待事情要樂觀一點。前幾天,群里有個搞互聯網招聘的朋友問我:你是搞技術的吧?我說是。他說我認識很多搞技術的都很悶,不像你這么開朗。我說我不想哪天死在了馬桶上~~

搞IT的給大部分人的映象確實是悶騷、不善言談、不善交際。其實也是,每天大量的工作,領導又開會訓人了、產品這邊需求又改了,確實讓人瘋狂。工作壓力大是IT人的標準屬性了。

我們需要調整好自己的心態,就像之前所說的,學習一個東西,雖然可能會占用本來就不多的業余時間,但是我們應該不是那種單純為了解決問題而去學習,去獲取,當成一種提升自己、升華自己的途徑,而不是逼不得已的無奈之舉。如果一份工作,你確認自己不喜歡,那就別猶豫,果斷跳吧!腦中有貨還怕找不到買家!

時刻警醒自己對待任何事情要有一個好的態度,認清自己,抓住一切機會提升自己、升華自我,保持一個良好的心態,這就是我想說的東西。

吭吭唧唧說了一大坨,其實我也知道很多是廢話,但是我依然希望,我的這些廢話能夠幫助到你,做為同一個動物園里的人,一起努力吧!

上一篇:李彥宏論搜索引擎三個定律
下一篇:淺談網頁搜索排序中的投票模型

網友回應

說點什么吧
  • 全部評論(0
    還沒有評論,快來搶沙發吧!

歡迎掃描關注我們的微信公眾平臺!

歡迎掃描關注我們的微信公眾平臺!

福彩3d天齐网