Nginx反向代理并发能力的强弱，直接影响到系统的稳定性。安装Nginx过程，默认配置并不涉及到过多的并发参数，作为产品运行，不得不考虑这些因素。Nginx作为产品运行，官方建议部署到Linux64位系统，基于该建议，本文中从系统线之上考虑Nginx的并发优化。

    1、打开Linux系统epoll支持

         epoll支持，能够大大提高系统网络IO的并发数。

     2、Linux文件句柄数限制

         Nginx代理过程，将业务服务器请求数据缓存到本地文件，再将文件数据转发给请求客户端。高并发的客户端请求，必然要求服务器文件句柄的并发打开限制。

         使用ulimit命令，查看linux系统文件句柄并发限制。

         $ ulimit -n

          1024

     linux系统默认设为1024，我们需要将该值设为65535。

         修改系统文件/etc/security/limits.conf，添加如下信息，并重新启动系统生效。

         *               soft    nofile            65535
         *               hard    nofile            65535

        $ sudo vi /etc/security/limits.conf

      3、Nginx配置文件中，添加文件限制及连接数信息

    worker_rlimit_nofile 65535;
    events {
        use epoll;
        worker_connections  65535;
    }

    Nginx并发数受限，通常引起502错误，完成上述操作，通常情况都能解决。

内存泄漏：

程序申请了堆空间，但是“忘记”释放，导致该块区域在程序结束前无法被再次使用导致的。泄漏时间长了，就会导致用户空间内存不足，严重的导致死机。

如果泄漏比较严重，很容易察觉；但是有些泄漏很缓慢，不容易察觉，但是软件会运行很长时间后，会慢慢导致严重问题，而且当发现症状的时候，基本上已经是比较晚的时候了，想要识别泄漏，还是可以实现的，本篇文章来聊聊内存操作的原理。

C++中申请内存使用的是new，C语言中使用的malloc（还有其他比如alloc原理类似），一般情况下new调用的是C语言使用的malloc。而由于C++/C可以在多个操作系统使用，所以可以想到malloc肯定是封装了不同操作系统提供的API，比如Windows上边调用的有这几个：VirtualAlloc、VirtualAllocEx、VirtualFree、VirtualProtect、VirtualQuery、VirtualLock、VirtualUnLock，不过它们分配的都是内存页的整数倍的虚拟内存空间RAM，然而我们想要使用内存的时候，几乎很少需要整数倍，那么就需要封装它们改变灵活一些，API替我们封装了：HeapAlloc、GlobalAlloc，它们全都是内核级别，存在于kernel32.dll里边。

很容易看出，我们调用new，实际调用的是HeapAlloc，不过不需要在检测内存泄漏的时候走到这么底层，回归正传，还是回到new/malloc。

在申请内存的时候new调用malloc，释放delete调用free，那么怎么能够让每一次申请和每一次释放都能够记录，最终找到可能的哪怕1字节的泄漏呢？容易想到，在new调用malloc的时候，记录下申请空间的地址，在delete调用free的时候，将记录里边对应地址的数据删除，这样最后如果记录中还有剩余记录，则表示有泄漏。这样还不够，即使知道泄漏，可是不知道在哪有有什么用呢？显然在记录的时候，除了记录地址，还应记录申请的文件名字、行数，这样最后有泄漏的时候，可以立刻知道在哪里泄漏，原理就是这些，看下例子、解决的基础代码。

#include

#include

using namespace std;

#include




void* operator new(size_t size, const char* file, int line)

{

void *p = (void*)malloc(size);

printf("【%d】%s : (%d) 申请%d字节内存\n", p,file,line,size);

return p;

}

void* operator new[](size_t size, const char* file, int line)

{

return operator new(size, file, line);

}

#define new DEBUG_NEW

#define DEBUG_NEW new(__FILE__, __LINE__)


void operator delete(void* pointer)

{

printf("【%d】释放内存\n",pointer);

free(pointer);

}


void operator delete[](void* pointer)

{

operator delete(pointer);

}


void operator delete(void* pointer, const char* file, int line)

{

operator delete(pointer);

}


void operator delete[](void* pointer, const char* file, int line)

{

operator delete(pointer, file, line);

}



int main()

{

int *pos1 = new int[10];

int *pos2 = new int(0x70000001);

delete []pos1;

delete pos2;;

return 0;

}

容易发现申请和释放是成对的，释放内存地方本来也可以知道释放的大小的，不过有点忘记具体保存的方式了，C++编译器一般都会在new返回的只针的前边几字节记录申请的长度等信息，可以在上边代码这么修改：

就会出现崩溃，因为将编译器的数据修改了，它无法正常释放内存了。

有个比较不错的开源内存泄漏检测项目：Visual Leak Detector，用它非常方便，仅仅需要将它的头文件、静态链接库添加到我们的项目中即可，用上边的例子做例子：

而当去掉一个delete 的时候，是这样的：

直接找到泄漏大小、地点。

Visual Leak Detector下载地址：

http://www.codeproject.com/script/articles/download.aspx?file=/KB/applications/visualleakdetector/vld-10.zip&rp=http://www.codeproject.com/Articles/9815/Visual-Leak-Detector-Enhanced-Memory-Leak-Detectio

参考：

http://www.ibm.com/developerworks/cn/linux/l-mleak2/

http://blog.csdn.net/yapingxin/article/details/6751940

http://bbs.csdn.net/topics/20329607

http://blog.csdn.net/g5dsk/article/details/6077601

http://babybandf.blog.163.com/blog/static/6199353201128101029894/

http://www.codeproject.com/KB/applications/visualleakdetector/vld-10.zip

http://blog.csdn.net/sunmenggmail/article/details/8316734

• —软件人才免语言低担保 赴美带薪读研！—

9 月 3 日，一个名为 Remind 的移动应用最近迅速成为苹果和谷歌应用商店中最流行的应用之一，并有可能引发一场教育革命。

Remind 不是游戏，也不是社交网络，而是一个适用于学校师生及学生家长的通讯应用。已经有约 100 万名教师和 1700 万家长及学生下载了 Remind。在美国的许多地方，Remind 被教师、学生和家长用来建立强大的通讯网络。

Remind 公司是美国旧金山的一个创业企业。该公司表示，在得克萨斯州、阿拉巴马州和佐治亚州等地区，40％ 到 50％ 的教师正在使用这个免费应用。教育工作者可以使用 Remind 来布置家庭作业、为校外参观考察征求志愿者，也可以使用 Remind 在教室里发送照片。有了 Remind，教师可以减少对纸质材料的依靠，学生家长也可以不必频繁查收来自学校的电子邮件。

Remind 还在 8 月 28 日推出了一种新功能，教师可以用它来发布短小的调查问卷（例如：“今天的功课太难了吗？”），并录制语音消息。“如果我们能找到一种方法，让学生家长每周两三次（而不是每年一两次）参与学校的教学工作，如果我们可以提高教师的工作效率，那么我们就可以产生巨大的影响。”Remind 公司年仅 27 岁的首席执行官布雷特·科普夫（Brett Kopf）说。

Remind 公司成立于 2009 年，当时科普夫刚刚在美国密歇根州立大学（Michigan State University）获得农业经济学的学士学位。最初几年，Remind 是不成功的。科普夫从小患有失读症（dyslexia），还有其他学习障碍。他设计 Remind 的初衷是帮助具有类似学习障碍的学生。学生如果在 Remind 中上传了自己的作业清单，它会提醒他们在最后期限内完成测验和其他作业。

最初几年，下载 Remind 的学生很少。科普夫和另一位公司创始人——他的哥哥大卫（David）——很快欠下了 1 万美元的债务。

2011 年，Remind 公司搬到了旧金山湾区（Bay Area），并加入了教育创业公司孵化器 Imagine K12。他们决定更专注于通信服务，并在 200 名教师中进行了需求调查。这些教师一致表示，他们需要让家长更多参与教学。

