简单整理设计模式相关资料。
 第一，虽然网上有很多教程，但大都不得要领，导致设计模式看起来非常复杂，就个人而言，从毕业到现在，反复学习过不下10遍，但由于工作中使用场景有限，不久就又忘记了。所以计划整理出一个适合个人的学习or复习的教程。
 第二，设计模式，本来是渐进的演化，或者基于需求驱动的，而非静态的结构 也就是说应该是原有结构-》遇到xx问题-》演变成xx结构，最终演变成的xx结构，就是常见的设计模式，但实际开发过程中更为在乎的是“遇到xx问题”，将xx结构变成xx结构。所以需要学习时主动补全一些信息，否则虽然学会了绘制关系图，却不明白在应该那种场景下使用。
 第三，设计模式一样是”需求驱动“，出现了问题，解决问题时才会用，而不是为了套用xx而使用。而且如果有完整源代码，并且自己也懂，修改源代码依然是最优方式，设计模式本来是为了处理模块对接（比如跨系统对接，跨平台对接，找不到源代码等），或者是为了对未来的兼容进行的抽象化。而非增加代码复杂度的累赘（不要为了用而用）。

模板模式

说明

删远端分支报错remote refs do not exist或git: refusing to delete the current branch解决方法

git merge 的撤销

接口调用存在的问题

近期和p2p公司合作进行闲置资金的货币基金购买。
核心功能自然是原有的网上交易核心service层，之前的service层服务的是ctrl层，现在ctrl层变成了第三方接口，而非常规的网页的ctrl层，简单来说就是重写ctrl层，返回json而非网页。

微信公众号，支付宝服务号对接资料现在已经很多了。但当时资料很少的。
微信公众号是前辈开发的，我是进行二次开发。第一代开发主要集中在普通基金净值查询，不需要登录。后来微信提供了oauth2的认证，支持公众号提取到用户的更详细的信息，就可以通过公众号和用户账号建立绑定关系，从而实现用户查询资产，以及通过菜单中的网页链接登录h5形式的app，进行基金交易。

网站相关技术点简单说明

攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。 如下：其中Web A为存在CSRF漏洞的网站，Web B为攻击者构建的恶意网站，User C为Web A网站的合法用户

OAuth（Open Authorization，开放授权）是为用户资源的授权定义了一个安全、开放及简单的标准，第三方无需知道用户的账号及密码，就可获取到用户的授权信息。
OAuth在”客户端”与”服务提供商”之间，设置了一个授权层，”客户端”不能直接登录”服务提供商”，只能登录授权层，以此将用户与客户端区分开 来，”客户端”登录授权层是使用令牌（token），”客户端”登录授权层以后，”服务提供商”根据令牌的权限范围和有效期，向”客户端”开放用户储存的资料

SSO 仅仅是一种架构，一种设计，而 CAS 则是实现 SSO 的一种手段。两者是抽象与具体的关系。当然，除了 CAS 之外，实现 SSO 还有其他手段，比如简单的 cookie。
CAS （Central Authentication Service）中心授权服务，本身是一个开源协议，分为 1.0 版本和 2.0 版本。1.0 称为基础模式，2.0称为代理模式，适用于存在非 Web 应用之间的单点登录。本文只涉及 CAS 1.0，

基本认证与摘要认证用于在HTTP报文交互中，服务端确认客户端身份。

简介

Map操作

默认：向下取整。
正常情况下 int(5.5) 结果为5

快捷手册vim

参考博文:数据库01mysql常用操作速查

本科小作业，快速傅里叶变换
python3.2

启动停止服务和设置