Nightly Summary

[博 庞]

今天和许亚堃一起重新设计了文件存取的模块。

写了部分代码。

明天开始继续完成代码，并测试。

[Guoqing Cui]

今天

=========

使用Backbone.js来管理所有页面（客户端所有页面都包含在一个html里面（SPA），backbone.js主要用来对页面之间的route逻辑，数据更新后的页面更新进行状态控制）

 

今天commit的版本还有点小问题，明天回修复

 

明天

=========

明天晚上有事可能不能在电脑前面，不过白天会抽出时间把所有页面跳转的逻辑修好

 

发自 Windows 邮件

 

发件人: Felix Xu
发送时间: ‎2013‎年‎4‎月‎28‎日, ‎星期日 ‎1‎:‎30
收件人: Me Zhu

 

今天
=====
o 初步完成release脚本，主要工作是将开发分支上的变化通过patch的方式打到主分支并提交到sinaapp上
o 解决验证码自动化测试遇到的问题
o 和庞博一起讨论并制定了文件存取方式，见【文件存取】
o 更正Jenkins上的一些问题

明天
======
+ 撰写服务端接口说明，方便崔开发客户端
+ 继续和庞博实现文件存取

文件存取
========
以前没有比较统一简单的文件存取方式，统一是指开发人员调用统一以及在本地和Sinapp上数据库统一。目前将文件的存取放到Model层实现，并且使用Model的Behaviour机制来重用，使得所有的有文件关联的Model都能使用，而且不需要关注如何存取，只需要在Model中指定一下哪个field对应着一个文件即可。
文件的最终放置路径如下（在新浪App上，相对于domain的根，在本地，相对于/app/webroot/files）
/MODEL_NAME/FILENAME_SUFFIX/FILENAME.EXT
其中
MODEL_NAME                  Model的名字，如User, Inn, Guest等
FILENAME                          文件的名字，目前是uuid
FILENAME_SUFFIX          文件名的最后两个字母，取最好两个字母是因为单机产生的uuid前面几个字母都一样
EXT                                       文件的扩展名，是由文件的MIME-TYPE转换得来


On Apr 27, 2013, at 12:34 AM, Felix Xu <f...@bristep.com> wrote:

> 今天
> =====
>
> o 调整Jenkins，使每天晚上自动更新代码，并自动测试
> o 为需要输入验证码的页面提供了一个获得正确验证码的接口
> o 为配合有发送邮件的页面的测试需求，研究imap的库，由于发现该库不会影响功能的测试，并且PHP异步发送邮件工作量不小，决定暂缓异步发送邮件。
> o 配合庞博一起修正一些bug
> o 和志远一起搭建开发环境和自动化测试环境
>
> 明天
> =====
>
> + 配合庞博完成文件的统一存取接口
> + 为崔开发客户端提供更多的服务端接口
> + 自动Merge代码并发布到SinaApp

[博 庞]

今天把文件存取的几个函数写好了，试了下有些错误。

明天开始debug。

五一家里事情比较多，可能进度会慢点。

[Felix Xu]

悲剧啊，昨天2点左右开始断网，邮件发不出。这把人扫地出门的节奏太狠了。今天一大早起来到食堂去把网络偷偷地恢复了。幸好当年当了一段时间core网管，哈哈。
今天
=====
今天晚上去参加生日Party了，回来得比较晚，没有太多时间。主要思考了宾馆管理系统（后面简称front）与在线预订系统（后面简称cloud）的通信问题。
从通信机制和流程两个侧面来考虑。

通信机制
--------------

