岭背汤,不被大众所知的银杏小村

  一说到观赏银杏,回答最多的一定是广东省南雄市,这里有密集的银杏种植,位于著名景点帽子峰,也有千年古银杏群位于坪田镇。恰好到了这个季节,于是计划着自驾南雄之旅。显然人满为患的景区是不是这次首要考虑,介于上次揭阳梅海之行得出的重要结论,美景一般都是在深山老林。

  一个偶然的机会得知坪田岭背汤这个小村庄也有不少的老银杏,并且居住在村里的人已经基本搬离了,甚至连进村路都没修好,仅有一条半山腰凿出来的泥路,却成了当地摄影发烧友的天堂。在搜索了各大导航App之后发现并没有这个叫【岭背汤】的地方,不过也没关系,到了之后当地人总该清楚。于是长途跋涉500公里入住了镇上一处民宿之后,和老板闲聊了一阵子,得知我们的目的后很大方的介绍了这个地方,还推荐了别的一些拍摄点,于是第二天的计划就顺利的加入岭背汤。

  由于路不好走,坐着他们家的摩托车就过去了。后来发现其实不下雨,车也能进去,就是比较考验技巧,一般问题也不大。大体位置是在迳洞村往冯屋方向,过了冯屋景点再往里开大概10分钟路程。其实过了景点就已经看不到人了,沿途也没有指示牌。这个小村看起来都是建筑在山腰上,错落有致,银杏数量也超过我们想象,落在地上还沾着露水,没有踩踏过的痕迹,非常之美。

  不过此次行程大部分时间都在跑长途上了,并且天气也不给力,并没有拍的尽兴。最大的收获还是在于找到这样一个地方,有机会明年再来。

  本次行程一些照片都在花图相册:https://hitu.me/albums/steven/AFp6PhEHro7hZ5gYko4ydK

初代树莓派上使用ZeroTier LAN

  话说这个初代的Pi闲置也有好些年头了,一直通着电放在网络箱,没怎么用起来。这不最近发现有一个基于P2P网络的Private LAN工具:ZeroTier。正如他所描述的:A virtual networking layer that works the same everywhere。免费版本支持100个设备,基本也够用了。

  按官方的说明配置好Windows,MacOS,iOS都没问题,但最重要的要在Pi上用却遇到了点麻烦,通过apt官方仓库的方式安装,运行时会报段错误(Segmentation fault),可能是不支持debian stretch。想着既然开源的,不如直接编译一个,在官方Github上找到了源代码,make && make install之后一段漫长的等待之后,果然可以了,先用zerotier-one -d启动主程序,再join到创建的私有网络中,zerotier-cli join your_network_id,顺利加入到Lan中。

  注册,创建网络什么的就简单了,官网的操作后台也是既简洁又专业,记得新join的设备勾上Auth,测试了几天,延时还是比较大的,但稳定性不错,强力推荐。

漫长的深户之旅

  入了深户,只是为了更好的离开深圳,一切只是一个开始。

  一晃眼,也来深工作了六年多了,计划离职休息一段时间,一个很偶然的因素决定以个人申报方式将户口迁入深圳,于是开始了长达3个月之久的等待。入户方式有三种:调干、招/调工,在满足积分的情况下依个人情况具体选择,要说现在干部身份和工人身份究竟有多大区别,可能就好听点罢了。

  网上有各种各样关于身份的识别方式,然而汇总到一点就是全日制普通大中专院校毕业生就够了。正常情况下毕业后会有个学籍档案,并附有报到证一式两份,蓝色联贴在档案袋外面,白色联放在档案内。由于毕业后一直没处理档案,联系了学校档案处老师,约了个时间过来顺利拿到尘封6年之久的学籍档案,档案袋都破了,给换了个新袋子,重新贴上封条,顺便看了一眼当年的成绩,哎~~

  大概2014年之前的学籍档案放入人才市场或事业单位一年后会有转正定级的操作,这就是那些年的干部身份获取方式。然而这么多年过去了,随着国家政策的变化,已经在全国范围逐步取消转正定级,还包括档案托管费,以及干部介绍信之类的,很巧我们那就已经没有了。作为政策的衔接,深圳这边在认定干部也不再检查转正定级,然而对外的资料都还是说要这个。

  在了解相关背景后,本着人在哪,档案就在哪,有则全力争取的原则,在去年的11月23日签下代理协议的时候选择了以调干这种困难模式开始了入户之旅,就连办事人员对我这种档案居然还拿在自己手中的,能不能通过都还不确定。第二天便回家,将档案放在我们当地的人才市场。

  后面的步骤和大家就没什么区别了,很快的公示完了之后拿到商调函寄回家办理调档。随后的人社局审核一切顺利,并未要求补充什么资料。拿到调令去公安局办理户口准迁证,寄回家办理户口迁移证,同时原户口我那一页就被收上去了,想想还真有点舍不得。准迁证加迁移证就可以办理入户了,于是新的户口页打印出来。再办理新身份证,为了原证不被剪,可以选择邮寄。到此全部搞定。

  正如开头所说,一切只是一个开始。