现在，Remind 获得了大多数硅谷初创企业梦寐以求的投资者。First Round Capital、 Kleiner Perkins Caufield & Byers（KPCB）和 Social+Capital Partnership 等风险投资公司已经对 Remind 投资了 2000 万美元。KPCB 公司的约翰·杜尔（John Doerr）现在是 Remind 董事会成员。约翰表示，教育技术创业具有很大的挑战性，Remind 的成功证明了智能手机定制服务的价值。“几十年来，我们努力开发实用的教育技术，”约翰说，“虽然 Remind 不太引人关注，但它已经走进了课堂。”

如何保护学生的隐私和安全，这是 Remind 和它的竞争对手面临的最大挑战。Remind 隐藏了用户的电话号码，家长在与教师联系时只需要输入一个特定的教室代码。为了保护学生，Remind 只允许老师向全体学生而非单个学生发送消息，而且会保存每一条信息。科普夫说，他不打算出售基于用户数据的广告，而希望开发收费的附加服务（移动支付功能），以此来实现盈利。

美国路易斯安那州杰一位名叫杰西卡·迪翁的老师表示，她的许多学生来自贫困家庭，家里没有可靠的互联网，但他们都有手机。杰卡西使用 Remind 来与家长进行各种提醒和沟通。她说，Remind 使更多的学生按时完成家庭作业。“它改变了我的课堂和学生。我认为 Remind 让我成了一个更好的老师。”她说。

本文链接

• —软件人才免语言低担保 赴美带薪读研！—

• —软件人才免语言低担保 赴美带薪读研！—

基于Item的时序协同过滤算法技术方案包括两个步骤：

（1）提取用户商品点击日志、搜索点击日志和商品基本信息等基本数据。然后，去除噪音数据（譬如每天点击商品数达到数以万计的用户）和缺失值数据，构建时序点击流数据，即记录用户每天按照点击时间先后顺序排序的商品行为数据。从而得到如下数据结构：<用户id，商品id，点击时间，点击日期>；

（2）时序协同过滤算法构建模块，根据数据预处理阶段的得到的商品点击时序数据集，在ODPS平台上实现该算法算法，计算商品之间的相关性。

时序协同过滤算法

步骤1：计算商品之间相关性

Map阶段

输入：key（行记录标识）， value（用户id，商品id，点击时间，点击日期）

输出：key（用户id，点击日期，点击时间）， value（商品id，点击时间）

Reduce阶段：

输入：key（用户id，点击日期，点击时间）， value（商品id，点击时间）

输出：ODPS Record(点击日期，商品1， 商品2， 相关性分数)

计算相关性分数算法：

1. 计算每个用户每天的点击时间序列对，按照升序排列，即<商品1，点击时间1>,<商品2，点击时间2>,…,<商品n，点击时间n>；
2. 在每个用户的商品点击序列中，如果两两商品时间序列对的点击时间差小于等于两个小时，则表示这两个商品具备相关性；计算出有效时序商品序列<商品1，商品2，商品3，…，商品n>；
3. 计算商品之间的相关性,公式如下:   
   
   ，其中score表示相关性分值，delta表示任意两个商品之间的时间排序位置之差

步骤2：计算每天商品之间相关性均值，减少噪声数据，譬如用户无意图的商品点击序列

Map阶段

输入：key（行记录标识）， value（点击日期，商品1， 商品2， 相关性分数）

输出：key（点击日期，商品1， 商品2）， value（相关性分数）

Reduce阶段

输入：key（点击日期，商品1， 商品2）， value（相关性分数）

输出：ODPS Record(商品1， 商品2， 相关性分数均值)

步骤3：计算每月商品之间的相关性，减少噪声数据，去除异常的相关性数据

Map阶段

输入：key（行记录标识）， value（商品1， 商品2， 相关性分数）

输出：key（商品1， 商品2）， value（相关性分数）

Reduce阶段

输入：key（商品1， 商品2）， value（相关性分数）

输出：ODPS Record(商品1， 商品2， 相关性分数均值)

参考：

http://blog.sina.com.cn/s/blog_61c463090102uwqu.html

http://www.aliyun.com/ odps 

Node.js连接数据库前，需要安装相应的包，如果安装sql server 需要先装包node-sqlserver。我们以mysql为案例来说明node.js查询mysql数据。

1、安装 node-mysql

npm install node-mysql

2、通过express框架实现数据库连接

