说到java语言的数据类型，我们都知道包括基本数据类型和对象类型，而且java是一门面向对象的语言，对象类型可以理解，基本数据类型会使得java的面向对象不是那么纯粹，那么为什么java还要保留基本数据类型呢？
先看基本类型和对象类型的一些区别：

区别

基本类型是基于值，对象类型是基于引用

1
2
3

int i1 = 100;
Integer i2 = new Integer(100);
Integer i3 = 100;

第一句是使用基本类型int，第二句使用int的包装类Integer，第三句使用了jdk5自动装箱的特性（简化了包装类的使用，减少编码量，但是底层的语义没有改变，对运行时也没有任何影响）。
i1直接持有一个整数的值，但是i2持有的是一个Integer对象的引用！
说到自动装箱有一点需要注意：

1
2

Integer i1 = null;
int i2 = i1;

基于自动装箱的特性，上面的代码并不会有编译错误，但是运行的时候你会发现会抛出NullPointerException，因为i1指向的是null，在自动拆箱的时候就会出现错误。

前言

折腾hexo有几天时间了，配合NexT主题，大爱！虽然我写博客主要是用来记录自己的一些知识积累，并不强求有多少人来看，hexo本身已经很优秀了，但有些地方对于强迫症来说还是忍不住想要定制和优化，这样才能让自己更爽~~而且折腾的过程中，也可以学到不少新的知识。

静态资源优化

主要是压缩html,css,js等等静态资源，可以适当减少请求的数据量，主要用到gulp和一些相关的插件来实现，直接列出我的dependencies.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

"dependencies": {
  "gulp": "^3.9.1",
  "gulp-htmlclean": "^2.7.6",
  "gulp-htmlmin": "^1.3.0",
  "gulp-imagemin": "^2.4.0",
  "gulp-minify-css": "^1.2.4",
  "gulp-uglify": "^1.5.3",
  "hexo": "^3.2.0",
  "hexo-deployer-git": "^0.1.0",
  "hexo-generator-archive": "^0.1.4",
  "hexo-generator-category": "^0.1.3",
  "hexo-generator-index": "^0.2.0",
  "hexo-generator-tag": "^0.2.0",
  "hexo-generator-sitemap": "^1.1.2",
  "hexo-generator-baidu-sitemap": "^0.1.2",
  "hexo-renderer-ejs": "^0.2.0",
  "hexo-renderer-marked": "^0.2.10",
  "hexo-renderer-stylus": "^0.3.1",
  "hexo-server": "^0.2.0"
}

其中gulp相关的就是用来压缩静态资源用的，接着还要安装gulp工具：

今晚折腾hexo的时候遇到很恶心的hexo报错，执行任何hexo命令都会报如下错误。

hexo报错

1
2
3

{ [Error: Cannot find module './build/Release/DTraceProviderBindings'] code: 'MODULE_NOT_FOUND' }
{ [Error: Cannot find module './build/default/DTraceProviderBindings'] code: 'MODULE_NOT_FOUND' }
{ [Error: Cannot find module './build/Debug/DTraceProviderBindings'] code: 'MODULE_NOT_FOUND' }

解决办法on google

google之后发现被这个问题困扰的小伙伴还真不少，网上最靠谱的解决办法是：

1

$ npm install hexo --no-optional

有时候遇到网站或者api访问速度慢，排除了服务器以及程序性能问题后，很可能是网络导致的慢速。我们可以通过linux中的curl命令来测试url的各项耗时。

1

curl -o /dev/null -s -w %{time_connect}:%{time_starttransfer}:%{time_total}:%{time_namelookup}:%{speed_download} http://url.com/api

time_connect:建立到服务器的TCP连接所用的时间
time_starttransfer:在发出请求后，web服务器返回数据的第一个字节所用的时间
time_total:完成请求所用的时间
time_namelookup:DNS解析时间，从请求开始到DNS解析完毕所用时间（记得关掉Linux的nscd的服务测试）
speed_download:下载速度，单位字节每秒

另外可以配合

time wget http://url.com/api

进一步测试。

应用服务器上多个webapp都使用了 ImageMagick来处理图片。
运行是发生如下异常：

1
2
3
4

java.lang.UnsatisfiedLinkError: Native Library /usr/lib/libJMagick.so already loaded in another classloader
     java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1772)
     java.lang.ClassLoader.loadLibrary(ClassLoader.java:1732)
     java.lang.Runtime.loadLibrary0(Runtime.java:823)

ps：ImageMagick是以JNI本地库的形式调用。

