2016年6月

以后的博客该怎么写?

最近,博客写的比较少,因为一直在思考编程思想,而这些思想都不太成熟,所以博客写的比较少。
但是,最近关于前后端知识体系的整理也比较熟悉了,所以也开始思考写博客的意义了。

除了编程思想以外,就数编程经验最重要了,而编程经验的获取,不外乎熟能生巧。比如许多互联网企业面试都考察算法一样,个人觉得,如果把算法当成高考科目来教育,没准我国的高中毕业生的整体水平能完爆那些面试前刷了几个月面试题的程序员。为啥,如果成为高考科目,分分钟出现几十种教辅资料把基础算法讲解的透彻务必,每天一张卷子做得高考生怀疑人生,即使死记硬背也能牢牢记住。就像大家高中锻炼出来的哑巴英语,在大学两年没使用,拿出来还能过个六级什么的。

有的时候,还会怀念高中时代的充实。当然,那是最适合娱乐的年纪却没有娱乐的时光,但是那种方向明确,有人引领的感觉是进了大学到现在都难以体会的。大学里面学习的东西比较脱离市场,未来不知所措;工作后学的东西乱七八糟,独自摸索。

到了现在,无论承不承认,以后自己的发展就围绕Web方向了,或许还有机会扩展到其他相关领域,比如大数据,客户端等。那么现在最重要的就是要熟能生巧,要多去熟练前后端各种框架技术的用法,总结规律,提高效率,不能光去学习思想而不去实践。古人说过:纸上得来终觉浅,绝知此事要躬行。

从今日开始,依据现有的分类,把每种语言,每种框架使用中遇到的问题,如何解决的,有了哪些新的想法都要记录下来。
除此以外,时常总结经验,明确自己发展方向,走错一步就落后一步,及早总结发现自己的错误。

《Head First Servlets & JSP》笔记

第一章:
P17 content-type(内容类型)响应首部的值成为MIME类型。
P21 端口是一个16位数,标识服务器硬件上一个特定的软件程序。TCP端口只是一个数字而已。

第二章:
P37 Servlet也需要帮助。请求到来时,必须有人实例化servlet,或者至少要建一个新的线程处理这个请求,必须有人调用Servlet的doPost()或doGet()方法。
P41 容器提供的功能:通信支持、生命周期管理、多线程支持、声明方式实现安全、JSP支持。
P44 在Servlet从容器中得到的响应对象中,可以拿到一个PrintWriter。使用这个PrintWriter能够将HTML文本输出到响应对象。
P49 除了把URL映射到实际的Servlet,还可以使用部署描述文件对Web应用的其他方面进行定制,包括安全角色、错误页面、标记库、初始配置信息等。
P49 实际上,容器使用了一组很复杂的规则来寻找匹配的servlet,它会根据客户请求提供的URL查找位于服务器某个位置的一个具体Java类。
P65 一个完全兼容的J2EE应用服务器必须有一个Web容器和一个EJB容器(以及其他一些部件,包括JNDI和JMS实现)。Tomcat是一个Web容器,而不是完整的J2EE应用服务器,因为Tomcat没有EJB容器。

第三章:
P80 要记住,最后servlet要从请求接受一个参数,在模型上调用一个方法,把信息保存在JSP能找到的一个位置上,再把请求转发给JSP。
P86 servlet把请求转发给JSP。然后,JSP从请求对象得到数据。
P88 容器提供了一种称为“请求分派”的机制 ,允许容器管理的一个组件调用另一个组件。
P89 RequestDispatcher view = request.getReqeustDispatcher("result.jsp");view.forward(request, response);

