第一组：姚成栋 UI模板中的树
- 要引用模板中的树只需要在html页面中加入
- 在js中加入
var apple_selected, tree, treedata_avm;
apple_selected = function (branch) {
$scope.searchPara.PTP_TrainBillName = branch.label;
getTheoryTrainList();
};
treedata_avm =
[
数据部分
];
$scope.my_data = treedata_avm;
$scope.my_tree = tree = {};
$scope.try_async_load = function () {
$scope.my_data = [];
$scope.doing_async = true;
return $timeout(function () {
$scope.my_data = treedata_avm;
$scope.doing_async = false;
return tree.expand_all();
}, 1000);
};
- 其样式大致如下：
第二组：叶佳意 《刺猬的优雅》
电影是从一个女孩的一段独白开始的。这段独白令人震惊。她决定在本学期结束，她13岁生日前死去。她说这话的时候带着严肃淡漠却又异常坚定的表情。
她的轻生之念并非因为生活窘迫或者穷途末路之类。相反地，她生活在巴黎的富人区，父亲是国会议员，过着衣食无忧的生活。可是大概也正是这样的生活，使她感到束缚。她说：生命在她看来就如金鱼，看似自由游弋，却始终被束缚在透明的鱼缸里。为了不困在这鱼缸里，她决定自杀。自杀前，她要拍一部电影。她深信，死亡是世界上最平常的一件事，但重要的是，你死的时候在做什么。
她是一个太过聪慧的十二岁女孩，聪慧到早早看透了人性。她有一双比成年人更清明的眼睛，透过浮华看见腐朽，透过平凡能看到一种睿智。她曾在某次家庭聚会上指出某位大人物的谬误。她说：“国际象棋和围棋不同，国际象棋就是想办法杀死对方，而围棋像人生一样，重要的是布局，我们要让自己活到最后，也要让我们的对手活到最后。”这样的话语，是不合适宜的。在大人眼里，她不是个讨人喜欢的孩子，甚至被认为是个不折不扣的小怪物。不爱说话，只爱喃喃自语地拿着摄影机到处拍摄。
她说：荷娜，你不是一个普通的门房。电影中另一个主要人物出场了。她是这栋高级住宅里的门房。没有人会注意到这个五十多岁不修边幅的矮胖门房太太荷娜。她其实并不是大家所看起来的那个样子。虽然她从来没上过学，但她密室里的满屋藏书早已填满她的灵魂。平人眼里庸俗的门房，却有着贵族般深邃的内心世界。
她独自坐在小房间里，一杯茶，一包黑巧克力，一只懒猫，满屋的书，我被这颗沉静的心打动。不是出身高贵，生活闲暇的人才有优雅的权利。也许一开始，我犯了个错误，优雅并不一定要属于天鹅，刺猬也可以有它的优雅。只是人们并不了解。就象人们不会了解到门房的内心有多美，不了解这个那么精灵的女孩对活着有那么多困惑。
我们活在一个重视表象的世界。这个世界刻板且不友善，充满偏见。在这样的世界，我们大概只能象刺猬那般竖起浑身的刺，建起坚不可摧的堡垒来保护自己柔软的心。直到某一天某人可以直抵你心。就是他，知道你不是别人看起来的那个样子。就是他，知道你的与众不同。就是你说：幸福的家庭都是相似的，他马上接口说：但不幸的家庭各有各的不幸。
此时，第三个重要人物登场了。日本来的小津先生，带着日本文化的细致精髓来到巴黎，也来到门房太太荷娜的内心世界。还记得有那么一场，她换了新妆，遇上同栋楼的有钱邻居。这位邻居很有礼貌地对她说：你好，太太。她对他说：她没有认出我。他望着她：因为她从来没有好好看过你。没错，只有你，才透过表面的沙砾，看到我内心钻石般的光芒。就因为此，即使我只是个门房，我也准备去爱了。一切掩饰，在懂你的人面前早已慢慢融化。虽然世界依然傲慢如故，但是心中已盈满能量。
忽地，怎么觉着有些熟悉之感。不正是小王子说的那样，重要的东西眼睛是看不到的。我们必须用心去体会，虽然这么说着其实有些悬乎，因为这实在没有什么可以具体化可操作的东西。也许这只是种感受，总有一些人在同一频率之上，我们可以感受得到彼此的好。心与心的交流，怕是这世上最美妙的事情了吧。是你在这里。呀，我也在这里的惊喜。
电影的结局没有那么完满。小女孩没有死，死的是荷娜，在猝不及防的车祸中。当幸福快要来临的时候，死亡却令人诧异的到来。死亡并不如小女孩想象中那般梦幻。死亡是最真实的东西。一切结束了，你看不到你爱的人，也看不到爱你的人。她的死对她是有所触动的。她不再有自杀的想法。
我们得好好活着，才有机会。我们得好好活着，才能使一切更有意义。
刺猬，看似懒散，其貌不扬，总是孤僻地生活在自我的世界，却也自有它的优雅。敏锐的洞察力和内心的丰富，是自己看世界的方式，你懂很好，你不懂也无谓。可以远离是非之所，有一个安身的小角落，静静地生活就好。孤独，却并不放弃追求幸福；不美，却拥有一颗善良的心；贫穷，却并不贫乏；沉静，却并不冷傲...这大概就是属于刺猬的优雅。
第三组：蔡永坚 设计模式-桥接模式
桥接模式的介绍
桥接模式即将抽象部分与实现部分脱耦，使它们可以独立变化。对于上面的问题中，抽象化也就是RemoteControl类，实现部分也就是On()、Off()、NextChannel()等这样的方法（即遥控器的实现），上面的设计中，抽象化和实现部分在一起，桥接模式的目的就是使两者分离，根据面向对象的封装变化的原则，我们可以把实现部分的变化（也就是遥控器功能的变化）封装到另外一个类中，这样的一个思路也就是桥接模式的实现，大家可以对照桥接模式的实现代码来解决我们的分析思路。
优点和缺点
介绍完桥接模式，让我们看看桥接模式具体哪些优缺点。
优点：
把抽象接口与其实现解耦。
抽象和实现可以独立扩展，不会影响到对方。
实现细节对客户透明，对用于隐藏了具体实现细节。
缺点： 增加了系统的复杂度
使用场景
我们再来看看桥接模式的使用场景，在以下情况下应当使用桥接模式：
如果一个系统需要在构件的抽象化角色和具体化角色之间添加更多的灵活性，避免在两个层次之间建立静态的联系。
设计要求实现化角色的任何改变不应当影响客户端，或者实现化角色的改变对客户端是完全透明的。
需要跨越多个平台的图形和窗口系统上。
一个类存在两个独立变化的维度，且两个维度都需要进行扩展。
第四组：张元一 get和post区别？
RFC7231里定义了HTTP方法的几个性质：
- Safe - 安全
这里的「安全」和通常理解的「安全」意义不同，如果一个方法的语义在本质上是「只读」的，那么这个方法就是安全的。客户端向服务端的资源发起的请求如果使用了是安全的方法，就不应该引起服务端任何的状态变化，因此也是无害的。 此RFC定义，GET, HEAD, OPTIONS 和 TRACE 这几个方法是安全的。
但是这个定义只是规范，并不能保证方法的实现也是安全的，服务端的实现可能会不符合方法语义，正如上文说过的使用GET修改用户信息的情况。
引入安全这个概念的目的是为了方便网络爬虫和缓存，以免调用或者缓存某些不安全方法时引起某些意外的后果。User Agent（浏览器）应该在执行安全和不安全方法时做出区分对待，并给用户以提示。 - Idempotent - 幂等
幂等的概念是指同一个请求方法执行多次和仅执行一次的效果完全相同。按照RFC规范，PUT，DELETE和安全方法都是幂等的。同样，这也仅仅是规范，服务端实现是否幂等是无法确保的。
引入幂等主要是为了处理同一个请求重复发送的情况，比如在请求响应前失去连接，如果方法是幂等的，就可以放心地重发一次请求。这也是浏览器在后退/刷新时遇到POST会给用户提示的原因：POST语义不是幂等的，重复请求可能会带来意想不到的后果。 - Cacheable - 可缓存性 顾名思义就是一个方法是否可以被缓存，此RFC里GET，HEAD和某些情况下的POST都是可缓存的，但是绝大多数的浏览器的实现里仅仅支持GET和HEAD。关于缓存的更多内容可以去看RFC7234。
在这三个特性里一直在强调同一个事情，那就是协议不等于实现：协议规定安全在实现里不一定安全，协议规定幂等在实现里不一定幂等，协议规定可缓存在实现里不一定可缓存。这其实就是上面那个作者提到的specification和implementation的关系。
语义之争
走到这一步，其实就明白了要理解这两个方法的区别，本质上是 「语义」的对比而不是「语法」的对比，是「Specification」的对比而不是「Implementation」的对比 。
关于这两种方法的语义，RFC7231里原文已经写得很好了：
The GET method requests transfer of a current selected representation for the target resource. GET is the primary mechanism of information retrieval and the focus of almost all performance optimizations. Hence, when people speak of retrieving some identifiable information via HTTP, they are generally referring to making a GET request.
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
The POST method requests that the target resource process the representation enclosed in the request according to the resource’s own specific semantics.
勉强渣翻一下，再加上点自己的理解：
GET的语义是请求获取指定的资源。GET方法是安全、幂等、可缓存的（除非有 Cache-ControlHeader的约束）,GET方法的报文主体没有任何语义。
POST的语义是根据请求负荷（报文主体）对指定的资源做出处理，具体的处理方式视资源类型而不同。POST不安全，不幂等，（大部分实现）不可缓存。为了针对其不可缓存性，有一系列的方法来进行优化，以后有机会再研究（FLAG已经立起）。
还是举一个通俗栗子吧，在微博这个场景里，GET的语义会被用在「看看我的Timeline上最新的20条微博」这样的场景，而POST的语义会被用在「发微博、评论、点赞」这样的场景中。
第五组：陈孚楠 赋值与引用
之前分享的问题以及问题的解决，其根本就在于当我们执行一个‘=’(等号)的操作时，此时这个操作的根本到底是我们以为的赋值，还是其实是引用呢？
继续拿之前的a1、a3作为例子来说：
这个时候会发现a1和a3的AA_Content的值都变成了“3”；对于Solution s1 = new Solution();这条语句，这条语句执行的动作是创建一个对象，我们都很明白，但是它确包含了四个步骤：
右边“new AffairAttentions”，表示以AffairAttentions类为模板，在堆空间中创建一个AffairAttentions类对象；
“()”，这对括号，永java里的话来说，就是在对象创建后，会立马调用AffairAttentions类的构造函数，由于没有给参数，所以会调用默认的无参构造。
左边的“AffairAttentions a1 ”创建了一个AffairAttentions类的引用变量，也就是说用来指向AffairAttentions对象的对象引用。这和C语言中的指针可以理解为一个意思。
“=”，这个等号操作符表示使对象引用a1指向刚创建的AffairAttentions对象。
所以，这条语句包含了两个实体：一个是对象引用变量，一个是对象本身。
而后面的“a3=a1”，其实就是把a1引用变量赋值给了a3，也就是a1与a3指向了同一片物理空间，或者说a1与a3都是这片空间的别名，改变了任意一个引用都是改变了这片空间的值，当然也就改变了另一个引用所显示出来的值。
这个逻辑可以延伸到函数的参数传递中，函数传参都是按值传递的。但是这个按值中的值到底是真正的值还是引用呢，是需要我们注意的。也就是在调用一个函数并给这个函数传递必要的参数的时候，我们传到函数里的值到底是真正的赋值还是函数外部变量的一个引用呢，我觉得这是值得我们注意的。