redis是一款开源的内存数据存储系统，可以用作数据库、缓存甚至是消息中间件（pub/sub）来使用。与memcache相比，redis支持更多的数据结构，比如string,hash,list,set,bit map,sorted set甚至是geo等等，基本覆盖了日常开发中使用到的数据结构。而且redis十分高效，当然是建立在合理使用的前提下。由于redis单线程的设计特性，任何一条阻塞的命令都会引起redis整个实例的阻塞，所以在使用过程中，需要尽量避免过多使用时间复杂度高的命令（特别是高并发的环境下），一般我们可以通过查看redis command的时间复杂度，但实际使用情况中还是会遇到不少坑，本文主要记录工作中遇到的redis问题，持续更新~~~

都说玩博客的都要经历三个阶段：

1.QQ空间、CSDN、iteye等等博客网站上写；

2.觉得都在第三方网站上写不爽，得自己折腾，于是自购服务器空间域名，搭建wordpress博客；

3.慢慢发现wordpress上写博客各种不爽，发现了jekyll、hexo之类高大上的开源博客系统，结合github pages+markdown，原来这才是真爱！

这里记录的是之前折腾wordpress时遇到的xmlrpc攻击问题。

最近刚刚搞好博客的备案，准备开始倒腾自己的网站了，结果今天一上来发现502 Bad Gateway！

在我们做产品的时候，选择第三方帐号登录的设计，对于用户而言的确是很方便，可以省去用户注册的流程，用户也不用费心去记多一个帐号和密码，可以用QQ、微博等帐号玩遍天下，而且使用第三方帐号系统可以更好的与第三方系统集成，更方便的与好友分享和互动。

OAuth优点

OAuth不会使第三方应用或者网站接触到用户的敏感数据（用户名密码等），而是通过授权后的access_token来实现用户数据交互，在http中传输的不再是用户的敏感数据而是access_token，所以即使数据包被拦截，也难以拿到用户敏感数据。这是OAuth最大的优点。

OAuth授权的安全隐患

在最近的项目中，我们使用到了微博、qq、微信等第三方帐号登录功能，在接入这些第三方帐号的时候，发现一些值得思考的问题。以新浪微博的OAuth为例，在网页中接入微博登录主要使用weibo的jssdk，分析jssdk的源码我们发现，在用户通过OAuth授权登录后，jssdk将授权后weibo返回的access_token是存入cookie的。

说到restful api的安全性，大家可能很快就想到OAuth2.0，的确，OAuth2.0是目前最主流和最安全的授权机制设计。但使用它的成本对于中小型应用来说还是比较高的。那么在不使用OAuth2.0的情况下如何设计restful api的安全性呢？

业内还真有不使用OAuth2.0来做api鉴权的大公司——大名鼎鼎的Amazon web service。且看amazon是如何来做的，查阅amazon相关的文档我们大概知道其中设计的原理：为client生成public key和private key对，其中public key当然任何人都可以知道，或者可以叫做appid，用于server来区分是哪个client的；private key（或者可以叫做app secret）则只能是server和client知道，不可泄漏给第三方的任何人；client在做request的时候，将request的参数和取值整合成一个string，然后对这个string使用private key计算签名值（HMAC-SHA1或者SHA256之类），然后将这个签名值连同请求参数一起发送给server，server收到request之后按照同样的逻辑整合string，用同样的算法计算签名值，最后比较server生成的签名和client生成的签名是否相同，相同则client可信，继续执行业务逻辑，不相同则拒绝访问。

amazon的第一版方案是这么做的：

1.Split the query string based on ‘&’ and ‘=’ characters into a series of key-value pairs.

2.Sort the pairs based on the keys.

3.Append the keys and values together, in order, to construct one big string (key1 + value1 + key2 + value2 + … ).

4.Sign that string using HMAC-SHA1 and your secret access key.

差不多一个多月没写博客了，不过也没闲着，完成了 几件大事 ：结婚、户口、驾照、买车。感觉写代码更有劲了~哈哈…

回到今天的主题，最近项目上有一个拍照的需求，对于客户端当然是个小问题，但是产品需要在网页版的页面上同样要实现跟客户端一样的体验！让用户可以在网页上拍照或者选取本地照片上传到服务器。

看到这个需求有点蒙，首先还不确定网页如何调用系统相机，选本地照片的话弄个<input type="file">应该就ok，其次手机拍一张照片都是几兆几兆的，如果不压缩一下图片，在这蛋疼的网络环境下，基本是没办法传到服务器的，网页上的环境也就那样，怎么做图片压缩呢？

网页拍摄照片&选取本地照片

这个看起来很麻烦，其实很简单，网页上可以调用系统原生的照片拍摄和选取操作。直接上代码：

1

<input type="file" id="photo" accept="image/*" capture="camera">

其中，accept和capture是HTML5的API，这样在网页上点击这个input之后会弹出拍摄和选取本地照片的窗口，和native app一样。

照片读取、压缩

上面说到，如果不对照片进行处理的话，一张照片就是好几兆，在2g网络下基本不可能成功上传到服务器，所以肯定需要对照片进行压缩了。我们可以使用HTML5的File API配合Canvas绘图实现照片的压缩，代码：