var express = require('express');
var mysql = require('mysql');
var app = express();
app.use(function(req, res, next){
  console.log('%s %s', req.method, req.url);
  next();
});
var conn = mysql.createConnection({
    host:'localhost',
    user:'root',
    database:'ceshi',
    password:'123456',
    port:3306
});
conn.connect();
app.get('/', function(req, res){
   conn.query('SELECT * from ceshibiao', function(err, rows, fields) {
        if(err) throw err;
        var data = '';
        foreach(rows,function(key,value){
            data += '<p>' + 'contents：' + value.contents + '</p>';
            data += '<hr />';
        }
        res.send(data);
    });
});
app.listen(81);
console.log('Listening on port 81');

在Android2.3 gingerbread系统中，google提供了11种传感器供应用层使用。 

我们依次看看这十一种传感器

1 加速度传感器

加速度传感器又叫G-sensor，返回x、y、z三轴的加速度数值。

该数值包含地心引力的影响，单位是m/s^2。

将手机平放在桌面上，x轴默认为0，y轴默认0，z轴默认9.81。

将手机朝下放在桌面上，z轴为-9.81。

将手机向左倾斜，x轴为正值。

将手机向右倾斜，x轴为负值。

将手机向上倾斜，y轴为负值。

将手机向下倾斜，y轴为正值。

加速度传感器可能是最为成熟的一种mems产品，市场上的加速度传感器种类很多。

手机中常用的加速度传感器有BOSCH（博世）的BMA系列，AMK的897X系列，ST的LIS3X系列等。

这些传感器一般提供±2G至±16G的加速度测量范围，采用I2C或SPI接口和MCU相连，数据精度小于16bit。

2 磁力传感器

磁力传感器简称为M-sensor，返回x、y、z三轴的环境磁场数据。

该数值的单位是微特斯拉（micro-Tesla），用uT表示。

单位也可以是高斯（Gauss），1Tesla=10000Gauss。

硬件上一般没有独立的磁力传感器，磁力数据由电子罗盘传感器提供（E-compass）。

电子罗盘传感器同时提供下文的方向传感器数据。

3 方向传感器

方向传感器简称为O-sensor，返回三轴的角度数据，方向数据的单位是角度。

为了得到精确的角度数据，E-compass需要获取G-sensor的数据，

经过计算生产O-sensor数据，否则只能获取水平方向的角度。

方向传感器提供三个数据，分别为azimuth、pitch和roll。

azimuth：方位，返回水平时磁北极和Y轴的夹角，范围为0°至360°。

0°=北，90°=东，180°=南，270°=西。

pitch：x轴和水平面的夹角，范围为-180°至180°。

当z轴向y轴转动时，角度为正值。

roll：y轴和水平面的夹角，由于历史原因，范围为-90°至90°。

当x轴向z轴移动时，角度为正值。

电子罗盘在获取正确的数据前需要进行校准，通常可用8字校准法。

8字校准法要求用户使用需要校准的设备在空中做8字晃动，

原则上尽量多的让设备法线方向指向空间的所有8个象限。

手机中使用的电子罗盘芯片有AKM公司的897X系列，ST公司的LSM系列以及雅马哈公司等等。

由于需要读取G-sensor数据并计算出M-sensor和O-sensor数据，

因此厂商一般会提供一个后台daemon来完成工作，电子罗盘算法一般是公司私有产权。

4 陀螺仪传感器

陀螺仪传感器叫做Gyro-sensor，返回x、y、z三轴的角加速度数据。

角加速度的单位是radians/second。

根据Nexus S手机实测：

水平逆时针旋转，Z轴为正。

水平逆时针旋转，z轴为负。

向左旋转，y轴为负。

向右旋转，y轴为正。

向上旋转，x轴为负。

向下旋转，x轴为正。

ST的L3G系列的陀螺仪传感器比较流行，iphone4和google的nexus s中使用该种传感器。

5 光线感应传感器

光线感应传感器检测实时的光线强度，光强单位是lux，其物理意义是照射到单位面积上的光通量。

光线感应传感器主要用于Android系统的LCD自动亮度功能。

可以根据采样到的光强数值实时调整LCD的亮度。

6 压力传感器

压力传感器返回当前的压强，单位是百帕斯卡hectopascal（hPa）。

7 温度传感器

温度传感器返回当前的温度。

8 接近传感器

接近传感器检测物体与手机的距离，单位是厘米。

一些接近传感器只能返回远和近两个状态，

因此，接近传感器将最大距离返回远状态，小于最大距离返回近状态。

接近传感器可用于接听电话时自动关闭LCD屏幕以节省电量。

一些芯片集成了接近传感器和光线传感器两者功能。

下面三个传感器是Android2新提出的传感器类型，目前还不太清楚有哪些应用程序使用。

9 重力传感器

重力传感器简称GV-sensor，输出重力数据。

在地球上，重力数值为9.8，单位是m/s^2。

坐标系统与加速度传感器相同。

当设备复位时，重力传感器的输出与加速度传感器相同。

10 线性加速度传感器

线性加速度传感器简称LA-sensor。

线性加速度传感器是加速度传感器减去重力影响获取的数据。

单位是m/s^2，坐标系统与加速度传感器相同。

加速度传感器、重力传感器和线性加速度传感器的计算公式如下：

加速度 = 重力 + 线性加速度

11 旋转矢量传感器

旋转矢量传感器简称RV-sensor。

旋转矢量代表设备的方向，是一个将坐标轴和角度混合计算得到的数据。

RV-sensor输出三个数据：

x*sin(theta/2)

y*sin(theta/2)

z*sin(theta/2)

sin(theta/2)是RV的数量级。

RV的方向与轴旋转的方向相同。

RV的三个数值，与cos(theta/2)组成一个四元组。

RV的数据没有单位，使用的坐标系与加速度相同。

举例：

GV、LA和RV的数值没有物理传感器可以直接给出，

需要G-sensor、O-sensor和Gyro-sensor经过算法计算后得出。

算法一般是传感器公司的私有产权。

『原创作品，转载请注明出处。 --- 孙国威』

〔文章原始地址  http://blog.csdn.net/manoel/article/details/39036507〕

当创建复杂的布局的时候，有时候会发现添加了很多的ViewGroup和View。随之而来的问题是View树的层次越来越深，应用也变的越来越慢，因为UI渲染是非常耗时的。

这时候就应该进行布局优化了。这里介绍两种方式，分别为<include>标签和ViewStub类。

<include/>

使用<include/>是为了避免代码的重复。设想一种情况，我们需要为app中的每个视图都添加一个footer，这个footer是一个显示app名字的TextView。通常多个Activity对应多个XML布局文件，难道要把这个TextView复制到每个XML中吗？如果TextView需要做修改，那么每个XML布局文件都要进行修改，那简直是噩梦。

面向对象编程的其中一个思想就是代码的复用，那么怎么进行布局的复用呢？这时，<include/>就起作用了。

如果学过C语言，那么对#include应该不陌生，它是一个预编译指令，在程序编译成二进制文件之前，会把#include的内容拷贝到#include的位置。

Android中的<include/>也可以这么理解，就是把某些通用的xml代码拷贝到<include/>所在的地方。以一个Activity为例。

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="fill_parent"
    android:layout_height="fill_parent" ><TextView
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:layout_centerInParent="true"
        android:gravity="center_horizontal"
        android:text="@string/hello" /><include layout="@layout/footer_with_layout_properties"/></RelativeLayout>

<TextView xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"
    android:layout_alignParentBottom="true"
    android:layout_marginBottom="30dp"
    android:gravity="center_horizontal"
    android:text="@string/footer_text" />

但是，仍然存在一些疑惑。

footer_with_layout_properties.xml中使用了android:layout_alignParentBottom属性，这个属性之所以可行，是因为外层布局是RelativeLayout。

那么，如果外层布局换做LinearLayout又会怎样呢？答案显而易见，这肯定是行不通的。那么怎么办呢？我们可以把具体的属性写在<include/>标签里面，看下面的代码。

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="fill_parent"
    android:layout_height="fill_parent"><TextView
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:layout_centerInParent="true"
        android:gravity="center_horizontal"
        android:text="@string/hello"/><include
        layout="@layout/footer"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:layout_alignParentBottom="true"
        android:layout_marginBottom="30dp"/></RelativeLayout>

注意：如果想要在<include/>标签中覆盖被包含布局所指定的任何android:layout_*属性，必须在<include/>标签中同时指定layout_width和layout_height属性，这可能是一个Android系统的一个bug吧。

ViewStub
在开发过程中，难免会遇到各种交互问题，例如显示或隐藏某个视图。如果想要一个视图只在需要的时候显示，可以尝试使用ViewStub这个类。

先看一下ViewStub的官方介绍：

“ViewStub是一个不可视并且大小为0的视图，可以延迟到运行时填充布局资源。当ViewStub设置为Visible或调用inflate()之后，就会填充布局资源，ViewStub便会被填充的视图替代”。

现在已经清楚ViewStub能干什么了，那么看一个例子。一个布局中，存在一个MapView，只有需要它的时候，才让它显示出来。

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent" ><Button
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:layout_gravity="center_vertical"
        android:onClick="onShowMap"
        android:text="@string/show_map" /><ViewStub
        android:id="@+id/map_stub"
        android:layout_width="fill_parent"
        android:layout_height="fill_parent"
        android:inflatedId="@+id/map_view"
        android:layout="@layout/map" /></RelativeLayout>

<com.google.android.maps.MapView xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/map_view"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:apiKey="my_api_key"
    android:clickable="true" />

另外，inflatedId是ViewStub被设置成Visible或调用inflate()方法后返回的id，这个id就是被填充的View的id。在这个例子中，就是MapView的id。

接下来看看ViewStub是怎么使用的。

public class MainActivity extends MapActivity {

  private View mViewStub;

  @Override
  public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);
    mViewStub = findViewById(R.id.map_stub);
  }

  public void onShowMap(View v) {
    mViewStub.setVisibility(View.VISIBLE);
  }

  @Override
  protected boolean isRouteDisplayed() {
    return false;
  }
}

题外话

确实是有区别的，会涉及到View树的渲染，内存消耗等。

至于有什么具体的差别，就请大家自己去Google吧。俗话说，自己动手，丰衣足食嘛！

参考资料

http://code.google.com/p/android/issues/detail?id=2863

http://android-developers.blogspot.com.ar/2009/03/android-layout-tricks-3-optimize-with.html

http://developer.android.com/reference/android/view/ViewStub.html

百度的移动搜索功能终于迈出了新的一步。这一次，百度要从连线用户和信息，转向连接用户和服务。

最新的连接渠道，就是百度副总裁李明远在今天百度世界大会上推出的新平台：直达号。

直达号到底是一个什么样的平台？百度借助这个平台想要实现什么样的价值？李明远在今天的演讲中介绍道，移动端的搜索流量不应该被浪费，百度将利用直达号为企业提供移动化解决方案，让用户在移动端直达商家服务。

直达号是什么？

直达号是商家在百度移动平台的官方服务账号。

商家的直达号展示在用户面前，其实类似于商家的移动端网站。

在直达号的移动页面上，可以实现各种功能，比如餐饮企业的座位预订、订餐、服务评论、查看菜单等功能。

目前已经开通的账号包括峨眉山、海底捞、良子健身、一亩田、平安保险等.

百度搜索海底捞，展现海底捞直达号

用户如何发现直达号？

