玩之前先明确一点：服务端叫repository, 客户端叫working copy ##创建repository 1. svnadmin create /home/kent/svntutorial ##创建working copy 2. mkdir /home/kent/svnclient cd /home/kent/svnclient svn checkout file:///home/kent/svntutorial/ ##进入创建一个叫作trunk的目录 3. cd svntutorial mkdir trunk ##创建一个文件并添加到svn repository 4. cd trunk vi 1st.txt ##创建一个本地文件 svn add 1st.txt ##加到svn svn status ##查看所有等待提交的文件 svn commit ##提交文件
http://en.wikipedia.org/wiki/Reverse_proxy Reverse Proxy(反向代理): 1. 它是一个Proxy：转发客户端的请求和服务端的响应 2. 为什么说Reverse? Forward Proxy一般是处在Client和Server之间，而Reverse Proxy则和Server放在一起，一般是同一个局域网内。比如apache httpd和tomcat就部署在一起。 作用：本质上来说，反向代理是一种“Indirection”。作为系统设计的核心理念之一，indirection可以起到很多种作用： 1. 安全： a.屏蔽Server的特性. 如果黑客不知道server是tomcat还是php,就无法采取专门针对特定服务器类型的攻击。 b.防火墙。Client无法直接访问Server，无法直接进行攻击。 2. 性能： a.一个Reverse Proxy下面可以挂多个Server，实现集群和load balancing. b.http协议相关的Cache. Apache httpd就很擅长这一点。 c.压缩response (不过很多Server自己也可以做这种事） d.替server分担一些请求，尤其是静态内容. httpd比tomcat处理静态内容的能力更高（原因不详) 3. 功能：可以干些URL重写之类的事情 4. 结构：对外提供唯一的服务入口，使proxy+多台server组成的系统在Internet上仍表现得像单台 a. 可以只用一个外部IP b. 可以只用一个域名，一个SSL证书 (如果你的域名本身可以对应多个IP，也不需要reverse proxy帮忙) 两个最流行的反向代理：Apache Httpd V.S. nginx (念作engine x) …
1. 解压tar.gz gunzip -c foo.tar.gz | tar xvf – 2. 压缩 tar -cvf hello.tar gello
自底向上地给出解决方案: 先看看现在有什么，再考虑怎么弄 1. 做方案之前先看看系统中对类似问题是否已有方案. 这个方案说不定你可以直接用，甚至不用再开发任何东西 2. 全面地了解你可能用到的子系统、模块，然后再去找相关的接口人；这不是为了评估对方所说是否正确，而是为了更好地倾向对方，避免自己产生似是而非的理解。
“你这个怎么做的？” “你们已经有这个接口了吗？” 不要轻信对方的回答。如果他没查代码，他给你的回答在一定概率上是不准确的。 你可以做的是： a. 问对方具体是哪个类里的哪个字段，自己校验一下。 b. 对于一个接口，既要问提供者，也要问当前的使用者；如果他们两个口风一致，可信度才高 不过，这过程中尽量不要让人觉得你不信任他。这需要技巧，这方面我还很弱。
做初步解决方案的时候，往往只能抓住关键性需求做出一些比较粗粒度的方案。粗糙不要紧，但仍然需要可靠，即满足可行性。要做到这一点，就必须在构思方案(time bound)时，头脑快速响应，迅速地在脑子里对自己的方案进行校验。 要想快速思考，就得掌握一些常用的系统分析的模式；当一个问题点出现时，你可以自然而然地想到从哪些方面来考虑。 不知道有没有这样的模式大全。我自己能想到的有这些： 1.不要漏掉关键的名词性领域模型。通过比较细致的Use Case可以避免这种遗漏。 2.名词性模型是可以按业务来分类的，你可以迅速定位某种模型的类别，然而快速考虑一下它的核心特征是否满足你的方案。四色原型提出了一种分类办法，但我完全看不懂。我目前能想到的有： a.某些东西是静态的物品，如商品 b.某些东西代表一个动态的过程，如订单；这时你应该考虑它的时间属性，它依赖的静态物品，和它的状态转换。 c. … 3.领域之间关系应该搞清楚，是1:1, 1:m还是m:n
如果一件事要三方一起沟通,惯常的作法是三方一起开会，这样效率比较高，因为说话人说一遍，就可以让其它两方同时知道（广播式）。 如果不这样而是采用点对点模式的话，A跟B说完之后，还得再跟C说一遍。 但有些经验表明,这并不是绝对的。有些“人”的因素，可能会使第二种模式效率更高。三方同时沟通在“人”的方面有一些缺点： 1. 三方碰头开会可能只允许有两三个小时的时间，因为这样往往会漏掉一些关键的东西，得出的解决方案很有可能会有可行性的问题。 2. 如果没有强势的主持人，三方沟通可能意味着七嘴八舌，会议无组织，效率反而更低 ３. 多数压倒少数效应。如果B和C意见一致，气场强大，则A可能会有点退缩，怕大家觉得自己笨而不敢乱发言。 4. 如果A和B,C并不平等， 则Ａ需要注意的礼节禁忌也会多一些 5. 以上缺点随着参与方的数目和每方人数的增加而增加。 在这种情况下，还不如换用点对点模式。按谁受益，谁主动的原则，让其中一个人来穿钻引线，不厌其烦地打扰其它各方： 1.其它人就像分时系统，一边回应，一边可以做自己的事；因此不会觉得时间有太大浪费。你也可以因此问的细一点，做出的方案更靠谱一点。 2.一对一模式下，你可以从容引导沟通的进程。因为只有你主动，别人都被动。 3.其它的一些人的因素也减轻了很多。 不过，你仍然要时不时地发一起阶段性的结论出来，发给所有人：to make sure all are on the same page, 这样可以弥补点对点沟通的一个缺点：无法当场取得所有人的一致。
project 2007 notes 1. 给定计划后，就要把它当作一个baseline，以后的追踪就是基于实际执行情况与baseline的比较 2. 追踪并调整计划 — 这时baseline怎么办？ Project 2007的作用： 1. 计划 a. 查看重大变更对项目的影响 b. 在取舍资源与进度时帮你做一些计算 c. 设置任务优先级 d. 找出critical path(关键路径) f. slack (摩擦损失时间) 2. 资源管理 3. Trackiing 4. Reports Project 2007中的工具： 1. Gantt chart 2. Network Diagram: 体现从一个任务到另一个任务的流动 3. Resource Grpah & …
我是看了这个PDF才明白的: http://pmpspecialists.com/WhitePapers/PMP_Specialists_Task_Types.pdf. 本贴里我再用自己的语言复述一下. Units, Duration, Work是什么? Units就是参与任务的"人力", 如果一个人100%干, Units就是１; 如果两个人各50%干,Units也是1 (2 * 50%) Duration就是任务完成所花的时间. 如果一个任务从周一干到周五, 那Duration就是5天 Work则是一段时间内所有人实际投入的"汗水",也就是"工作量". 如果两个人各100%一共干了5天,那Work就是10天. 简单地说, Work = Units * Duration Fixed Units, Fixed Duration, Fixed Work MS Project里的任务类型必定是Fixed Units, Fixed Duration, Fixed Work其中一种.那又分别是什么意思? 1. 先说一个最容易理解的, "十月怀胎"这种任务就是典型的Fixed Duration. 一个女人生一个孩子要10个月,十个女人只生一个孩子还是要10个月! 那投入十个女人后,上面几个参数会怎么变呢? a. 一个女人的时候, Work = Units * Duration = 1个月 * 10人 = 10 人月 b. 十个女人的时候, Work …
有句著名的话叫做"All problems in computer science can be solved by another level of indirection". 另有人(page-jones)研究过耦合(connascence)的种类,并提出 通过把某种耦合变成另一种耦合,可以减弱耦合的程度. 今天终于有机会使用这两个著名的东西了. 问题是这样的. 你的合作方比较强势, 不愿意按契约来设计. 你的系统想知道"这个流程执行完后,倒底谁拿到了标书? ", 对方告诉你, "我们不提供’谁拿到了标书’这个接口,你可以使用’竞标者是不是市委干部的儿子或女婿’这个接口,因为他们一旦竞标,合同肯定就是他们的" 而你又相信"人间或许还有点公义,现在他们能拿到,以后就未必了". 但前面说了,对方很强势,于是干脆不搭理你. 如果你按他们的意思来,那你们就没有严格地按照契约来定义接口: 他给你的东西不是你直接想要的东西,而是你想要的东西的背后的东西. 如果你直接依赖"竞标者是太子"这个接口,万一这玩意儿靠不住了,你就得改你的系统. 从Connascence的角度来说, 这里存在一个Connascence of Algorithm(算法耦合性), 你们两个系统之间的正确交互依赖于 "高干子弟必定拿标书" 这个脆弱的业务规则(算法). 那怎么解决这个问题? 既然对方不愿给真正的接口,那你就无法避免这个耦合; 但你仍要想办法减弱它对你的系统的影响; 也就是说, 算法被改变时,你的系统所做的修改要尽量小. 举例来说,如果你的系统中多处用到了这个接口,那一旦算法被改变,你的系统就有多处要改. 说到这里,解决方案已经呼之欲出了. 你要引入一个Adaptor作为indirection, 这个Adaptor在名义上提供你要的接口:"倒底是拿到了标书? ", 实现上它再依赖对方系统的"高干子弟拿标书"这个潜规则; 你的系统里要调用标书逻辑的地方都必须通过这个Adaptor, 而不能直接依赖对方的系统.如果对方改了这个逻辑,你只需要改你的Adapter这一个地方就可以了. 没错,耦合性还是存在,但你对未来的担扰至少少了些. 从Connascence的角度来说, 你是把耦合性 从"Connascence of Algorithm" 减弱为 "Connascence of name", …