大多数时候，难以拒绝别人，其实是无法接受一个“不被别人喜爱的自己”——即是只有在不断满足对方的要求，并且在这个过程中判断自己被对方接纳的时候，才能获得被对方肯定的满足感。

尽管对方可能只是自己生活中一个过客，甚至只是一名不会对自己产生任何影响的推销员，我们都可能因为对方因我们的拒绝而产生的失望感到自责，所以，会通过满足对方的提议来实现对方的肯定。

但是，很多人没有意识到的是，这种满足感的来源，是你大量的时间耗费和情感耗费。

我认识一个朋友，她有一个好闺蜜在做代购。每一次，当她的好闺蜜代购时，都会让她帮忙转发，甚至要求她转发给其他好友，并截图给她看。

我那个朋友，还真的照做了。

我问，你难道不觉得这件事情很不值得吗？

她回答我说，是很不值得，但是她求我帮忙的时候，我真的不知道如何拒绝，我只能去做。

这就是典型的无法拒绝别人的情形。

当她在耗费大量时间、精力和人脉完成一件事情，并且潜意识中认为这件事非做不可的时候，其实是一种“瘾”——这种瘾所产生的心理暗示强迫你“必须完成对方要求你的事情”。

本质上它和游戏成瘾没有什么两样。

很多时候难以拒绝某一个人，不是因为TA和自己有多熟，而是他的举动让你产生了“上瘾感”：

1. TA往往会把这件事情形容得对TA很重要，并且用上一些优先级很高的词，比如“求你了”“拜托了”这样的说辞；
2. TA会在你没有帮助TA之前，表现出“你这样做很不够意思”的态度；并且在你帮助TA之后，告诉你“真的很感谢你”——但实际上，你们的感情并不会因为你帮了TA而更加坚固，他还会再次请你帮忙，然后再次“真的很感谢你”。

如果你面对以上这种举动，自己无法抗拒的话，那么基本可以判断你有这种成瘾行为。

戒掉任何一种“瘾”，最好的办法，是找到另一种“瘾”替代它。

这听上去好像有点荒唐，但是却是最好的办法。

其实任何一个难以拒绝别人的人，都或多或少有讨好型人格的一面——在这一面人格里，内心会不断告诉你，别人对自己的喜爱很重要，因此照顾别人的情绪很重要。

因此，你可以找到一种更强烈的瘾，比如说，去讨好更重要的人。

所谓去讨好更重要的人，就是你反复地告诉自己，讨好真正喜爱自己的人，比讨好一个只会索取的人，要更有价值。

最重要的一点是，当你不断固化“讨好只会索取的人”会使得你“不能照顾到更重要的人”的时候，你的大脑就会自动在这两类成瘾对象里面比较并选择更重要的人，而不再去选择讨好那些只会索取的人。

比如当一个根本和你不熟的同事平白无故就要求你帮她做ppt，但是你不好拒绝的时候，不妨这样思考：

如果我帮你做PPT，那也就意味着我少了和男/女朋友煲电话的两个小时。

难道帮一个陌生人，比我的伴侣的爱还要重要？

这样，你就可以从“讨好所有人”的上瘾者，变成“讨好爱自己和自己爱的人”的上瘾者。

而对爱自己和自己爱的人，给予他们关怀，不是很美妙的事么？

附：在言语上应该如何拒绝？

1. 当对方提出要求时，首先条件反射性地判断，“他是不是一个我值得帮忙的人”，以及“这件事是不是不值得的”。

2. 当做出这种判断确认不值得帮之后，回复对方：不好意思，我有更重要的事情要忙；

3. 在2的情形下，对方往往会从阐释客观事件（“我的这件事本身很容易的，你就帮一下”）和怀疑主观动机（“我看你也不忙啊”）来继续提出请求；

4. 如果对方阐释客观事件，需要做的不是和他辩论他让你帮忙的事到底是不是小事，而是让对方知道“既然是一件小事，那你完全可以自己做，或者有比我更好的人选代替我。”

5. 如果对方怀疑主观动机，需要做的不是告诉他“我真的很忙”，而是让对方知道，“我并没有义务帮忙，因此，无论我主观动因是什么，当我告诉你我很忙的时候，就代表我不想帮。在这种情况下，怀疑我的主观动因没有意义”。