直达号基于移动搜索、 @账号、地图、个性化推荐等多种方式，让顾客直达商家服务。

以目前开通直达号的海底捞为例，它就会在以下情景中出现在用户面前：

移动搜索：用户打开百度移动网页，或百度搜索应用，在输入框中输入“海底捞”，现在得到搜索结果的第一条就是海底捞的直达号。

@账号：用户在搜索框中输入“@海底捞”会跳过搜索结果页面，直接打开海底捞的直达号页面。

地图：目前还不适用于海底捞。官方解释是，在地图上搜索某商家，点击进去后可能会进入相应的直达号页面，

个性化推荐：基于场景和兴趣对用户推荐，让用户在百度移动端上直接看到海底捞的直达号。

百度搜索中输入@良子健身，直接跳转到商家直达号

商家如何建立自己的直达号？

百度针对不同行业推出适配于细分行业需求的模板。商家登录之后，选择自己所处的行业，编辑文字，上传图片，就能开通一个直达号。如果行业模板不能满足个性化需求，商家还可以使用组件工厂，通过选择一些模块，进行拖拽编辑，建立一个直达号。

百度为什么要推直达号？

1.帮助传统企业移动化。

大量线下企业想要移动化，但没有配套的移动互联网解决方案。用户在移动端不能方便地直接触达企业服务。所以百度希望利用直达号，为餐饮、旅游、娱乐、生活服务等各行各业商家直接提供移动化方案。

2.移动端的搜索流量不应该被浪费。

百度副总裁李明远以“良子健身”为例，用户在上午10点到下午6点期间，从手机百度以及百度地图寻找良子相关服务的需求，达到近千人次。如果把这些顾客需求都连接到良子健身直达号，可能为企业带来近100个潜在客单。

3.利用直达号为企业提供CRM系统。

百度利用已有的用户账号体系，帮助商家进行用户画像。通过数据分析，将用户标签化。让商家为用户提供个性化的服务。

今天，百度世界大会召开，从大会传达的信息和李彦宏演讲来看，未来百度将坚定不移地走技术流，既然是技术流，那么我们挑一个细节，分析一下百度是如何坚定地走技术流的。

我们所讲的细节就是这次在百度世界大会发布的两款硬件产品其中之一的百度筷搜。

无论百度将百度筷搜描绘成多么牛逼的产品，但当我们拆分一下会发现，虽然百度筷搜无论从需求或者是工艺上，它都能在如今参差不齐的智能硬件里面脱颖而出，它的核心技术依旧是百度的优势——大数据。

为什么这么说呢，因为在硬件方面，百度筷搜底端集成了四颗传感器，它们分别是，油脂快速分析引擎、钠离子分析装置、PH 值感应装置、高灵敏温度感应模块、这对应的测量对象就是油脂、盐分、PH 值和温度。

虽然把它们集成在筷子大小的硬件设备上的确十分考验工艺，但是想必我们日常生活中也会接触到便携式 PH 检测笔和高灵敏温度计等，因此百度筷搜在工艺上虽然很优秀，但是并不足以令人吃惊。

最令人吃惊的也是这个筷子最核心的价值就是其背后百度强大的数据库。

首先我们看看数据能值多少钱，此前基于癌症大数据分析的医疗初创公司 Flatiron Health 获得了 1.3 亿美元的 B 轮融资，而领投的正是 Google Venture。

当然，你可以认为医疗数据值钱多了，这完全是两码子事，但是从百度筷搜提供的信息包括营养成分、保质期、搭配禁忌、卡路里等关于食品的一系列信息，我们也可以看出这并不是一个小的数据量。

因此这也拉开了百度筷搜与其他硬件产品的距离，哪怕将 Flatiron Health 获得的融资除以 10 或者 100，它都不是一般的硬件厂商所能负担的。

为什么我要强调百度筷搜以及它背后的数据库？因为一直以来百度商业模式单一，过于依赖网络搜索入口的优势，但在移动互联网的当下，这一优势正面临动摇，百度急需下一个引爆点。这也是李彦宏喊出“狼性”口号的原因。

因此这一次百度开始认真的寻找一个新的方向，它不再只是想当一个单纯的入口，相反它想将自己已经积累的大数据以及技术转换成下一个赢利点。

这一次与硬件结合是一个很好的尝试，不能说是重新起航，但是正如李彦宏所说，人们表达需求的方式不再只是文字了，而将大数据与硬件结合，正是以另外一种方式解决人们的需求，或者说是将搜索信息以另外一种形式表达出来。

题图来自 blouinnews

吴翘楚

安心修道，才是王道。

邮箱

#欢迎关注爱范儿认证微信公众号：AppSolution（微信号：appsolution），发现新酷精华应用。

爱范儿 · Beats of Bits |原文链接· 查看评论· 新浪微博· 微信订阅· 加入爱范社区！

Code Review即代码审查是软件开发中常用的手段，它和QA测试相比，更容易发现架构以及时序相关等较难发现的问题，还可以帮助团队成员统一编程风格，提高编程技能等。代码审查被公认为是一个提高代码质量的有效手段。目前很多开发团队虽然进行了代码审查，但是他们可能没有有效、合理的进行代码审查，以致没有很好达到代码审查的目的。近日，BIDS 贸易科技有限公司的CTO Jim Bird总结了关于代码审查的一些建议。现对这些建议进行了一个全面的梳理，具体内容如下：

1、代码审查不要太正式

目前，有很多研究表明正式代码的评审会议会延误开发进度和增加开发成本。尽管可能只需要几周的时间进行代码评审，但是只有4%的缺陷是在会议期间发现的，其余所有的权限是靠代码审查者自己发现和处理的。只有采用简短、轻量的代码审查才是有效的发现问题在代码检查,这样的代码审查更适合迭代、增量开发，为开发者提供更快的反馈。

2、代码审查人员要尽可能少

并不是代码审查人员越多就能发现越多Bug，只有合理数量的审查人员才能够更加有效的地审查代码。研究表明，平均来说，一个代码审查人员能够发现Bug的一半, 第二审稿人会发现剩余新问题的一半。多个人同2个人发现问题的数量没有太大差异，故两个人进行代码审查是比较合适的。另外，还由于社会惰性的存在，更多代码审查人员意味着多人在寻找同样的问题，使得审查人员积极性、主动性不高，更加不利于代码审查工作的有效进行。

3、需要有经验的开发者进行代码审查

研究充分表明，代码审查的有效性依赖于审查人的技能和对问题领域以及代码的熟悉程度。如果让新加入团队的成员进行代码审查的话，并不利于他们的成长，且对于代码审查来说也是一种非常糟糕的方式。只有擅长阅读代码、程序调试、非常熟悉语言、框架、对应的问题的人才最适合代码审查，才能够高效发现问题、提供更多有价值的反馈。新的、没有经验的开发者只适合检查代码的变化和使用静态分析工具并和另一位评论人员共同代码审查。

4、实质重于方式

完全按照编码规格标准进行的代码审查是一个浪费开发人员宝贵时间的方式。代码审查的实质是确认代码能够正确的运行，发现安全漏洞、功能错误、代码错误、设计失误、安全验证和防范、恶意代码等。而不是单单按照编码规范完全保证代码格式一致，而丢失了代码审查的实质。

5、合理安排Bug 和可维护性问题代码的审查时间分配

发现代码中的Bug是很难的，在别人的代码找到的Bug更难。研究表明，代码审查人员找到Bug和可维护性、可读性问题的比例是25:75，故消耗在了代码可读性、可维护性等问题上和Bug上的代码审查时间应该合理分配。

6、尽量使用静态代码分析工具以提高审查效率

工欲善其事，必先利其器。静态代码分析工具可以帮助程序开发人员自动执行静态代码分析，快速定位代码隐藏错误和缺陷；帮助代码设计人员更专注于分析和解决代码设计缺陷；显著减少在代码逐行检查上花费的时间，提高了软件可靠性并节省软件开发和测试成本。

