本章谈谈MySQL的备份和还原，外加一点点复制。

其中所谓的复制跟备份有点关系，因此放在这里记录下来，另一部分复制跟主、从库有关系，未来打算放进MySQL架构部分去记录，在本博看来主、从库不仅是架构级别，并且需要适当监控，因此独立一章，具体阐述。

备份和还原其实也是比较复杂的，譬如备份时不要影响生产环境的业务进行，还原时同时也应注意这点。

Read More

MySQL数据库权限严格来说并非属于优化范畴，为了保持系列严谨，姑且就这么分配吧。

权限部分包括两大部分，第一：授权认证，即账号密码，可访问来源。 第二： 访问控制，库、表、字段、存储过程及函数的各种粒度的不同操作，例如增、删、改之类。

Read More

本博源码更新了些文件，主要如下
-修复几个URL，使用url_for 函数生成，主要是后台地址改了下，防止脚本猜测
-增加评论功能，最简单，无回复
-增加rss feed
-修改若干样式

经过一段时间的折腾，成功基本完成了基于Flask这个Python的微型框架搭建的博客。本博成功升级。

期间本博经历了各种技术的考验，当然也考虑的不少因素，到底什么语言，什么框架，做成什么样子，什么功能，走了很多弯路，各种心酸待本博娓娓道来。

Read More

准备写Java语法方面的各种知识点的理解，因此，参照 Java 核心技术上下两册，进行精读，从而整理出各个知识点，同时在本博中记录下亲测的结果，达到记忆的目的。

以下是两本书的豆瓣传送门，页面中有各种购买链接。

JAVA核心技术卷1

JAVA核心技术卷2

知识点 : Java方法的参数传递是基于值传递的

先看一下一个比较迷惑人的示例

//定义一个测试类，属性x，get set 方法， 初始值是 String类  "init"
class Sample {
    private String x;
    public Sample() {
        this.x = "init";
    }
    public String getX() {
        return this.x;
    }
    public void setX(String x) {
        this.x = x;
    }
}
//测试类
public class FuncParamDemo {
    public static void main(String[] args) {
        Sample sampleA = new Sample();
        System.out.println(sampleA.getX());
        FuncParamDemo.changeSample(sampleA);
        System.out.println(sampleA.getX());
    }
    public static void changeSample(Sample s) {
        s.setX("SampleA is changed...");
    }
}
//输出
init
SampleA is changed...

在测试类中定义一个改变参数内容的方法 ， changeSample(Sample s), 传入sample 对象， 改变属性x。
传入前是初始值，执行方法后,sampleA 的属性被改变了。
注意，这里还是值传递！！
sampleA 有两部分组成，指针 和 对象 ，sampleA 这个指针被拷贝了， 变成 s， 因此， sampleA 和 s 是2个不同的指针，但是指向了同一个对象， 因此， 对象的属性x在执行完测试方法后被改变了。
因此，这里说的值传递，是对于指针（引用来说的）

第二个例子

//在测试类FuncParamDemo 中增加方法，进行一个对象互换的操作
public static void exchangeObj(Sample samplex, Sample sampley) {
    Sample temp = new Sample();
    temp = samplex;
    samplex = sampley;
    sampley = temp;
    System.out.println("Samplex now is " + samplex.getX());
    System.out.println("Sampley now is " + sampley.getX());
}

//测试类中main方法修改为
public static void main(String[] args) {
    Sample sampleA = new Sample();
    Sample sampleB = new Sample();

    sampleA.setX("Sample A");
    sampleB.setX("Sample B");
    System.out.println("sampleA is " + sampleA.getX());
    System.out.println("sampleB is " + sampleB.getX());

    FuncParamDemo.exchangeObj(sampleA, sampleB);

    System.out.println("sampleA now is " + sampleA.getX());
    System.out.println("sampleB now is " + sampleB.getX());
}
//输出
sampleA is Sample A
sampleB is Sample B

Samplex now is Sample B
Sampley now is Sample A

sampleA now is Sample A
sampleB now is Sample B

