A. 打算用兩個月左右時間自學計算機C語言，（即將讀專業計算機科學與技術，）求各路神仙指點～～
別聽上面說的什麼單片機，那個主要是電氣和通信類學的，你學的那個專業主要是軟體方向的，C語言是必學的課程，也是很重要的課程，為以後學其他的打下很好的基礎，記住語言都是相通的，所以你要學好C，你說的那邊書，我也學過，其實各種版本的書都差不多，就是這些內容，沒必要糾結這些，重點就是指針，這是C語言的精華，指針可是程序員殺手啊，當然書上用到的指針都是很簡單的一些題目咯，我建議你花上兩個小時把整本書翻翻看看吧（看把戲），然後可以把書上的每一個代碼都敲到電腦上運行一下，看看能否正確運行，你運行之後就會發現，書上有很多代碼都有那麼點錯誤，呵呵，主要是興趣咯，你看前面幾章的時候沒必要太糾結那些定義，記住定義就行了，你越學到後面，前面理解的就越清楚，最好是學快點，不然還沒看到後面的精華就忘了前面的了，進大學後，你就可以去一些大學的ACM網站（編程競賽的）做一些C語言題目，主要是學習演算法，這個對以後很有用的，鍛煉你的邏輯思維哦，這是我上學期學C的經驗，希望對你有幫助。
B. 大專生北漂10年，月薪翻20倍，我的人生從不被學歷設限
我是一枚工作10年的IT老兵，目前就職於北京互金行業某公司BI工程師崗位。
初入社會，二十齣頭的我帶著一身學生的稚氣，對工作、職業規劃、社交關系一無所知，只知道自己迫切想要找到一份工作，要干一番事業，但又不知道自己到底能幹什麼，應該干什麼，找起工作來像個無頭蒼蠅，到處亂投簡歷。
沒有目標的行動果然是失敗的，很長一段時間我都沒有找到工作，後來家裡人托親戚朋友幫我在北京找了一份工作，也不知道工作內容具體是什麼，只知道工資是1500，當時想著能有錢賺總比我在家裡待著好，我就迷迷糊糊坐上了去北京的火車，開啟了我的北漂夢.....
「北漂」——1.5k的現實太骨感
沒到北京之前，我對這個國際大都市滿懷憧憬，在北京的火車上，我幻想過很多到了北京之後的場景，想像著自己西裝革履穿梭在帝都的CBD之間，和各種優秀的職場「白骨精」們邂逅。
辦公室里開著中央空調，工位上排列堆放著整齊的文件夾，每天過著電視里那樣「朝九晚五」的生活。
但，一切的夢想在我到達北京後破碎。
剛到北京，帶著家裡人給的盤纏，在親戚的幫助下租好了房，隨後去親戚介紹的公司報道。踏進辦公司的那一刻才發現和我想像的完全不一樣。
我人生的第一份工作是在一家算上老闆一共只要7個人的招投標公司，安排給我的職位叫做「軟體工程師」，聽起來高大上，但實際上就是個打雜的小嘍啰。
辭職轉行，坎坷旅途中找到方向
在招投標公司上班日子對我來說是一種煎熬，無數次想過辭職回老家，但我又不甘心，在自己一事無成的時候離開北京看起來更多像是在逃避。
在多次的痛苦思索後，我決定嘗試新的職業方向，於是我辭去了第一份工作，通過自己的努力，跳槽了，工資也從1500漲到了6000。
剛開始工作時還沉浸在漲薪的喜悅中，但是沒多久發現周圍的同事都是本科、碩士、博士…而我是單位里學歷最低，工資也最低的人，頓時喜悅感全無。
知道差距才能想辦法縮小差距 ，於是我開啟了瘋狂學習的狀態，專升本學習和PHP技術培訓並行展開，白天上班，晚上下班後WEB前端培訓課上到九點，周末PHP後端和專升本學業連軸轉，整整一年沒日沒夜學習，讓我收獲頗豐，也順利拿到了本科學歷。
本以為自己的努力能夠得到相應的回報，但現實很殘酷，薪資增長緩慢，職位也依然沒有變化，正當我一籌莫展的時候，偶然的機會，我接觸到了「帆軟」。
我與帆軟相識是2013的事，那時單位拿下一個大項目，需要做有色金屬工業統計網上直報(分析)系統，完成歷史數據入庫，通過填報功能收集企業新數據，最後做分析展示。整個項目周期大概兩年。
考慮到工程量大，成本高，周期長等因素，公司放棄自研，准備藉助工具實現，經過考察和選型之後選定帆軟工具來實現。在這次項目中我主要負責功能開發，我的搭檔負責效果展示。
學習一個新的工具來開發產品不是一件容易的事情，還好帆軟產品的幫助文檔非常詳細，通過對幫助文檔的一頓狂啃，以及我和搭檔的不斷嘗試下，一套像模像樣的系統終於完成，並且順利地通過了驗收。
跳槽舒適圈，選擇互金領域
在單位待了6年，不知不覺到了而立之年，此時的我對於自己的職業規劃有了更加清晰的認知，這里的穩定和舒適不是我想要的，我需要更大的平台來發揮我的價值。
於是我決定再一次跳槽，放棄事業單位的穩定，憑借從事帆軟產品的經歷和一張FCRP證書，入職了當年風頭正盛的互金公司，薪資也從10k漲到了20k。
新公司的確有很多項目機會，一過去我就被安排到一個平台項目。仗著自己對帆軟平台的熟悉，一過去就直接上手開幹了。
但了解之後才發現事情並不簡單，公司之前都是自己開發，各個部門有自己的系統，數據口徑不一、不規范，同事還總質疑「你們的數據准確嗎」......一系列的問題像一座座大山壓在我面前，我決定從重要的經營分析入手，先做出點東西來。
通過產品以及業務部門的不斷battle，在一次次痛苦的開會討論後，終於讓業務部門發現原來繁瑣的sql取數，Excel整理等操作居然可以通過平台簡化為自動刷新自動取數！這會我才鬆了口氣，算是在公司站穩了腳跟。
行業驟變，裁員不斷
本以為自己到了一個好的平台，終於可以大展身手了，但意外又發生了！
記得那個周一，回到公司，就發現自己部門被裁了一半的人。
公司人員減少了，需求卻只增不減。我察覺這可能是平台推廣的一個好時機，於是我們開始對接內部審計、對外披露、人力財務等核心部門，讓每個業務線的領導可以清晰看到自己部門的績效。
果然，所有的努力都沒有被辜負，在19年年底，領導發了內部信說以後的數據平台以我們這個BI平台為准，把公司的數據口，都歸攏到一起。我這才真正的鬆了口氣，歷經了公司4輪的裁員潮，我幸運地堅持了下來，薪資從原來的20k漲到30k。
回歸社區，不斷學習
在我剛剛學習FineBI的時候，幫助文檔給了我很大的幫助，對產品了解越來越深後，我也開始上手嘗試完善幫助文檔，大概有寫過100篇左右。
我是一個在IT行業深耕10年的老兵，我的故事就說到這里。
C. 為什麼要用nodejs
著作權歸作者所有。
商業轉載請聯系作者獲得授權，非商業轉載請註明出處。
作者：FengqiAsia
鏈接：http://www.hu.com/question/19653241/answer/15993549
來源：知乎
要講清楚這個問題，先講講整個Web應用程序架構（包括流量、處理器速度和內存速度）中的瓶頸。瓶頸在於伺服器能夠處理的並發連接的最大數量。Node.js解決這個問題的方法是：更改連接到伺服器的方式。每個連接發射一個在Node.js引擎的進程中運行的事件，而不是為每個連接生成一個新的OS線程（並為其分配一些配套內存）。Node.js不會死鎖，因為它根本不允許使用鎖，它不會直接阻塞 I/O 調用。Node.js還宣稱，運行它的伺服器能支持數萬個並發連接。
Node本身運行V8 JavaScript。V8 JavaScript引擎是Google用於其Chrome瀏覽器的底層JavaScript引擎。Google使用V8創建了一個用C++編寫的超快解釋器，該解釋器擁有另一個獨特特徵：您可以下載該引擎並將其嵌入任何應用程序。V8 JavaScript引擎並不僅限於在一個瀏覽器中運行。因此，Node.js實際上會使用Google編寫的V8 JavaScript引擎，並將其重建為可在伺服器上使用。
Node.js優點：
1、採用事件驅動、非同步編程，為網路服務而設計。其實Javascript的匿名函數和閉包特性非常適合事件驅動、非同步編程。而且JavaScript也簡單易學，很多前端設計人員可以很快上手做後端設計。
2、Node.js非阻塞模式的IO處理給Node.js帶來在相對低系統資源耗用下的高性能與出眾的負載能力，非常適合用作依賴其它IO資源的中間層服務。3、Node.js輕量高效，可以認為是數據密集型分布式部署環境下的實時應用系統的完美解決方案。Node非常適合如下情況：在響應客戶端之前，您預計可能有很高的流量，但所需的伺服器端邏輯和處理不一定很多。
Node.js缺點：
1、可靠性低
2、單進程，單線程，只支持單核CPU，不能充分的利用多核CPU伺服器。一旦這個進程崩掉，那麼整個web服務就崩掉了。
不過以上缺點可以可以通過代碼的健壯性來彌補。目前Node.js的網路伺服器有以下幾種支持多進程的方式：
#1 開啟多個進程，每個進程綁定不同的埠，用反向代理伺服器如 Nginx 做負載均衡，好處是我們可以藉助強大的 Nginx 做一些過濾檢查之類的操作，同時能夠實現比較好的均衡策略，但壞處也是顯而易見——我們引入了一個間接層。
#2 多進程綁定在同一個埠偵聽。在Node.js中，提供了進程間發送「文件句柄」 的功能，這個功能實在是太有用了（貌似是yahoo 的工程師提交的一個patch） ，不明真相的群眾可以看這里： Unix socket magic
#3 一個進程負責監聽、接收連接，然後把接收到的連接平均發送到子進程中去處理。
在Node.js v0.5.10+ 中，內置了cluster 庫，官方宣稱直接支持多進程運行方式。Node.js 官方為了讓API 介面傻瓜化，用了一些比較tricky的方法，代碼也比較繞。這種多進程的方式，不可避免的要牽涉到進程通信、進程管理之類的東西。
此外，有兩個Node.js的mole：multi-node 和 cluster ，採用的策略和以上介紹的類似，但使用這些mole往往有一些缺點：
#1 更新不及時
#2 復雜龐大，往往綁定了很多其他的功能，用戶往往被綁架
#3 遇到問題難以解決
Node表現出眾的典型示例包括：
1、RESTful API
提供RESTful API的Web服務接收幾個參數，解析它們，組合一個響應，並返回一個響應（通常是較少的文本）給用戶。這是適合Node的理想情況，因為您可以構建它來處理數萬條連接。它仍然不需要大量邏輯；它本質上只是從某個資料庫中查找一些值並將它們組成一個響應。由於響應是少量文本，入站請求也是少量的文本，因此流量不高，一台機器甚至也可以處理最繁忙的公司的API需求。
2、Twitter隊列
想像一下像Twitter這樣的公司，它必須接收tweets並將其寫入資料庫。實際上，每秒幾乎有數千條tweet達到，資料庫不可能及時處理高峰時段所需的寫入數量。Node成為這個問題的解決方案的重要一環。如您所見，Node能處理數萬條入站tweet。它能快速而又輕松地將它們寫入一個內存排隊機制（例如memcached），另一個單獨進程可以從那裡將它們寫入資料庫。Node在這里的角色是迅速收集tweet，並將這個信息傳遞給另一個負責寫入的進程。想像一下另一種設計（常規PHP伺服器會自己嘗試處理對資料庫本身的寫入）：每個tweet都會在寫入資料庫時導致一個短暫的延遲，因為資料庫調用正在阻塞通道。由於資料庫延遲，一台這樣設計的機器每秒可能只能處理2000條入站tweet。每秒處理100萬條tweet則需要500個伺服器。相反，Node能處理每個連接而不會阻塞通道，從而能夠捕獲盡可能多的tweets。一個能處理50000條tweet的Node機器僅需20台伺服器即可。
3、電子游戲統計數據
如果您在線玩過《使命召喚》這款游戲，當您查看游戲統計數據時，就會立即意識到一個問題：要生成那種級別的統計數據，必須跟蹤海量信息。這樣，如果有數百萬玩家同時在線玩游戲，而且他們處於游戲中的不同位置，那麼很快就會生成海量信息。Node是這種場景的一種很好的解決方案，因為它能採集游戲生成的數據，對數據進行最少的合並，然後對數據進行排隊，以便將它們寫入資料庫。使用整個伺服器來跟蹤玩家在游戲中發射了多少子彈看起來很愚蠢，如果您使用Apache這樣的伺服器，可能會有一些有用的限制；但相反，如果您專門使用一個伺服器來跟蹤一個游戲的所有統計數據，就像使用運行Node的伺服器所做的那樣，那看起來似乎是一種明智之舉。
總的來說，Node.js的應用場景
1) 適合
JSON APIs——構建一個Rest/JSON API服務，Node.js可以充分發揮其非阻塞IO模型以及JavaScript對JSON的功能支持(如JSON.stringfy函數)
單頁面、多Ajax請求應用——如Gmail，前端有大量的非同步請求，需要服務後端有極高的響應速度
基於Node.js開發Unix命令行工具——Node.js可以大量生產子進程，並以流的方式輸出，這使得它非常適合做Unix命令行工具
流式數據——傳統的Web應用，通常會將HTTP請求和響應看成是原子事件。而Node.js會充分利用流式數據這個特點，構建非常酷的應用。如實時文件上傳系統transloadit
准實時應用系統——如聊天系統、微博系統，但Javascript是有垃圾回收機制的，這就意味著，系統的響應時間是不平滑的(GC垃圾回收會導致系統這一時刻停止工作)。如果想要構建硬實時應用系統，Erlang是個不錯的選擇
2) 不適合
CPU使用率較重、IO使用率較輕的應用——如視頻編碼、人工智慧等，Node.js的優勢無法發揮
簡單Web應用——此類應用的特點是，流量低、物理架構簡單，Node.js無法提供像Ruby的Rails或者Python的Django這樣強大的框架
NoSQL + Node.js——如果僅僅是為了追求時髦，且自己對這兩門技術還未深入理解的情況下，不要冒險將業務系統搭建在這兩個漂亮的名詞上，建議使用MySQL之類的傳統資料庫
如果系統可以匹配Node.js的適用場景，那麼是時候採取具體的措施來說服老闆了。
說服自己老闆採用Node.js的方式
構建一個簡單的原型——花一周時間構建系統某一部分的原型是非常值得的，同時也很容易和老闆在某一點達成一致，等到系統真的在某一部分應用了Node.js，就是打開局面的時候
尋找開發者——首先JavaScript語言的普及度很高，一般公司都不乏Web前端工程師，而此類工程師的學習門檻也非常低。這就意味著Node.js很容易招人，或者公司就隱藏了一些高手
強大的社區支持——Node.js社區非常活躍，吸引很多優秀的工程師，這就意味著公司可以很容易從社區得到免費或者付費的支持
系統性能考慮——JavaScript引擎Google V8，加之原生非同步IO模型，使得Node.js在性能的表現非常出色，處理數以千計的並發請求非常輕松
專業公司的支持——使用開源技術的最大問題是，原作者不承諾對其產品進行技術支持或者質量保證。現在Node.js已經得到Joyent公司的贊助，這就保證了未來Node.js的發展是可持續性的