7、二八定律处理高风险代码

审查所有的代码并没有太大的意义，应该把审查的重点放在高风险的代码和容易引起高风险的修改或者重构的代码上。旧而复杂、处理敏感数据、处理重要业务逻辑和流程、大规模重构以及刚加入团队的开发者实现的代码都是审查的重点。

8、从代码审查中尽量获得最大的收益

虽然代码审查是发现Bug、提高开发人员代码编写质量的重要方式，但是它也增加了代码开发成本。如果没有合理、有效的进行代码审查，将有可能影响项目进度和破坏团队文化。故我们要紧抓代码审查的实质性问题，尽早和经常性的进行非正式的代码审查；选择精而少的人员并运用二八定律审查高风险的代码，同时，还需要合理分配Bug以及可维护性问题的代码审查时间，才可以从代码审查中获得最大的收益。

• —软件人才免语言低担保 赴美带薪读研！—

我靠解决技术债务养家糊口。在我的工作中我看到许多难以维护的代码，并且一次又一次地看到很多相同的原本可以避免的问题。

我专长于调试，修复，维护和扩展旧的软件系统。我的典型的客户拥有一个尚可运行的网站或内部应用，但是开发者已经不知所踪。业务需求已经改变了但是软件没有跟上。抑或我的客户有了些“快要完成”的东西但是由于预算和日程安排的关系失去了开发者。通常那包括一系列尚未完成的功能和bug。

我的客户通常被别的开发者告知需要丢弃所有的东西从头来过。大多数程序员不喜欢维护代码，尤其是维护别人的代码。当程序员写代码的时候他们总是在可维护性上问错误的问题——关于这个话题详见Matt DuVall的文章: The myth of maintainability

我在这里为你的开发项目提供了一些建议以使我有活可以干。

不要用版本控制

我总是能惊奇地发现在过去几年写的大项目不使用版本控制。如果你不使用版本控制，下一任开发者就要找出哪些文件是现有系统的一部分以及哪些仅仅是备份。他没有任何提交信息和改动日志来知悉代码的历史。我在我的文章Introduction to Abject-Oriented Programming中讲述了如何不使用版本控制。

自定义你的开发环境——越多越好

不要让下一任开发者可以轻松地上手。要求特定的开发语言版本和工具，并且确保他们和操作系统自带的版本有冲突。疯狂自定义你的Eclipse或VisualStudio或vim，然后写一些只能在那个配置下运行的宏和脚本。不要创建一个磁盘映像或者脚本来重现你的开发环境，并且不要写任何文档——那给了太多提示。

创建一个详细的构建和展开环境

把一个网站投入到正式服务器应该以下面的形式进行：

svn up
git pull
hg pull

程序员可以讨论代码是否简洁和优雅，然后他们转过身去建立最为详尽和复杂的展开系统。这是他们悄悄干的，不经过产品经理和客户的审查，也无法被理解的行为之一，所以它会轻易地失控。当你用不同的脚本语言把八个工具连接起来时，记得留下文档。

不要建立测试／登录平台

改变一个产品系统让人激动。不用麻烦去搭建测试或登录平台了。取而代之的，用秘密的登录方法或者用些后门URL来测试新特性。把测试数据和真实数据混合在你的数据库里。因为你没有使用版本控制，保存几份原先版本的拷贝以防万一。不要在代码里加入登录。不要在测试中关闭邮件发送，信用卡验证，等等。

将所有的东西从头写过

千万别用一个像Django, Rails, 或者CakePHP那样大家都能理解的框架。你可以写一个更好的引擎，ORM，排序或者哈希算法。当我看到一些例如“比原有字典更快的方法”或者“改变了PHP的库函数因为参数顺序烂透了”的注释时，我就要重置我的大脑。

为特殊的库和资源加上从属关系

尽可能多的加入第三方代码。连接你需要连接的库。我见过用了大量的外接库只为调用某个方法的代码。改变第三方库的源代码这样它们就无法自动更新，但是千万不要用版本控制。这样我就能发现不同的地方从而还原出原来的版本。

但是千万不要保护这些关系或者为此写文档

我接到最多的紧急电话和更新出错有关。一个看上去无害的wordpress升级，Linux更新包，或者新的jQuery版本会造成一系列实效。不要把你的代码放到特殊的或者不用的第三方库版本下检测。甚至不要加上注释。

用不同的编程语言并且紧跟潮流

每一天HackerNews和Reddit上涌现出新的酷的语言。在你的客户的东西上试试它们。任何合格的程序员可以在瞬间学会一种新语言，所以你的代码的继任者对其毫不了解也不是你的错。语言的边界，不兼容的API和数据格式，不同的服务器配置都是有趣的挑战并且值得在StackOverFlow上贴出来。我真的见过有人把Ruby嵌入PHP网站因为所有人都知道PHP很烂而Ruby更好。半吊子的caching, 流产的Rails和Node.js项目，特别是那些NoSQL方案都是我的好生意。

编程建议在哪里？

你的代码是否完美地面向对象，光鲜亮丽都无关紧要——程序员在面对旧的系统时总是一团浆糊。我擅长用diff，grep和Ctag, 追踪代码，重构和调试。我会搞清楚所有的东西。最美丽，优雅的代码如果缺少了版本控制，加上太多从属关系和自定义，并且没有测试系统的话仍然是很难维护的。这就像在一群强迫性囤积症患者中找到一间干净整洁的屋子。

如何开发无法维护的软件，首发于 博客 - 伯乐在线。

Java SE 5.0中引入了任务执行框架，这是简化多线程程序设计开发的一大进步。使用这个框架可以方便地管理任务：管理任务的生命周期以及执行策略。

在这篇文章中，我们通过一个简单的例子来展现这个框架所带来的灵活与简单。

基础

执行框架引入了Executor接口来管理任务的执行。Executor是一个用来提交Runnable任务的接口。这个接口将任务提交与任务执行隔离起来：拥有不同执行策略的executor都实现了同一个提交接口。改变执行策略不会影响任务的提交逻辑。

如果你要提交一个Runnable对象来执行，很简单：

Executor exec = …;
exec.execute(runnable);

线程池

如前所述，executor如何去执行提交的runnable任务并没有在Executor接口中规定，这取决于你所用的executor的具体类型。这个框架提供了几种不同的executor，执行策略针对不同的场景而不同。

你可能会用到的最常见的executor类型就是线程池executor，也就是ThreadPoolExecutor类（及其子类）的实例。ThreadPoolExecutor管理着一个线程池和一个工作队列，线程池存放着用于执行任务的工作线程。

你肯定在其他技术中也了解过“池”的概念。使用“池”的一个最大的好处就是减少资源创建的开销，用过并释放后，还可以重用。另一个间接的好处是你可以控制使用资源的多少。比如，你可以调整线程池的大小达到你想要的负载，而不损害系统的资源。

这个框架提供了一个工厂类，叫Executors，来创建线程池。使用这个工程类你可以创建不同特性的线程池。尽管底层的实现常常是一样的（ThreadPoolExecutor），但工厂类可以使你不必使用复杂的构造函数就可以快速地设置一个线程池。工程类的工厂方法有：

• newFixedThreadPool：该方法返回一个最大容量固定的线程池。它会按需创建新线程，线程数量不大于配置的数量大小。当线程数达到最大以后，线程池会一直维持这么多不变。
• newCachedThreadPool：该方法返回一个无界的线程池，也就是没有最大数量限制。但当工作量减小时，这类线程池会销毁没用的线程。
• newSingleThreadedExecutor：该方法返回一个executor，它可以保证所有的任务都在一个单线程中执行。
• newScheduledThreadPool：该方法返回一个固定大小的线程池，它支持延时和定时任务的执行。

这仅仅是一个开端。Executor还有一些其他用法已超出了这篇文章的范围，我强烈推荐你研究以下内容：