初始时 sampleA.x 为 Sample A, sampleB.x 为 Sample B
方法内部被2个对象互换成功。
最后打印sampleA.x sampleB.x为原来的值
因此，肯定不是引用传递，不然最后一步就不会那么打印了。
所以第一个例子的结论是正确的。

在IT行业将近工作了有10年左右时间，接触过不少产品。有硬件的，台式机，笔记本，各类Pad等。有软件的，Win平台，Mac的，Linux的。Pad和移动端的各类App。各种功能，各种界面。甚至自己做的很多系统，应用之类的。有时候也会进行或深入或浅薄的思考，产品层面，内部代码层面，甚至并不是很敢兴趣的市场层面，一直想记录下些东西，说说自己的体会之类。

自从苹果公司的产品出来之后，一瞬间大家好像对产品，用户体验等概念有了新的认识。特别是移动互联的兴起后，到处都是产品经理的身影，以前做Web应用的时候，似乎做产品的已经被列在了设计阶段，而现在，产品的地位提升了很多，这里有很多客观因素也是存在的。

先说说行业内对产品的定义，因本人从事的是互联网行业，目前也连带移动互联，主要从事Android开发中，因此所论述的产品涵盖了这2个领域，也可以说是小小心得。为什么说产品的地位提升很多呢？很多时候做产品的和后端的码农可以说是存在非常多的矛盾，但是又是互相依赖的，譬如假设一个做互联网产品的不知道HTML， CSS， 那是可以肯定的说做出来的原型图是非常脱离现实的，而且这也是非常基础的部分，如果说到用户体验，不懂前端，如果设计出好产品呢？

认识产品、开发

当然前提也尤为重要，产品经理必须非常清楚和了解产品的概貌，不仅从产品本身来说，更要从产品所附属的整个行业的一个大方向来说。这对产品经理的要求是非常高的，因为接下来需要做的事情，就要将这个宏伟的产品分阶段，也就是产品层面的战略了，我的理解是设计迭代中的每一环。要知道做互联网，或者移动互联的产品，必须是要有非常宏大的目标，想象非常庞大的用户量要使用这个产品，导致了各种各样的用户，包含各种各样的用户习惯去做，这些个阶段中，每个阶段的目标不仅仅是产品的提升，更是培养用户的方式，而且也配合到整个产品所属公司的战略。

因此做产品，必须清楚目标，并且能为目标做出妥善的计划，即是所谓的里程碑。 从大方向来说，产品经理确实是非常苦难的一个角色，但同时也是一个强悍的角色，因为要懂那么多东西，确实很牛叉。

相对来说，产品涉及的“面”上的东西较多，以上是从产品的更新迭代来说的，那么来说说产品本身的细节问题，目前很多产品，公司，包括独立开发者，都崇尚简单。我想从两个角度来看这个东西。

第一、产品中的流程。任何产品的使用，都逃不过流程，注册需要流程，用户购买需要流程，用户发信息需要流程等等。如何将复杂的流程做简单了，那就是说产品设计是成功了，并且从用户角度来说，不但流程简单，而且，当面对高级用户时，也能及时提供这类用户的特殊需求，也必须将复杂的一面交给这类用户自己定制。
第二、产品中的界面。大部分产品都是有UI的，UI如何操作合理，高效，不让用户反感的情况下，培养用户等等，这些都是需要UI来做的，那么懂一些Web的控件，App的控件， widget， Desktop App 的控件，组件之类的，是非常有必要了。

但是，基本控件，其实人人都知道，这个无法满足用户需求的，那么这个时候开发必须要登场了。

开发人员，典型的工程师思维，不管前端如何简单，但是，开发人员必须非常了解每个细节，因为开发人员必须要做实现。每一项 特性，每一个 功能 背后可能有好多层好多种关系交织在一起，必须去了解、规划、整理出其中的细节，才能实现前端简单的功能。所以，简单和复杂其实是共同体，在这个共同体中，开发人员应该是担当了基石的作用。如果说产品可以做到前端的功能表达，而具体业务逻辑是由开发来做的话，那么我想这之间还必须要有程序设计人员作为桥梁。