### 信号
前面尝试做了一个通信的接口zbus，主要目的是希望能有一个比较统一的接口来做Front与Cloud的通信。由于一些消息只能异步地发给Front，信号的机制就比较适合。如一个用户下了一个订单，只有Front在线且发起请求时才能获得这个信号以及信号的数据。信号的机制比较好扩展，是用字符串来作为信号标识的，所传的数据也是一个万能的对象，zbus的API是参照GLib的信号机制做的。当时只想实现这么个机制，Front到Cloud的信号也采用了和服务端类似的异步发送机制，即当调用emit时，信号被存在了一个队列里，只有在5秒一次的sync中才会将信号发给Cloud，而且，也是发到固定的URL上，这样做有以下问题
* 本来请求由Front向Cloud发起，没有必要5秒才能发一次，可以在有需要通知Cloud的时候，立即发送
* Cloud上的处理被限制在一个固定的URL上，对Cakephp来说，也就是一个固定的Controller，如果处理逻辑都放在这个Controller里，随着逻辑的增加，势必造成这个Controller的臃肿，也不利于复用
针对上面的问题，对zbus提出以下目标
+ Cloud到Front的信号是延迟发送的，正常情况下，每隔一段时间，Front才能收到，且要保证信号已经被Front处理过了（忽略也是一种处理），不会因为Front拿走了信号，因为某些原因（比如掉电）却没有处理而再也收到这个信号了
+ Front离线情况下，仍然可以向Front发送信号
+ 信号是按创建顺序发送的
+ 可以将一个信号与多个处理函数相连
+ Front到Cloud的信号是即时发送的，且可以将信号连接到不同的Controller上的Method处理
+ 信号发送失败后，要保存到一个持久化的队列中，定时尝试重新发送（网络故障时的恢复）
+ 保持接口的简单


### 拉取
当Front需要一些数据些，可以直接拉取数据，目前想法是直接通过RESTful的API来拉取，如拉取所有房型数据。


Front流程
--------------

### 登录

1. 认证
打开宾馆管理系统的第一步是登录。
在网络正常的情况下，使用在线认证，并且缓存密码（需要做HASH）。
在网络不正常的情况下，使用缓存密码验证，类似于Windows的域在离线情况下的认证。

2. 第一次登录
如果是第一次登录，应该主动向Cloud拉取房型、订单、价格等数据，并且保存在本地。

3. 启动
启动zbus，zbus启动后，会先发送持久队列里信号（需要考虑数据的一致性问题），然后开始正常的信号处理（类似有一个MainLoop）。

### 处理信号

zbus启动后，信号机制开始运作，这时，如果宾馆的房间或订单有任何变化，都会接收到信号，并且做相应的处理。信号与处理函数之间是通过zbus连接起来的。

### 发送信号

当Front发生了变化，并且需要通知Cloud，则发送一条信号。如添加了一个住房预订，需要向Cloud汇报什么房型、什么时间被占用了。信号发送的目的地，是信号连接时决定的。


明天
==========
新的zbus，会在明天实现。这个机制比较重要，我一个人可能会有考虑不周的地方，最好有多个人一起参与制定。

[博 庞]

今天完成了本地文件存储和读取的behavior。

新浪app端的存取尚未验证。

接下来完成文件删除的函数以替代filemanger。

[Felix Xu]

今天
======

o 和崔一起制定Cloud和Front的机制ZBus
o 研究IndexedDB，部分实现了新的ZBus机制

明天
=======

+ 完整实现ZBus
+ 调整Cloud上宾馆的一些页面，以加载到Front上

[Felix Xu]

今天
=====
o 使用IndexedDB实现了ZBus的接口
o 学习了Backbone.JS

明天
====
+ 尝试将ZBus与Backbone.JS的事件机制整合，不在代码里存在两种风格的东西
+ 完成Front的基本功能：登录及加载房型。

[博 庞]

这两天事情比较多,今天完成了文件删除的模块,roomphoto测试正常.

明天把其他几个controller的文件操作也做相应的修改.

[Felix Xu]

嗯，玩儿的时候就要尽情玩儿哈^_^

On May 2, 2013, at 12:17 AM, 杨浩 <cas...@bristep.com> wrote:

抱歉，这两天工作量较少，不是很方便上网，只是文字上设计了管理端和宾馆部分的测试case，争取回来后赶上进度。

实在不好意思。

杨浩

Go to group website 
Remove me from the group mailing list

[Felix Xu]

今天

=====

o Front登录实现

需要进一步与界面整合，例如登录失败的处理，错误信息，离线登录。

o Front端信号机制实现，已经加入了IndexedDB来保证信号不会因为离线而丢失，以离线订单和在线订单提交作为示例

信号使用了两个Backbone.JS中的Collections，分别是inbox和outbox，目前是将它们放在app中的。需要和崔交流如何布局这些变量。