6. 至于对方面对面要求你帮忙时，… 阅读全文

【编者的话】用了Docker，好处挺多的，但是有一个不大不小的问题，它会一不小心占用太多磁盘，这就意味着我们必须及时清理。

• 所有服务器的配置都非常简单，只安装了Docker，这样新增服务器的时候要简单很多。
• 可以非常方便地在服务器之间移动各种服务，下载Docker镜像就可以运行，不需要手动配置运行环境。
• 开发/测试环境与生产环境严格一致，不用担心由于环境问题导致部署失败。

至少，上线这一年多来，Docker一直非常稳定，没有出什么问题。但是，它有一个不大不小的问题，会比较消耗磁盘空间。

如果Docker一不小心把磁盘空间全占满了，你的服务也就算玩完了，因此所有Docker用户都需要对此保持警惕。当然，大家也不要紧张，这个问题还是挺好解决的。

1. Docker System命令

在《谁用光了磁盘？Docker System命令详解》中，我们详细介绍了Docker System命令，它可以用于管理磁盘空间。

docker system df命令，类似于Linux上的df命令，用于查看Docker的磁盘使用情况：

docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              147                 36                  7.204GB             3.887GB (53%)
Containers          

在这篇文章中：

• 1.lrucache
• 2.disklrucache
• 3. 缓存策略对比与总结

不论是android还是ios设备，流量对于用户而言都是宝贵的。在没有wifi的场景下，如果加载批量的图片消耗用户过多流量，被其知晓，又要被念叨一波~

如何避免消耗过多的流量呢？当程序第一次从网络加载图片后，就将其缓存到移动设备上，这样再次使用这个图片时，就不用再次从网络上下载为用户节省了流量。

目前常用的一种缓存算法是lru（least recently used），它的核心思想是当缓存满了，会优先淘汰近期最少使用的缓存对象。采用lru算法的缓存有两种：lrucache和disklrucache，lrucache主要用于实现内存缓存，disklrucache则用于存储设备缓存。

1.lrucache

lrucache是api level 12提供的一个泛型类，它内部采用一个linkedhashmap以强引用的方式存储外界的缓存对象，提供了get和put方法来完成缓存的获取和添加操作，当缓存满了，lrucache会remove掉较早使用的缓存对象，然后再添加新的对象。

过去实现内存缓存的常用做法是使用softreference或者使用weakreference，但是并不推荐这种做法，从api level 9以后，gc强制回收掉soft、weak引用，从而导致这些缓存并没有任何效率的提升。

lrucache的实现原理：

根据lru的算法思想，我们需要一种数据结构来快速定位哪个对象是最近访问的，哪个对象是最长时间未访问的，lrucache选择的是linkedhashmap这个数据结构，它是一个双向循环链表。来瞅一眼linkedhashmap的构造函数：

/** 初始化linkedhashmap

     * 第一个参数：initialcapacity，初始大小

     * 第二个参数：loadfactor，负载因子=0.75f

     * 第三个参数：accessorder=true，基于访问顺序；accessorder=false，基于插入顺序<br/>**/

   public linkedhashmap(int initialcapacity, float loadfactor, boolean accessorder

… 阅读全文

前言

public class

刚入手android一个多月，因公司需要提交技术文档，才写了这个demo测试，想保存下来，以备后用！有什么不对的地方欢迎大家指正，这个示例也是参考了网上别人的demo自己做的。

Android应用程序的升级（自身升级）

一、       引言：

很多的Android应用都具有版本检测和自动更新的功能，用户一键就可以完成软件的升级和更新。Android应用程序的升级本质上是利用了Linux系统的软件包管理和安装机制，而对于上层这一功能的开发来说很容易，只需要我们开发人员利用Android自带的API就可以实现。

二、     功能说明：

1、本示例用来实现单个应用程序的自身升级

2、程序启动时，连接tomcat7 web服务器进行版本的检测，若有新版本则提示更新

3、将从web服务器下载的新版本的APK文件放到sdcard中

4、监听新版本的APK应用是否安装完成，如果是，则将下载的apk文件从sdcard中删除

三、     程序框架流程：

四、     环境说明：

1、 服务器端：Ubuntu下的tomcat7web服务器，安装后默认端口是8080，Android模拟器访问时要将apk文件放到 /var/lib/tomcat7/webapps/ROOT/目录下，Android模拟器的访问方式是http：//10.0.2.2/NewAppSample.apk

2、 Android模拟器端的开发环境：

Ubuntu+eclipse+ADT

五、     流程详解及关键点说明：

(一)   新版本的应用程序（NewAppSample）准备：

a)  新建一个android工程，编辑其版本代码为2，高于我们的旧版本用于更新测试，版本名称为1.0.1