程序设计也是非常tough的工作，也是包含各种需要考量的东西，个人觉得架构师这个职位可以说是程序设计中的总设计。虽说产品已经从需求那里提炼出了UI和各种idea，但是正如产品的局限性来看，无法看到产品背后的实现，因此，架构师还是需要不停的和需求、产品做沟通，同时要考虑到开发实现，毕竟是全局工程啊。

那么这个时候，架构在必须游走在复杂与简单之间，来回推导，进行抽象。

设计产品、开发产品

需求，产品，架构，开发这些都是很重要很费神事情，有很多方法可以作为推进项目的方式，甚至还有配套的工具来加强效果、弥补不足。

本人最为推崇的是迭代开发，好处是目标清晰，并且一旦全身心投入进去，产品的进度应该无需担心，本人平时在开发中，也会碰到这种情况，只要是想好了，特别是每个Mile stone，非常清晰的知道要开发什么，需求边界是什么，设计原型是什么，这些细节把握清楚之后，跟着功能走，一般都会在很快的时间内完成，而不用刻意去计算项目花费时间。

其实整个开发过程就是一个从简单到复杂，再从复杂到简单的多个过程。从最简单的原始需求慢慢挖掘出细节，通过对细节的揣摩，进行各个层面的抽象，这里不得不提UML， 真是个好东西，有描述功能的用例图，描述静态结构的类图、包图、构建图等，有行为的时序、活动、状态等。抽象出来后，开始搭建软件架构，各种超类，接口的编写，又是来回推导，很有意思的是，这些动作也是从简单到复杂，再从复杂到简单。还真是你中有我，我中有你啊。

当然从前端来看，那应该就是极尽简单，有这么复杂的后台逻辑做支持，产品才可以放心的去构建。 当然其中也有测试之类的，也很重要，简单与复杂在测试中也是存在的。

那么，这么看来，每当产品经理看着简单明了的产品，能想到后端复杂的逻辑，每当设计开发看着大片大片的代码，想到前端优雅的操作。这个时候才真是感到Team的强大，生活的和谐内。。。

一直以来，都在使用MySQL这一开源数据库，也进行了深入研究，从开发角度讲，很多时候只是作为数据的持久存储，并不涉及过多的功能，而是根据不同的场景需求，来使用MySQL的各种特性，因此比较多的心得和笔记都是偏重于管理部分。

目前所做的一系列笔记基于两本书籍，一本是 MySQL性能调优与架构设计 , 另外一本是 高性能MySQL 。相信都是大家所熟悉的两本好书。因此整理了一些心得，根据几个议题，列了出来，一是作为读书笔记，另一面是在未来使用和再学习过程中进行比对，修复错误的，温习原有的，发现新的。

Read More

2014已经悄悄来临了，稍微总结了一下2013年的经历，各种遭遇，各种坎坷。有好的也有不好的，十分之复杂。

生活部分还是很满意，家里又添个娃，这次是男孩，意料之外，导致之前买的很多都是粉色系的女孩装都无法使用，因此需要再多买点男孩的装备，这样才能避免旁人误会。

工作部分非常坎坷，12年从Moker出来后来到某创业公司，环境尚可，某些benifit在入职之后未能兑现，非常之郁闷，导致本来家庭所制定的计划无法推进，无奈离开，虽最后补回损失，但时机已过。。。

Read More

作为一名软件开发人员，特别是服务器端开发来说，要关注方方面面的事情，但是并不是说其他类型的开发人员，例如客户端的开发，这类关注的事情会少许多，不！同样有很多很多事情需要操心。

这些事情促成了一个系统一套软件的形成，从最初的需求、概要设计、详细设、编码、测试一直到交付、验收。每个环节都需要关注，对于这样的流程，有很多方式去完成，大的不去说了，包含的东西实在太多，无法方方面面的去评述。最近思考了许多东西，想要好好整理一下，先笼统的从开发人员的角度来看，从最源头开始考虑起来，比如需求。