• 生命周期管理的方法，这些方法由ExecutorService接口声明（比如shutdown()和awaitTermination()）。
• 使用CompletionService来查询任务状态、获取返回值，如果有返回值的话。

ExecutorService接口特别重要，因为它提供了关闭线程池的方法，并确保清理了不再使用的资源。令人欣慰的是，ExecutorService接口相当简单、一目了然，我建议全面地学习下它的文档。

大致来说，当你向ExecutorService发送了一个shutdown()消息后，它就不会接收新提交的任务，但是仍在队列中的任务会被继续处理完。你可以使用isTerminated()来查询ExecutorService终止状态，或使用awaitTermination(…)方法来等待ExecutorService终止。如果传入一个最大超时时间作为参数，awaitTermination方法就不会永远等待。

警告：对JVM进程永远不会退出的理解上，存在着一些错误和迷惑。如果你不关闭executorService，只是销毁了底层的线程，JVM就不会退出。当最后一个普通线程（非守护线程）退出后，JVM也会退出。

配置ThreadPoolExecutor

如果你决定不使用Executor的工厂类，而是手动创建一个 ThreadPoolExecutor，你需要使用构造函数来创建并配置。下面是这个类使用最广泛的一个构造函数：

public ThreadPoolExecutor(
    int corePoolSize,
    int maxPoolSize,
    long keepAlive,
    TimeUnit unit,
    BlockingQueue<Runnable> workQueue,
    RejectedExecutionHandler handler);

如你所见，你可以配置以下内容：

• 核心池的大小（线程池将会使用的大小）
• 最大池大小
• 存活时间，空闲线程在这个时间后被销毁
• 存放任务的工作队列
• 任务提交拒绝后要执行的策略

限制队列中任务数

限制执行任务的并发数、限制线程池大小对应用程序以及程序执行结果的可预期性与稳定性有很大的好处。无尽地创建线程，最终会耗尽运行时资源。你的应用程序因此会产生严重的性能问题，甚至导致程序不稳定。

这只解决了部分问题：限制了并发任务数，但并没有限制提交到等待队列的任务数。如果任务提交的速率一直高于任务执行的速率，那么应用程序最终会出现资源短缺的状况。

解决方法是：

• 为Executor提供一个存放待执行任务的阻塞队列。如果队列填满，以后提交的任务会被“拒绝”。
• 当任务提交被拒绝时会触发RejectedExecutionHandler，这也是为什么这个类名中引用动词“rejected”。你可以实现自己的拒绝策略，或者使用框架内置的策略。

默认的拒绝策略可以让executor抛出一个RejectedExecutionException异常。然而，还有其他的内建策略：

• 悄悄地丢弃一个任务
• 丢弃最旧的任务，重新提交最新的
• 在调用者的线程中执行被拒绝的任务

什么时候以及为什么我们才会这样配置线程池？让我们看一个例子。

示例：并行执行独立的单线程任务

最近，我被叫去解决一个很久以前的任务的问题，我的客户之前就运行过这个任务。大致来说，这个任务包含一个组件，这个组件监听目录树所产生的文件系统事件。每当一个事件被触发，必须处理一个文件。一个专门的单线程执行文件处理。说真的，根据任务的特点，即使我能把它并行化，我也不想那么做。一天的某些时候，事件到达率才很高，文件也没必要实时处理，在第二天之前处理完即可。

当前的实现采用了一些混合且匹配的技术，包括使用UNIX SHELL脚本扫描目录结构，并检测是否发生改变。实现完成后，我们采用了双核的执行环境。同样，事件的到达率相当低：目前为止，事件数以百万计，总共要处理1～2T字节的原始数据。

运行处理程序的主机是12核的机器：很好机会去并行化这些旧的单线程任务。基本上，我们有了食谱的所有原料，我们需要做的仅仅是把程序建立起来并调节。在写代码前，我们必须了解下程序的负载。我列一下我检测到的内容：

• 有非常多的文件需要被周期性地扫描：每个目录包含1～2百万个文件
• 扫描算法很快，可以并行化
• 处理一个文件至少需要1s，甚至上升到2s或3s
• 处理文件时，性能瓶颈主要是CPU
• CPU利用率必须可调，根据一天时间的不同而使用不同的负载配置。

我需要这样一个线程池，它的大小在程序运行的时候通过负载配置来设置。我倾向于根据负载策略创建一个固定大小的线程池。由于线程的性能瓶颈在CPU，它的核心使用率是100%，不会等待其他资源，那么负载策略就很好计算了：用执行环境的CPU核心数乘以一个负载因子（保证计算的结果在峰值时至少有一个核心）：

int cpus = Runtime.getRuntime().availableProcessors();
int maxThreads = cpus * scaleFactor;
maxThreads = (maxThreads > 0 ? maxThreads : 1);

然后我需要使用阻塞队列创建一个ThreadPoolExecutor，可以限制提交的任务数。为什么？是这样，扫描算法执行很快，很快就产生庞大数量需要处理的文件。数量有多庞大呢？很难预测，因为变动太大了。我不想让executor内部的队列不加选择地填满了要执行的任务实例（这些实例包含了庞大的文件描述符）。我宁愿在队列填满时，拒绝这些文件。

而且，我将使用ThreadPoolExecutor.CallerRunsPolicy作为拒绝策略。为什么？因为当队列已满时，线程池的线程忙于处理文件，我让提交任务的线程去执行它（被拒绝的任务）。这样，扫面会停止，转而去处理一个文件，处理结束后马上又会扫描目录。

下面是创建executor的代码：

ExecutorService executorService =
    new ThreadPoolExecutor(
        maxThreads, // core thread pool size
        maxThreads, // maximum thread pool size
        1, // time to wait before resizing pool
        TimeUnit.MINUTES, 
        new ArrayBlockingQueue<Runnable>(maxThreads, true),
        new ThreadPoolExecutor.CallerRunsPolicy());

下面是程序的框架（极其简化版）：

// scanning loop: fake scanning
while (!dirsToProcess.isEmpty()) {
    File currentDir = dirsToProcess.pop();

    // listing children
    File[] children = currentDir.listFiles();

    // processing children
    for (final File currentFile : children) {
        // if it's a directory, defer processing
        if (currentFile.isDirectory()) {
            dirsToProcess.add(currentFile);
            continue;
        }

        executorService.submit(new Runnable() {
            @Override
            public void run() {
                try {
                    // if it's a file, process it
                    new ConvertTask(currentFile).perform();
                } catch (Exception ex) {
                    // error management logic
                }
            }
        });
    }
}

// ...
// wait for all of the executor threads to finish
executorService.shutdown();
try {
    if (!executorService.awaitTermination(60, TimeUnit.SECONDS)) {
        // pool didn't terminate after the first try
        executorService.shutdownNow();
    }

    if (!executorService.awaitTermination(60, TimeUnit.SECONDS)) {
        // pool didn't terminate after the second try
    }
} catch (InterruptedException ex) {
    executorService.shutdownNow();
    Thread.currentThread().interrupt();
}

总结

看到了吧，Java并发API非常简单易用，十分灵活，也很强大。真希望我多年前可以多花点功夫写一个这样简单的程序。这样我就可以在几小时内解决由传统单线程组件所引发的扩展性问题。

相关文章

• 线程池实例：使用Executors和ThreadPoolExecutor
• 深入理解JVM内幕：从基本结构到Java 7新特性
• 使用Specs进行单元测试
• Android 4.3可能于7月发布
• FileOutputStream vs. FileWriter
• HashSet vs. TreeSet vs. LinkedHashSet
• Java 8简明教程
• WAR包 vs 集成服务器的Java应用
• POJO中使用ThreadLocal实现Java嵌套事务
• jOOQ：如何通过高内聚消除Bug

　　 英文原文：http://www.sitepoint.com/complete-guide-reducing-page-weight/

　　据调查，网页大小在2013年平均增长了32%，平均达到了1.7M，单独的HTTP请求达到96个。这是令人震惊的数字，而且这只是个平均值，有一半的网站会大于这个值。网站也得了肥胖症，而我们这些开发者就是罪魁祸首。