b)  编辑应用程序对应的版本信息文件version.json

说明：后缀为json的文件是一种轻量级的数据交换格式，比xml要快很多，适合于小型数据的网络交换，其实质类似键值对，键用字符串的形式表示与其值用冒号隔开，能存储多种数据类型。

(二) 旧版本的应用程序准备：

1、在其AndroidManifest.xml中定义版本代码为versionCode=”1”让其自动生成即可，我们主要利用程序的版本代码的高低来判断是否有新的版本，用于更新。

2、我们在应用程序启动时自动联网检测是否有新的版本，即在onCreate（）函数中进行联网检测。

a)  从服务器获得读取版本信息文件version.json，我们单独写了一个类来实现，用其GetUpdateInfo静态方法来返回读取的version.json，返回形式是字符串。代码如下

b)  获得当前旧的应用程序版本信息，我们单独封装了一个类CurrentVersion，用其中的静态方法来获得当前应用的版本信息，包括程序的名称版本，代码版本，和应用程序名字。

代码如下：… 阅读全文

一直以来， 一直在用svn做为版本系统， 最近几年git异常流行， 看来到了必须学习一下的时刻了， 若是为了学习而学习， 学了，然后时间长了不用， 估计也就忘记了， 因此必须应用到实际环境中。

初步考虑在家里的一个pc上安装git 的server， 然后把个人的资料， 分布在笔记本上， 其他机器上的资料通过git都做版本化， 这样由于数据， 在笔记本上保存一份本地副本， 在gitserver上也存在一份， 可以充分防止丢失。

另外利用git等的版本化功能， 可以分析数据的变化情况等， 做好历史记录， 即使有重名的数据， 重复的文件， 数据的删除等都可以通过历史等进行显示和管理等。

为此上网收集了一些资料， 参照进行了实践， 资料记录如下：

 Windows下Git Server的搭建

参数
-a 显示全部接口信息

[root@controller hello]# ifconfig -a
enp0s3: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500
inet 192.168.10.202 netmask 255.255.255.0 broadcast 192.168.10.255
inet6 fe80::a00:27ff:febc:4068 prefixlen 64 scopeid 0x20<link>
ether 08:00:27:bc:40:68 txqueuelen 1000 (Ethernet)
RX packets 132991 bytes 86829278 (82.8 MiB)
RX errors 0 dropped 0 … 阅读全文

团队开发过程中，Subversion是首选的源码版本控制软件，Trac是基于网页界面的项目管理和缺陷最终的软件，最重要的是它们都是开源的。

最近我在用图形数据库来完成对一个初创项目的支持。在使用过程中觉得这种图形数据库实际上挺有意思的。因此在这里给大家做一个简单的介绍。

NoSQL数据库相信大家都听说过。它们常常可以用来处理传统的关系型数据库所难以解决的一系列问题。通常情况下，这些NoSQL数据库分为Graph，Document，Column Family以及Key-Value Store等四种。这四种类型的数据库分别使用了不同的数据结构来记录数据。因此它们所适用的场景也不尽相同。

其中最为特别的便是图形数据库了。可以说，它和其它的一系列NoSQL数据库非常不同：丰富的关系表示，完整的事务支持，却没有一个纯正的横向扩展解决方案。

在本文中，我们就将对业界非常流行的图形数据库Neo4J进行简单的介绍。

图形数据库简介