Front => Cloud：的add方法，规范如下：

outbox.add({

'name': 'ControllerName:SignalName',

'data': object

});

Cloud => Front: 主要是连接信号与处理函数，规范如下：

this.listenTo(inbox, SignalName, callback)

SignalName是由服务端产生的，命名的规范是全部小写，使用连接符-而不是下划线隔单词，类似glib里的信号名。

o Front拉取数据，以RoomType作为示例，是直接使用的Backbone.JS里的Collection机制。

o Front的一些规范，我只总结了我今天用到的几点，咱们商量着定：

# js文件

1. 文件名全部小写，单词之间用连接线分隔，不使用下划线

2. 一个对象的Model，Collection放一起，由于我还没有写过View，不过建议View也放一起。拿订单来说，类Order, Orders，OrderView放在一个叫order.js的文件里，纵向归并，比较清晰，不知道崔同意吗？

# js代码规范

1. 变量和函数统一使用小驼峰式，jQuery和Backbone都使用的小驼峰式命名，如var newOrder; function updateMessage();

2. 类名使用大驼峰式，如OrderView，Signal

3. event的处理函数使用前缀on，如this.on('add', this.onAdd);

4. 脚本里使用单引号引住字符串，除非特殊情况（例如字符串里这么多单引号）

# html

1. 属性使用双引号

2. 所有元素必须关闭，虽然HTML5并不强制规定，但是关闭可以帮助一些编辑器的缩进和增强代码美观

3. 元素id中不使用下划线，使用连接符

4. 所有的js放到js文件中（Chrome app好像不支持在HTML中直接放js代码哦）

已经放到in.zhu.me/工作区/ 技术相关/代码规范

明天

=====

+ 配合崔完成登录的所有逻辑

+ 配合崔完成房型在界面上的呈现

[Felix Xu]

今天（4.5小时）
============
o 和大家一起制定了第一个迭代的计划
o 和崔一起初步讨论了界面的实现问题
1. 如何显示房型
2. 如何显示订单
o 解决了离线登录数据的存储问题

明天
=============
+ 完整实现登录
+ 和崔一起整理Front代码
+ 制定好界面的规划

[Felix Xu]

大家以后写summary，请注明当天工作的小时数。主要是给后面制定开发计划提供时间上的参考，同时也有助于发现问题的瓶颈在哪里。

Sent from my phone

[Guoqing Cui]

今天（4.5小时）

======

1.安装本地的测试环境

2.和方方讨论front界面的实现问题，并进行测试

 

明天

======

1. 完成登陆错误提示

2. 确定界面的规划

3. 整理front代码 

 

发自 Windows 邮件

 

发件人: Felix Xu
发送时间: ‎2013‎年‎5‎月‎3‎日, ‎星期五 ‎1‎:‎47
收件人: Me Zhu

 

--
您收到此邮件是因为您订阅了 Google 网上论坛的“zhume”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 zhume+un...@googlegroups.com。
要查看更多选项，请访问 https://groups.google.com/groups/opt_out。

[博 庞]

昨天晚上忘发了。

昨天4小时，主要完成了

1. InnPhoto模块的文件操作

2. Inn模块的文件操作碰到点问题。

3. 分了几个user story。

今天继续解决Inn模块文件存储的问题，争取完成第一个user story——后台提供房型的数据

[博 庞]

一直在外头刚回来，今天白天花了3，4个小时时间尝试解决inns模块的问题没有成功。

明天继续研究下文档找解决方法并完成第一个user story

发自我的 iPhone

[Guoqing Cui]

今天（21:00-24:00 3小时）
========

1. 和方方一起确定首页的布局，并根据最终的Tab+Calendar的方案做了demo方案
2. 整理删去代码中没有用的文件


明天
========
1. 完成登录出错处理
2. 对首页布局进行微调确定最终方案并实现，并对边栏进行细化

> Subject: Nightly Summary
> From: da...@bristep.com
> Date: Sat, 4 May 2013 00:02:39 +0800
> To: zh...@googlegroups.com

>
> 一直在外头刚回来，今天白天花了3，4个小时时间尝试解决inns模块的问题没有成功。
>
> 明天继续研究下文档找解决方法并完成第一个user story
>
> 发自我的 iPhone
>

