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的发展是可持续性的