Sogou路书绘制骑车上班路线
今天试用了一下sogou的路书功能,还是挺好用的
直接输入起点,终点,它就能自己绘制出骑行路线
然后,自己可以拖动鼠标去修正路线
或者如果有gpx轨迹文件,直接上传就行了
以下是我骑车上班的路线图,总距离大概11.6KM,耗时45分钟
今天试用了一下sogou的路书功能,还是挺好用的
直接输入起点,终点,它就能自己绘制出骑行路线
然后,自己可以拖动鼠标去修正路线
或者如果有gpx轨迹文件,直接上传就行了
以下是我骑车上班的路线图,总距离大概11.6KM,耗时45分钟
今天,在部署U盘程序时,重启resin时,报错
此时,无论直接运行java或用ant编译,都报以上错误
把所有的java进程都kill掉后,可以正常重启2个jvm,在启动第3个时,同样的错误又出现了
尝试更换成jdk5的其它版本,错误依旧
于是,决定用jdk6试试,如果不行,准备只好重启机器了...
没想到,在安装jdk6时,失败了,先提示/tmp空间不足,然后又报段错误
这时,才突然明白,可能是/tmp空间满了,导致无法运行java
把/tmp空间清理后,用以前的jdk可正常启动resin了
那么,启动java进程时,会向/tmp目录下写什么东西呢?
进去后,会发现有一个/tmp/hsperfdata_root目录
该目录下有一些文件,这些文件就是对应java进程的pid
而文件的内容似乎是启动java的命令,还有其它的一些log信息
看来java是利用该文件来记录启动时的一些log了
郁闷的问题,下午折腾了好久......
曾听人这么评价过淘宝
“淘宝上的东西,90%以上都是假货...”
正因为如此,我每次在淘宝上买东西
一般都照信用比较高,评价好的店主
前端时间,在上面买了一个Kingston的8G U盘
看到很多好的评价,于是就出手了
拿到U盘后,用软件测试了一下,就发现是假的
是通过扩容扩成8G的,而且拷贝文件速度很慢
写入速度每秒不足3M....
当时本是想退货的,不过想想挺麻烦的,就懒得理它了
昨天,找了对应芯片的量产工具处理了一下
发现,实际容量是4G,还有13%的坏块
最后的可用容量大概是3.4G,而且量产后,速度也没有任何的提升
那个店主总算不太黑,曾看到网上有人买的U盘
是从16M直接给扩容到了4G,这个可真够狠的了...
看来,在淘宝上买东西,也不能只看它的那些评价和信用...
reset命令有3种方式:
以下是一些reset的示例:
如果我们某次修改了某些内容,并且已经commit到本地仓库,而且已经push到远程仓库了
这种情况下,我们想把本地和远程仓库都回退到某个版本,该怎么做呢?
前面讲到的git reset只是在本地仓库中回退版本,而远程仓库的版本不会变化
这样,即时本地reset了,但如果再git pull,那么,远程仓库的内容又会和本地之前版本的内容进行merge
这并不是我们想要的东西,这时可以有2种办法来解决这个问题:
在删除远程master分支时,可能会有问题,见下:
这时需要在远程仓库目录下,设置git的receive.denyDeleteCurrent参数
然后,就可以删除远程的master分支了
虽然说有以上2种方法可以回退远程分支的版本,但这2种方式,都挺危险的,需要谨慎操作......
昨天,送快递的给我打电话说到楼下了,让下去取
于是,我就开始换衣服准备下去
昕昕看见了,非要跟这一块下去
为了省事,奶奶就给他穿着凉鞋
衣服也没换,就穿着一个小兜兜(他在家里就穿这个)
拉着他刚下到4层,这小子突然停住了
用手摸着他的兜兜,叫道:
完了,忘了换衣服了!
然后,就开始转身,往回走,说:
我要回去换衣服了
我对他说:算了,别回去换了,就一个送快递的,没有别的人
于是,他就继续跟着我下楼
到一层快下台阶时,当看到那个送快递的时候
他死活也不走了,怎么拉都不下楼
无奈,只好让他站在那,我去签收了
这小子,穿着兜兜还知道害羞...
Nginx和Apache中对于反向代理的请求,它们都有默认的timeout的
对于正常的请求来说,没有什么问题
但如果我们是请求一个长连接,那么就需要去修改它们的默认超时了
否则,长连接还没有返回结果时,前端Nginx或Apache就已经proxy timeout了
Firefox和Safari浏览器中,XMLHTTPRequest支持interactive readyState的状态
其对应的readyState状态为3,当Client接收到Server端的一部分数据后就可以触发该状态
当Request请求完成后同样还会触发Success的状态
于是,可以利用这个特性来实现Streaming模式的Comet
Client端测试代码如下:
Server端代码如下:
注意:
要实现一个基于Streaming模式的comet,比较通用的办法就是使用Iframe来实现
但iframe有一个比较大的问题,浏览器中的进度条会一直停留在某个地方,显示正在加载
Google的工程师们,包装了一个js对象,在IE下使用htmlfile,Firefox下嵌套Iframe解决了这个问题
测试代码如下,Client端页面代码:
Server端jsp代码:
以上代码,在Tomcat里测试正常,可以看到页面内容在不断变化,但如果用nginx反向代理后,页面就不能实时变化,而是最后load完了才变化
查了好久原因,才发现,nginx的proxy默认会Buffer后端Server的响应内容,导致Client端不能实时更新,解决很简单,把buffer给关闭就可以了:
但在Resin里面,上述代码仍旧没有测试通过,页面无法实时更新,暂时还没有找到原因
但Resin自己也提供了一套comet的解决方案,参见这里
Web开发中,Comet通常是指在Client和Server端维持一个长连接
当有新消息到达时,Server端可以实时把消息push到Client端
实际上,要实现“服务器推送”,不一定非要用基于http的comet来做
还可以基于socket来实现,比如:flash、applet、html5等
可以参考IBM的“Comet:基于 HTTP 长连接的“服务器推”技术”
就Comet的实现来说,可以有两种方式:
1. Streaming流模式:这种方式,实际上才是真正的长连接,Client和Server端一直维持该连接
当Server端有数据时,立即把数据返回给Client,Client马上去解释处理该数据
然后该连接继续保持,等待后续的数据....
2. Long Polling长轮询模式:当Server端没有数据时,该连接一直保持着,当返回给Client端后,Server端就断掉该连接
同时,Client端再发起一个新的长连接,依次循环...
从具体的技术实现上,comet可以有以下方式:
1. Iframe,可适用于Streaming和Long Pooling这2种模式,返回的数据格式使用Chunked来进行传输,使用它最大的缺点是,浏览器上可能会有进度条或不停Loading,不过,总还是有解决办法 的,见这里
2. Ajax, 可以适用于任何浏览器的Long Pooling模式。对于Streaming模式,在Firefox和Safari下可以使用,参见这里
3. Jsonp, 只适用于Long Pooling模式,它的好处是可以跨域,但同样会有浏览器不断Loading的问题