Spring MVC之工作流程

  一直以来都是用Spring MVC做业务开发,却很少去了解内部的一些细节,虽然网上与天盖地的源码解读,然而却无多大印象,加上版本变化之快,不妨重读一次。这里以spring-webmvc 4.3.4为例,也正是花图所使用的版本,下面详细来看看。

  DispatcherServlet继承自FrameworkServlet,而FrameworkServlet又继承自HttpServletBean并实现了ApplicationContextAware,通过这样的一个分层结构,可以更清晰的知道处理流程。

  第一部分:初始化

  初始化分两个部分:一个是监听器部分:负责Root WebApplicationContext的初始化,包含通过XmlBeanDefinitionReader获取配置文件,进行加载,通过RequestMappingHandlerMapping扫描出带有RequestMapping注解的Controller,通过RequestMappingHandlerAdapter注册Controller,等等。

  另一部分是FrameworkServlet的初始化:抽象类HttpServletBean继承自HttpServlet,实现了父类的init()方法,获取init-param中的配置,对DispatcherServlet进行数据绑定。然后调用FrameworkServlet.initServletBean(),初始化webApplicationContext,并调用DispatcherServlet.onRefresh(),来完成初始化。

initMultipartResolver(context);
initLocaleResolver(context);
initThemeResolver(context);
initHandlerMappings(context);
initHandlerAdapters(context);
initHandlerExceptionResolvers(context);
initRequestToViewNameTranslator(context);
initViewResolvers(context);
initFlashMapManager(context);

  从Bean中取出相应的Resolver,若没配置则取默认,默认的设置在DispatcherServlet.properties。

  第二部分:接收请求

  对于Java Web而言,都是通过web.xml中的Servlet来分配请求,一般的都会将”/”根请求配置为DispatcherServlet,这样所有的前端请求都会路由到Spring MVC。

  抽象类FrameworkServlet对Servlet的几个基本Http method方法进行了代理,统一通过processRequest()进行处理,并最终到达DispatcherServlet中的doDispatch()。

  doDispatch()中先检查request是否是multipart request,如果是,则用一个multipartResolver来包装request,判断依据是contentType是否是”multipart/”开头。

  找到HandlerExecutionChain用来处理当前的请求,方法是从已注册的mappingRegistry中找到最匹配请求URL路径的handlerMethod,这个即我们最熟悉的Controller,放在HandlerExecutionChain中。若HandlerExecutionChain为空,则没有匹配到任何处理流程,发送404响应,并报非常熟悉的一个日志:”No mapping found for HTTP request with URI XXX”。

  找到HandlerAdapter用来处理请求,从已加载的handlerAdapters中遍历出一个支持该Handler的HandlerAdapter,本例中的Handler即Controller。

  检查Http method是否为GET或者HEAD,如果是,进行last-modified验证,符合条件的发送304响应,并更新Last-Modified相关参数值。

  检查拦截器配置,遍历执行applyPreHandle(),并触发triggerAfterCompletion(),若有返回false的,则本次请求结束。

  一路顺利到此可以调用Controller中的方法了。

  对于Controller返回时ModelAndView没设置view的,给一个默认view。

  接着倒着遍历执行过滤器applyPostHandle(),执行完一个完整的拦截器链。

  接下来是进行ModelAndView的渲染,将ModelMap转化到request.setAttribute()中,并RequestDispatcher.include() or forward()到JSP中。

  最终完成本次请求。

在MacOS中使用AB测试工具

  一直以来都是用JMeter来做压力测试,GUI界面功能虽然强大,报表齐全,但有时候只是想简单测试下,启动JMeter过于繁琐,于是想到用ab来测试,一条命令搞定。MacOS自带了ab,却因版本问题无法正常使用,需要升级到最新版,本文简单记录下过程。

1,先下载httpd、apr、apr-util、pcre,若有已安装的可以忽略
http://httpd.apache.org/download.cgi
http://apr.apache.org/download.cgi
https://ftp.pcre.org/pub/pcre/

2,由于httpd依赖apr、pcre,所以先安装apr、apr-util、pcre

$ cd apr-1.5.2/
$ ./configure
$ make
$ make test
$ sudo make install

$ cd apr-util-1.5.4/
$ ./configure --with-apr=../apr-1.5.2/
$ make
$ sudo make install

$ cd pcre-8.40/
$ ./configure
$ make
$ sudo make install

$ cd ../httpd-2.4.25/
$ make
$ sudo make install

3,在恢复模式下替换系统ab,关闭MacOS Rootless,开机按住Cmd+R键,进入恢复模式,打开终端执行:

$ csrutil disable
Successfully disabled System Integrity Protection. Please restart the machine for the changes to take effect.

重启
$ reboot

4,备份并替换,以下路径是httpd默认安装位置

$ cd /usr/local/apache2/bin/
$ sudo mv /usr/sbin/ab /usr/sbin/ab.bak
$ sudo cp ab /usr/sbin/

5,重新进入恢复模式,开启Rootless

$ csrutil enable
Successfully enabled System Integrity Protection. Please restart the machine for the changes to take effect.

重启
$ reboot

  到此,工具算是准备好了,但MacOS对文件打开有限制,无法满足ab需求,通过以下命令临时调整:(重启后需重新执行)

$ sysctl kern.maxfiles
kern.maxfiles: 12288

$ sysctl kern.maxfilesperproc
kern.maxfilesperproc: 10240

$ sudo sysctl -w kern.maxfiles=1048600
kern.maxfiles: 12288 -> 1048600

$ sudo sysctl -w kern.maxfilesperproc=1048576
kern.maxfilesperproc: 10240 -> 1048576

$ ulimit -n
256

$ ulimit -n 1048576

$ ulimit -n
1048576

  搞定!