相信您和我一样，在使用关系型数据库时常常会遇到一系列非常复杂的设计问题。例如一部电影中的各个演员常常有主角配角之分，还要有导演，特效等人员的参与。通常情况下这些人员常常都被抽象为Person类型，对应着同一个数据库表。同时一位导演本身也可以是其它电影或者电视剧的演员，更可能是歌手，甚至是某些影视公司的投资者（没错，我这个例子的确是以赵薇为模板的）。而这些影视公司则常常是一系列电影，电视剧的资方。这种彼此关联的关系常常会非常复杂，而且在两个实体之间常常同时存在着多个不同的关系：

在尝试使用关系型数据库对这些关系进行建模时，我们首先需要建立表示各种实体的一系列表：表示人的表，表示电影的表，表示电视剧的表，表示影视公司的表等等。这些表常常需要通过一系列关联表将它们关联起来：通过这些关联表来记录一个人到底参演过哪些电影，参演过哪些电视剧，唱过哪些歌，同时又是哪些公司的投资方。同时我们还需要创建一系列关联表来记录一部电影中哪些人是主角，哪些人是配角，哪个人是导演，哪些人是特效等。可以看到，我们需要大量的关联表来记录这一系列复杂的关系。在更多实体引入之后，我们将需要越来越多的关联表，从而使得基于关系型数据库的解决方案繁琐易错。

这一切的症结主要在于关系型数据库是以为实体建模这一基础理念设计的。该设计理念并没有提供对这些实体间关系的直接支持。在需要描述这些实体之间的关系时，我们常常需要创建一个关联表以记录这些数据之间的关联关系，而且这些关联表常常不用来记录除外键之外的其它数据。也就是说，这些关联表也仅仅是通过关系型数据库所已有的功能来模拟实体之间的关系。这种模拟导致了两个非常糟糕的结果：数据库需要通过关联表间接地维护实体间的关系，导致数据库的执行效能低下；同时关联表的数量急剧上升。

这种执行效能到底低下到什么程度呢？就以建立人和电影之间的投资关系为例。一个使用关联表的设计常常如下所示：

如果现在我们想要通过该关系找到一部电影的所有投资人，关系型数据库常常会执行哪些操作呢？首先，在关联表中执行一个Table Scan操作（假设没有得到索引支持），以找到所有film域的值与目标电影id相匹配的记录。接下来，通过这些记录中的person域所记录的Person的主键值来从Person表中找到相应的记录。如果记录较少，那么这步就会使用Clustered Index Seek操作（假设是使用该运算符）。整个操作的时间复杂度将变为O(nlogn)：

可以看到，通过关联表组织的关系在运行时的性能并不是很好。如果我们所需要操作的数据集包含了非常多的关系，而且主要是在对这些关系进行操作，那么可以想象到关系数据库的性能将变得有多差。

除了性能之外，关联表数量的管理也是一个非常让人头疼的问题。刚刚我们仅仅是举了一个具有四个实体的例子：人，电影，电视剧，影视公司。现实生活中的例子可不是这么简单。在一些场景下，我们常常需要对更多的实体进行建模，从而完整地描述某一领域内的关联关系。这种关联关系所涵盖的可能包含影视公司的控股关系，各控股公司之间复杂的持股关系以及各公司之间的借贷款情况及担保关系等，更可能是人之间的关系，人与各个品牌之间的代言关系，各个品牌与所属公司之间的关系等。

可以看到，在需要描述大量关系时，传统的关系型数据库已经不堪重负。它所能承担的是较多实体但是实体间关系略显简单的情况。而对于这种实体间关系非常复杂，常常需要在关系之中记录数据，而且大部分对数据的操作都与关系有关的情况，原生支持了关系的图形数据库才是正确的选择。它不仅仅可以为我们带来运行性能的提升，更可以大大提高系统开发效率，减少维护成本。

在一个图形数据库中，数据库的最主要组成主要有两种，结点集和连接结点的关系。结点集就是图中一系列结点的集合，比较接近于关系数据库中所最常使用的表。而关系则是图形数据库所特有的组成。因此对于一个习惯于使用关系型数据库开发的人而言，如何正确地理解关系则是正确使用图形数据库的关键。

注：这里的结点集是我自己的翻译。在Neo4J官方文档中，其被称为label。原文为：A label is a named graph construct that is used to group nodes into sets; all nodes labeled with the … 阅读全文