　　一个超重的网站会对你产生如下影响：

　　1. 网站代码越多，用户下载的就越多，加载速度就会越慢。在这个地球上，并不是每个人都能享受20M的宽带，每一个开发者心里都很清楚，用户不愿意等。

　　2. 众所周知，移动互联网发展迅速，对于2G网络来说，加载1.7M的页面甚至需要一分钟时间。

　　3. 影响搜索引擎抓取速度将会对网站排名造成很大影响。

　　4. 对于开发者来说，代码量越大，就越不容易更新和维护。

　　我猜测今年页面平均代码量会减小，希望事实如我所愿。如今已经有很多人开始关注这个问题，并出现了很多优化的工具，而且这些技术都非常容易上手，不需要花太多时间，也不需要重新开发。

　　在本文中，我会给大家一些建议。前三个建议实际上不能给网页减肥，但它们仍能有效的加快网页加载速度。

　　1. 用GZIP格式压缩

　　gzip是GNUzip的缩写，它是一个GNU自由软件的文件压缩程序。它是Jean-loupGailly和MarkAdler一起开发的。第一次公开发布版本是1992年10月31日发布的版本0.1，1993年2月发布了版本1.0。

我们在Linux中经常会用到后缀为.gz的文件，它们就是GZIP格式的。现今已经成为Internet 上使用非常普遍的一种数据压缩格式，或者说一种文件格式。

　　HTTP协议上的GZIP编码是一种用来改进WEB应用程序性能的技术。大流量的WEB站点常常使用GZIP压缩技术来让用户感受更快的速度。这一般是指WWW服务器中安装的一个功能，当有人来访问这个服务器中的网站时，服务器中的这个功能就将网页内容压缩后传输到来访的电脑浏览器中显示出来.一般对纯文本内容可压缩到原大小的40%.这样传输就快了，效果就是你点击网址后会很快的显示出来.当然这也会增加服务器的负载. 一般服务器中都安装有这个功能模块的。

　　根据W3C组织调查，大部分的网站都没有启用压缩功能。 

　　2. 支持浏览器缓存

　　如果浏览器支持缓存，我们就不用重复下载网页资源。最简单的设置缓存方法是在响应头中添加相应的内容，包括：Expires header，Last-Modified等。

　　你可以可以通过配置服务器来自动添加这些属性。比如你在Apache服务器中配置缓存所有的照片一个月:

　　3. 使用内容分发网络 (CDN)

　　CDN的全称是Content Delivery Network，即内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络“边缘”，使用户可以就近取得所需的内容，提高用户访问网站的响应速度。CDN有别于镜像，因为它比镜像更智能，或者可以做这样一个比 喻：CDN=更智能的镜像+缓存+流量导流。因而，CDN可以明显提高Internet网络中信息流动的效率。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等问题，提高用户访问网站的响应速度。 

　　为更好地理解CDN，让我们看一下CDN的工作流程。当用户访问已经加入CDN服务的网站时，首先通过DNS重定向技术确定最接近用户的最佳CDN节点，同时将用户的请求指向该节点。当用户的请求到达指定节点时，CDN的服务器（节点上的高速缓存）负责将用户请求的内容提供给用户。具体流程为: 用户在自己的浏览器中输入要访问的网站的域名，浏览器向本地DNS请求对该域名的解析，本地DNS将请求发到网站的主DNS，主DNS根据一系列的策略确定当时最适当的CDN节点，并将解析的结果（IP地址）发给用户，用户向给定的CDN节点请求相——应网站的内容。

　　以上三个方法可以有效地加快页面的访问速度，现在我们将对你的代码进行诊断，帮助我们给页面减肥。

　　4. 删除不需要的资源

　　当你不再需要一个组件的时候，你应该删掉它的CSS和JavaScript代码，如果这些代码都单独放在一个文件中，那删掉它们也不是难事，但如果已经没有用的代码和其它代码在一个文件中，那你肯定要费不少精力去删掉它们。这个时候你就需要使用第三方的工具来帮你一键解决，比如 JSLint,  Dust-Me Selectors,  CSS Usage,  unused-css.com 或是像 grunt-uncss一样的构建工具。

　　5. 通用和最小化CSS

　　理想情况下，需要一个单独的CSS文件，让每个页面都调用这一个布局，当然，如果你想要支持老版本的IE，你就得多弄一个CSS文件。当你把它们构建到服务器上之前，你应该把代码间所有不必要的格式都删掉。

　　有很多预处理工具都可以帮你解决这件麻烦事，比如 Sass,  LESS 和 Stylus。

　　有一些方法可以帮助你直接合并多个CSS文件，在Windows上：

　　在 Mac或Linux上：

　　你可以把得到的CSS文件再经过在线的CSS压缩工具删除格式化， cssminifier.com,  CSS Compressor & Minifier 和 CSS Compressor都是很不错的工具。

　　最后，在head标签中加载所有的CSS，这样浏览器就知道你的页面样式不用多次重绘了。

　　6. 通用和最小化的JavaScript

　　平均每个页面加载了18个javascript文件，虽然把像jQuery这样的库文件单独分开非常实用，但是你自己的JavaScript代码应该保持通用和最小化。同样很多第三方的工具可以帮你解决这样事情，比如  YUI Compressor,  Closure Compiler 和我最喜欢用的  The JavaScript CompressorRater。简化的JavaScript代码会加快网页的访问速度，减少HTTP请求次数。

　　最后，最好在HTML的body标签后放置JavaScript引用代码，这样能保证JavaScript代码不影响到其它内容的加载。

　　7. 使用正确的图片路径

　　加载错误的图片格式会对你的网页造成很大影响，一般来说选取图片我们应用遵循如下原则：

　　1.照片使用JPG格式。

　　2.其它所有的图片都使用PNG格式。

　　8. 调整大图的大小

　　目前智能机所拍出的照片越来越大，你不可能把原照片直接展示在页面中。普通的编辑器都会直接上传原图，这样会让页面的加载速度慢到另一个级别。在正常的照片处理中，一般都没有必要给用户高质量的图片展示。所以你需要一个自动调整图片大小的工具。

　　需要注意的是，图片的尺寸是不能超过容量的大小的，这样一来页面加载了全图，却无法展示出来。现在照片的尺寸基本上都超过电脑显示屏的尺寸了。

　　图片的大小在网页总大小中占很大的比重，图片减小50%会导致整体页面大小减少75%，所以你应该认真解决一下图片的加载。

　　9. 进一步压缩图片

　　仅仅调优图片的大小是不够的，你应该通过第三方工具对图片进行分析，进一步压缩图片。比较好用的工具有 OptiPNG,  PNGOUT,  jpegtran 和 jpegoptim。这些工具大都能安装成独立的工具或是整合到开发过程中，另外像 Smush这样的工具，还可以直接在云端处理。

　　10. 删除不必要的字体

　　Web fonts已经彻底改变了字体的设计，它减少了很多不必要的文本。然而，目前的字体仍然会给你的网页带来多余的字节。如果你使用超过两种字体，这就已经开始对性能造成影响了。

　　结论

　　我相信大部分网站都可以通过以上的优化减小大概30%-50%的重量，但是身为一个完美主义的开发者这是远远不够的，我们在接下来的系列文章中会继续对网站瘦身进行深入研究，感兴趣的可以关注一下极客头条的微博和微信，我们会将接下来的文章在各个社交平台上进行推送。