[Felix Xu]

今天(4.5h 20:30-01:00)
==================
o Front页面确定
o 登录错误处理
HTTP状态为401，内容为JSON字符串
o 和崔整理代码
o 进一步熟悉了Backbone里的同步机制
o 离线认证机制确定
Ajax请求为error，且错误为404，切换到离线认证模式

明天
=========
+ 协助庞博完成文件接口
+ 实现离线认证
+ 和崔协同完成日历

[博 庞]

今天10点-12点，19点半-23点。4.5小时在许亚堃的帮助下解决了json格式以及Inn模块文件存储的问题。

明天视进度完成user story。

[Felix Xu]

今天（5.5h 10:00-11:30 21:00-01:00）
=============================
o 协助庞博完成了文件存取接口，意识到了高速网络在我们以后工作中的重要性，另外遇到Cakephp的一些特性
! 可以使用$this->RequestHandler->renderAs('json')来输出json的结果
! 可以通过iframe.contentDocument.body.innerText获得iframe里的内容
o 实现了离线登录，有以下收获
! indexedDB里put一个object会更新整个object内容
! 可以使用String(object)将一个javascript对象转换为字符串

明天
======
+ 调整服务端关于房型和房间的数据库结构，以适应新的逻辑
+ 配合崔完成Front上日历以及相应的功能

[Guoqing Cui]

昨天 （18:00-22:00)
=======
1. 对FullCalendar的代码进行定制，使它能够满足front的要求
2. 熟悉indexdb

今天
=====
1. 根据需求完成日历的定制
2. 完成前后台数据交换的功能

这两天白天要学车，可能联系不上，下午回来之后都会在线上：）

Regards,
Guoqing

[博 庞]

今天10-11点，14-16点，完成了服务端房型数据的提供。

明天完成其他的user story。

[Felix Xu]

今天（2h 23:00-01:10）
====================
今天忙了一天房子的事情，现在还没有定下来，真是麻烦啊。
o 考察了当前数据库里关于房型和房间的设计，有以下问题：
* 房间没有存电话号码
* 房间是与房型绑定，这样，当房型发增删时，房间就没了，考虑将二者分离，让房间直接关联到宾馆，房型仅作为它的一个属性
* 房锁(Hold)与房间和房型的id关联，删除房间或房型时，未判断是否有房锁与之关联
已经在本地做了更新，由于是增加了些字段，与以前的逻辑基本上是兼容的，附件是数据库的更新，请使用mysql -uzhume -pzhume zhume < zhume-update-1.sql来更新你的数据库。代码无需太多修改。

o 研究了一下indexedDB的index，需要进一步试验才能确认订单的本地存储。

明天
=====
+ Demo并制定下一个sprint的User Story
+ 设计订单的本地存储方案
+ 和崔一起把房型放在日历上

[博 庞]

今天主要是回顾了一下FileBehavior的代码。主要还有以下两个问题：

1. 错误的处理

2. 新浪app端的验证

明天研究下cakephp里的错误处理。

[Guoqing Cui]

今天

======

1. 根据讨论修改calendar

2.完成登录出错提示

明天

======

1.完成房型获取

2.设计离线订单流程

Regards,

Guoqing

--

[Felix Xu]

今天（3h 22:00 - 01:00）
===================
o 和崔、庞博总结了上一个迭代，切分了下一个周期的任务
o 和崔、庞博一起讨论了日历的格子设计
o 思考了离线订单的一些字段：
离线订单
Order {
/*创建*/
created：创建时间，本地主键
roomType: 房型名
room: [name, 房间名]
cost：总价
till: 保留到的时间
start: 开始时间
end: 结束时间
who: 联系人
mobile: 手机
payMode: 支付方式
remark: 备注
state: 状态
/*同步*/
id：云端主键
/*入住*/
guests: [{cid,name},{身份证,姓名}]
checkedIn: 入住时间
/*退房*/
checkedOut：退房时间
}
其它一些字段如评论、评价会直接推送给server

明天
==========
+ 实现离线订单的本地存储
+ 实现离线订单与远程同步
+ 提供改变离线订单状态的接口