第四章:
P95 容器根据请求中的URL查找正确的servlet,为这个请求创建或分配一个线程,并调用servlet的service()方法(确定调用哪个Servlet方法)。
P96 service()方法结束,所以线程要么撤销,要么返回到容器管理的一个线程池。
P97 你可能听过别人这么说,“servlet的每个实例……”。但这种说法是错误的。任何servlet类都不会有多个实例,只有一种特殊情况除外。
P104 每个Servlet都有一个ServletConfig对象,每个Web应用有一个ServletContext对象。
P108 对,除了GET和POST之外,确实还有其他一些HTTP 1.1方法,包括HEAD、TRACE、OPTIONS、PUT、DELETE和CONNECT。
P118 如果没有在表单中之处method="POST",就会默认为HTTP GET请求。
P119 单个参数可以有多个值!这说明需要一个返回数组的getParameterValues(), 而不是返回String的getParameter()。
P123 还有可能创建一个servlet来处理计算机驱动的请求,其中请求体包含要处理的文本或二进制内容。
P123 既然客户对服务器是远程的,所以getRemotePort()是指“得到客户的端口“。getLocalPort()和getServerPort()的差别很微妙,getServerPort() 是”请求原来发送到哪个端口“,getLocalPort()是指”请求最后发送到哪个端口“。
P126 使用响应对象向客服发回数据会对响应调用两个方法:setContentType()和getWriter(),在此之后,只需要完成I/O将HTML写至流。
P132 不过ServletResponse接口只提供了两个流可供选择: ServletOutputStream用于输出字节,PrintWriter用于输出字符数据。
P132 PrintWriter实际上”包装“了ServletOutputStream,也就是说,PrintWriter有ServletOutputStream的一个引用,而且会把调用委托给ServletOutputStream。
P133 setHeader()会覆盖现有的值;addHeader()会增加另外一个值。

P157 上下文初始化参数与servlet初始化参数很类似,只不过上下文参数对整个Web应用可用,而不是针对一个servlet。
P165 她想监听一个上下文初始化事件,这样就能得到上下文初始化参数,并在应用为客户提供服务之前运行一些代码。

P236 禁用cookie的用户会忽略"Set-Cookie"响应首部。
P238 此时,容器并不知道cookie是否工作,所以向客户返回第一个响应时,它会同时尝试cookie和URL重写这两种做法。
P239 根本就不能对静态页面完成URL重写!使用URL重写只有一种可能,这就是作为会话一部分的所有页面都是动态生成的!
P253 但是不存在setCookie()方法。只有一个addCookie()方法!

依赖注入的存在是为了解决什么问题?

最近喜欢上问自己问题:某某技术的存在是为了解决什么问题?因为只有了解这个技术的产生缘由后,才会对这个技术的理解更加深刻。
那么,今天尝试着来问自己这么一个问题:依赖注入解决了什么问题?之所以会产生这个疑问呢,还是得归咎于了解了Node.js的express框架后,发现相比其他语言的框架(Spring,Laravel),缺少依赖注入这个特色。但是实际使用上,其实还是相当给力的,那么依赖注入的存在是否就无关紧要呢?
那么,首先我们来了解一下依赖注入的定义是什么?

依赖注入(Dependency
Injection),是这样一个过程:由于某客户类只依赖于服务类的一个接口,而不依赖于具体服务类,所以客户类只定义一个注入点。在程序运行过程中,客户类不直接实例化具体服务类实例,而是客户类的运行上下文环境或专门组件负责实例化服务类,然后将其注入到客户类中,保证客户类的正常运行。

嗯,是不是觉得非常深奥和玄乎?什么接口,注入,具体服务类,上下文等名词搞晕了我们大脑,这也就是为什么学习技术是一件痛苦的事情了,类似《Head first》之类的书籍简直是神器。

这么玄奥的话我们是不懂的啦,那么我们来尝试依赖注入产生的动机。

首先,没有依赖注入,我们会频繁的制造创建对象的代码,比如我们要发送邮件:

use AppBundle\Mailer;

$mailer = new Mailer('sendmail');
$mailer->send('ryan@example.com', ...);

比如这种代码,我们可能在很多地方去重复制造。
重复制造有什么问题呢?
个人觉得其实也没有什么问题,大家刚开始编程的时候不都这么写的么。。。哈哈

但是可能有人觉得重复制造不好,比如有可能在一次调用过程中会制造出多个mailer对象,其实明明创建一个就可以了是不?
那么我们在最开始的时候初始化一个对象好不好呢?
比如在每次请求过程开始的时候,初始化一个mailer对象,然后在后面就可以任意次数进行调用了。

但是也有问题,万一这个项目的代码中需要用到成百上千个这样的对象(纯属假设),那我们岂不是要在请求开始的时候创建这么多个对象了。
那么,有更好的解决办法么?
我们可以假设系统中存在一个容器,容器内部放置了这么多个对象,容器内的对象可以直接用来调用。其实容器内被调用的对象都不存在,只有在第一次被调用的时候才会被系统初始化,保存在容器内部。
但是对我们这些调用者来说,容器就相当于存在成百上千个对象等待我们去调用。

这样就大概是依赖注入被制造出来的原因了,只是关于重复制造存在的问题,我还需要思考思考该怎么表述。

给个Node.js依赖注入的例子:http://www.infoq.com/cn/articles/ioc-meet-nodejs