需求的定义，已经很明确了，三个层次： 业务需求 、 用户需求 、 功能需求 。

a) 业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。

我理解的业务需求，应该是站在比较高的高度上去描述的，可以用几句话来描述系统的Why 和What。例如本人参与过的几个项目，非常笼统的描述，某区人事管理系统，或者OA 管理系统，解决本行政区某管理部门的人事管理，或者解决办公无纸化、系统化。典型的提纲挈领，这里的Why就是要解决的问题，是Vision。 What是需要开发的系统，也可以说是Scope。这两点可以使用很多方式描述，基本的方法就是画大饼，做个什么PPT，Chart之类的，可以很好的描述出来，大致的方向和任务也已经明晰了，所谓的Aim已经有了，从这里画条线到Aim，就是主线，初步的问题解决。

b) 用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。

这部分的定义也很明确，如果有这么一个系统，那使用者们能干些什么呢？各种角色或者各种OBJECT，都能做什么事情，完成什么任务，用起来是怎么样的，看起来是怎么样的。听起来好像是产品经理干的活，也可以做点PPT或者Chart，来描述系统的UI，流程，Feature等等。这部分要收集，要思考。再说几个本人经历的，Ecommerce 的网站和企业内部的系统结合的故事，这里面，由于行业的特点，有很多需要收集和询问的需求。

c) 功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

这个以本人的经历来说，主要是从开发者的角度去看，提取模块、模块中的业务模型，这些业务模型的相互作用等。这类东西相对来说标准化的很多，看看那些开源项目就可以有一个很清楚的蓝图。解决一个数据库ORM 问题，可以有很多库去参考，一堆的Feature List，就是功能需求。因此功能需求是基于用户需求而来的。

了解了这些定义，还不是最主要的，主要问题是如何获得这些需求，使用什么方法，使用什么工具，如何展示得更清晰。

• 文档，这个是必不可少的，文字描述，定义一些，描述一些，结构一定要清晰，分类分层是个好办法，容易记忆，也更直观。使用业务和用户需求。

• 使用UML从几个层面去描述业务逻辑，动态的静态的，做成chart，仔细研究，使用于开发需求。

• Prototype，好多软件Axure， Pencil等，直接画出来。

以上是工具，具体如何做，慢慢学习，改进，再学习，再改进。这个就是方法层面上的，本人特别喜欢的迭代，话说迭代可以用在开发上，亦可以用在需求挖掘上，每一次的Review挖掘更多需求， 用工具记录下来，用文档描述出来，用图片画出来。

另外一个就是脑图，发散性的去思考，获取更多隐藏需求。

工具和方法都是必要的，原始的材料在这个阶段获取，尽量在已定的scope内将需求尽最大可能全面和精细。注意scope，避免无限制的变化，不要跌倒焦油坑里面。

“需求”这个词本身也包含了2个方面，“需” 意味着要求的事物，我们要什么，“求” 意味着要求，我们需要的东西要达到某种程度。本人喜欢纵横比较，需求列表一要在横向上列出不同的任务需要，纵向上要明确写出任务的程度。

注意，在需求阶段，最好分清楚需求的种类，到底是业务的，用户的还是开发的，虽说可能描述的是同一个事情，但是在不同层面，表现的形式会不一样，很有可能造成团队中对问题认识的分化，在本人的项目管理经历中，出现过类似的问题，解决的问题是对于不同的人，不同的角色，以不同的形式阐述问题，对业务来说，使用原型具象化。对开发来说，抽象化，以开发特有的工具和形式来表现。

以上只是本人工作中碰到问题后总结出来的，当然，问题天天多，在慢慢的一个一个解决的同时，也停下来思考过，学习过，通过这种方式，再结合实际，发现效果也非常明显，简单来说，能够提高效率的事情，能够提高效率的工具，一定要去做，一定要去用。

If you want to see the diagram of XHProf . You should install Graphviz . Here is the link http://www.graphviz.org/.

Just download the lastest version source code. Then

./config --with-png=yes
make && make install

But before this. Make sure you have install the zlib and libpng : )