public class Producer {
	public static void main(String[] args) {
	    String user = ActiveMQConnection.DEFAULT_USER;
	    String password = ActiveMQConnection.DEFAULT_PASSWORD;
	    String url = ActiveMQConnection.DEFAULT_BROKER_URL;
	    String subject = "TOOL.DEFAULT";
	    System.out.println(user +" "+ password+" "+url+" "+subject+" ");
		ConnectionFactory contectionFactory = new ActiveMQConnectionFactory(user,password,url);
		try {
			Connection connection = contectionFactory.createConnection();
			connection.start();
			Session session = connection.createSession(Boolean.TRUE, Session.AUTO_ACKNOWLEDGE);
			Destination destination = session.createQueue(subject);
			MessageProducer producer = session.createProducer(destination);
			for(int i = 0;i<=20;i++){
				MapMessage message = session.createMapMessage();
				message.setLong("date", new Date().getTime());
				Thread.sleep(5000);
				producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
				producer.send(message);
				System.out.println("—SendMessge："+new Date());
			}
			session.commit();
			session.close();
			connection.close();
		} catch (JMSException e) {
			e.printStackTrace();
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
	}
}

public class Consumer {

	public static void main(String[] args) {
		String user = ActiveMQConnection.DEFAULT_USER;
	    String password = ActiveMQConnection.DEFAULT_PASSWORD;
	    String url = ActiveMQConnection.DEFAULT_BROKER_URL;
	    String subject = "TOOL.DEFAULT";
		ConnectionFactory connectionFactory = new ActiveMQConnectionFactory(user,password,url);
		Connection connection;
		try {
			connection = connectionFactory.createConnection();
			connection.start();
			final Session session = connection.createSession(Boolean.TRUE, Session.AUTO_ACKNOWLEDGE);
			Destination destination = session.createQueue(subject);
			MessageConsumer message = session.createConsumer(destination);
			message.setMessageListener(new MessageListener(){

				public void onMessage(Message msg) {
					MapMessage message = (MapMessage)msg;
					try {
						System.out.println("--Receive："+new Date(message.getLong("date")));
						session.commit();
					} catch (JMSException e) {
						e.printStackTrace();
					}
				}
			});
			Thread.sleep(30000);
			session.close();
			connection.close();
		} catch (JMSException e) {
			e.printStackTrace();
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
	}

}

• —软件人才免语言低担保 赴美带薪读研！—

9 月 4 日，Twitter 财务官安东尼·诺托（Anthony Noto）透露，Twitter 将优先改进搜索服务，同时还将开发群聊功能。

在花旗全球技术大会上，诺托称，Twitter 新任产品主管丹尼尔·格拉夫（Daniel Graf）把提升搜索功能作为 2015 年工作的首要目标之一。

诺托说：“说起搜索功能，我们拥有一个关于主题 Twitter 消息的信息数据集。搜索的结构层次必须适用于这种分类方法。”他还表示，Twitter 因此需要一种算法，这种算法要展示特定主题内容的深度和广度，并要让内容与用户相关联。

这就与 Twitter 更大的战略目标联系在一起——Twitter 希望更好地组织自己的内容，帮助用户从信息噪音中分离出有趣、及时的 Twitter 信息。Twitter 已经着手改进时间轴功能。时间轴可以展示陌生用户发布的信息，这是它最显著的特点，也是颇具争议的特点。

Twitter 时间轴以相反的时间顺序展示信息，自从八年前上线以来，这项功能就没有变化。一些早期 Twitter 用户甚至将时间轴奉为核心 Twitter 体验。

但诺托表示：“对于用户，它（时间轴）并不是最相关的体验。”举例来说，如果用户没有打开 Twitter 应用，一些及时的 Twitter 信息可能被其他信息淹没，埋藏在时间轴底部。

“如果要更好地组织 Twitter 内容，Twitter 就要把信息及时放到用户眼前。”诺托补充道。

上周六，Twitter 首席执行官迪克·科斯特罗(Dick Costolo)尝试在 Twitter 上解释时间轴信息推送服务的优点。针对用户抱怨的“不速之客类信息”，科斯特罗称用户两次刷新时间轴，时间轴就会展示其他用户喜爱的信息，Twitter 无法连续两次展示新的内容。

“否则，用户的第二次内容请求就会返回空值。我认为，满足用户的请求是一个值得我们努力的目标。”科斯特罗这样解释。

诺托表示，改进将是渐进式的。“我们将有条不紊地加以改进。我们会测试，确保自己了解各种可能性。我们不会妄想用户在某一天早晨醒来，突然发现自己时间轴完全以一种算法推送信息。”他说道。

诺托还暗示，Twitter 可能正在开发群聊功能。Twitter 私信功能历来居于次要地位。公开是 Twitter 服务的本质特性，Twitter 内部一直争论私信功能所扮演的角色。过去一年，随着消息应用的兴起，Twitter 已经让私信功能扮演一个更加突出的角色。诺托认为私信功能可能会更加社交化。

现在，Twitter 用户只能每次向一个帐号发送一条私信。诺托表示：“假如我用 Twitter 发布了一条球赛信息，同学可能会回复这条信息。但是，我不想当着老板和其他用户的面与同学讨论球赛。那么我就会选择私密的交流方式，我可能会选择私信功能。目前，私信功能只支持一对一会话，还不支持一对多会话。因此，这就是一个围绕分享或表达的创新样本。”

本文链接

作者：田民 赤莺

WordPress是国内站长非常喜欢采用的一款建站应用软件，由于其具有非常丰富的模版和插件，具有良好的可扩展性。特别对于博客类网站，WordPress几乎成为建站首选。

在阿里云安全团队的日常运营中，我们发现，WordPress一直是黑客攻击的主要目标。下图是阿里云云盾安全运营团队对第三方应用遭受攻击的统计（Source：第27期阿里云云盾安全运营报告，http://security.aliyun.com/doc/view/13762631.html）：

图1 WordPress是攻击者最主要的攻击目标之一

从上图来看，WordPress是攻击者最主要的攻击目标应用之一。这很大程度上在于WordPress应用在建站中的大量采用，以及不断暴露出来的安全隐患。

WordPress存在安全隐患的原因主要在于两个方面：一方面由于应用功能的丰富，程序越来越复杂，WordPress屡暴漏洞在所难免；另一方面提供WordPress主题和插件下载的网站五花八门、鱼龙混杂。很多黑客恰恰利用了这个现状，通过各种提供WordPress建站资源下载的网站散布带有恶意脚本的插件。事实上，上述两方面原因中后者的安全隐患更大。对于一个渴望找到建站资源的网站站长，在下载插件程序时，往往疏于防护，对提供下载资源的来源网站不加选择。

云盾安全技术团队在不久前截获了一个带有后门的WordPress程序。这个后门程序存在于WordPress一个叫做“KnowHow”的主题插件中。在这个插件里，我们发现如下代码：

图2: WordPress主题程序中的后门

红圈内的代码，很显然，就是后门。攻击者利用这个后门可以进一步获得网站的控制权。

经过云盾安全技术人员进一步调查，KnowHow是一款非常流行的WordPress主题。KowHow主题是收费的，价格为48美金。为了明确问题的根源，技术人员决定从确定被植入后门的程序来源入手。

我们联系了用户。和用户沟通后证实，该用户并非购买的正版主题，而是从国内某偏僻站点下载。与此同时，我们从官方渠道下载了一份同版本的主题程序，两者进行了比较。结果证实官方版本中并没有相对应的后门代码。因此，用户下载的程序显然是被人恶意修改后发布的版本。

我们并没有到此止步。云盾安全技术人员接下来经过搜索和对比， 发现大量国内此主题的下载文件中被人嵌入了类似的后门。

在明确了后门问题的原因后，云盾安全运营团队立刻对阿里云全网用户进行了扫描，并在第一时间通知了存在类似安全隐患的阿里云用户。

最后，对于WordPress KnowHow主题后门，阿里云云盾安全运营团队提出如下建议：

第一，请已下载并安装Knowhow主题的站长尽快检查自己的网站服务器，找到 /wp-content/themes/knowhow/functions.php文件，对比上文检查是否存在恶意代码。后门特征一般含有eval字符；

第二，从官方或具有良好信誉的网站下载插件，不要随意下载/添加不明站点的代码；

第三，请购买正版软件。