2016.1.12 晴 有风无霾
今天工作的开始，本来是计划将数据库设计的工作做个总结，把产品设计的工作进行一个收尾，大概今天的工作不应该太忙，但是，事情往往都有一个但是！！！
上午进行了模板选型，在themeforest上找了半天相关的模板，和外包团队讨论模板设计及对之前的需求进行细化的工作；接下来就是功能性需求了，考虑到需要统一认证入口，便开始讨论的工作用户表结构的问题，原计划用户和商户的两个表是独立的，经过一段时间的验证，发现这两个表有90%的相同字段，于是开始整合，细化，细化整合，就这样，一个大傻冒在在不停地打磨着那破烂产品，啊哈哈哈，有痛但也幸福着。
关于认证问题，我访问了支付宝；支付宝似乎有无数个登录入口，有商户、用户以及第三方等等，而且在输入框中已经显示了可以使用淘宝用户名登录，下面还给出了一个淘宝登录的URL，这是怎么样一种神经病行为？
明天继续数据库、需求设计。工作就是提出问题解决问题的过程，但现在的问题怎么这么多呢？
在这里感谢一下帮助过我的小伙伴们，虽然现在还不能公布他们的姓名，但愿未来有机会可以公布出来或者给你们一些补偿。
2016年1月12日星期二
2016年1月11日星期一
2016年1月10日星期日
产品设计 day4 2016.01.10
2016.1.10 晴 有风无霾
今天的信息量较大，本来是没什么精力写总结了，但是还是耐着性子写一篇吧，为了不破坏这个总结的习惯。
今天写完商户系统的描述，应该到最后的管理中心了，这基本上是前面几套系统的综合管理中心，关于网站管理后台的设计，对于数据的增删改查基本都在这个系统里实现，我参考了很多优秀的产品，例如比较流行的wordpress架构以及国内的discuzx，主要是数据库设计相关的，因为我对他们的定值管理还是比较感兴趣，随即发现了以下优秀的文章： wordpress源码解析-目录结构-文件调用关系、wordpress源码解析-数据库表结构（2）、wordpress源代码研究-前台运行流程、WordPress工作原理之程序文件执行顺序（传说中的架构源码分析）、技术角度wordpress结构优缺点分析、对我比较有用的可能是最后这篇WordPress数据结构分析以及研究了一下宽表和窄表在数据库中的设计宽表和窄表的建设该如何选择？，还有关于lvs负载的一些知识 LVS负载均衡，主要源自于一本叫做《淘宝技术这十年》的应该算是网站架构方面的书籍，但是里面的废话较多，主要是摆了一些人名，说了一些淘宝创造的数据以及过往用过的方法、架构等，跳跃式的看了看，前面一部分基本是大家都知道的一些知识，没什么特别，未来如果有，我再补充。
管理中心的系统设计进度截至到现在完成了25%左右吧，大概有2-3个数据库表是设计完成的，还有很多表以及很多的字段需要填充内容，还有很多很多需要学习的地方，当然，在这里我想表达的是，在学习的过程中其实感觉是最慢的，也并没有什么具体的收获，对产出大概价值也不是太高，所以，时间上的浪费对于我今天的工作满意度来说还是比较不太舒服，大概工作时间有占全天时间的45%左右？其他时间在学习和偷懒。这点是完全需要被克服的。
PS1,关于未来办公室的问题，现在在考虑寻找一些孵化器，但时间上也不是太够用，应该怎么办！？
PS2,关于产品名，现在还没有定论，如果有一个像阿里“阿珂”那样会起名的姑娘在就好了。
PS3,今天因为要搭建一个WP环境，需要一个云环境，所以体验了一下vultr的vps，效果…，怎么说呢，速度还可以，但总是感觉系统不太干净？
PS4,对于国内的云主机也有了一些了解，主要都是在以打折或者免费的形式吸引客户，在此夸赞一下亚马逊的EC2，人家基本是认证后便免费一年的状态，中文支持方面大概有70%左右的内容现在可以是中文环境了。
PS5,今天也认识了一些在坚持写技术blog的朋友，具体我就不点名了，因为感觉太忙了，记忆内存实在不够用，可以看一下这里，内容不错，人也非常热心。
今天的信息量较大，本来是没什么精力写总结了，但是还是耐着性子写一篇吧，为了不破坏这个总结的习惯。
今天写完商户系统的描述，应该到最后的管理中心了，这基本上是前面几套系统的综合管理中心，关于网站管理后台的设计，对于数据的增删改查基本都在这个系统里实现，我参考了很多优秀的产品，例如比较流行的wordpress架构以及国内的discuzx，主要是数据库设计相关的，因为我对他们的定值管理还是比较感兴趣，随即发现了以下优秀的文章： wordpress源码解析-目录结构-文件调用关系、wordpress源码解析-数据库表结构（2）、wordpress源代码研究-前台运行流程、WordPress工作原理之程序文件执行顺序（传说中的架构源码分析）、技术角度wordpress结构优缺点分析、对我比较有用的可能是最后这篇WordPress数据结构分析以及研究了一下宽表和窄表在数据库中的设计宽表和窄表的建设该如何选择？，还有关于lvs负载的一些知识 LVS负载均衡，主要源自于一本叫做《淘宝技术这十年》的应该算是网站架构方面的书籍，但是里面的废话较多，主要是摆了一些人名，说了一些淘宝创造的数据以及过往用过的方法、架构等，跳跃式的看了看，前面一部分基本是大家都知道的一些知识，没什么特别，未来如果有，我再补充。
管理中心的系统设计进度截至到现在完成了25%左右吧，大概有2-3个数据库表是设计完成的，还有很多表以及很多的字段需要填充内容，还有很多很多需要学习的地方，当然，在这里我想表达的是，在学习的过程中其实感觉是最慢的，也并没有什么具体的收获，对产出大概价值也不是太高，所以，时间上的浪费对于我今天的工作满意度来说还是比较不太舒服，大概工作时间有占全天时间的45%左右？其他时间在学习和偷懒。这点是完全需要被克服的。
PS1,关于未来办公室的问题，现在在考虑寻找一些孵化器，但时间上也不是太够用，应该怎么办！？
PS2,关于产品名，现在还没有定论，如果有一个像阿里“阿珂”那样会起名的姑娘在就好了。
PS3,今天因为要搭建一个WP环境，需要一个云环境，所以体验了一下vultr的vps，效果…，怎么说呢，速度还可以，但总是感觉系统不太干净？
PS4,对于国内的云主机也有了一些了解，主要都是在以打折或者免费的形式吸引客户，在此夸赞一下亚马逊的EC2，人家基本是认证后便免费一年的状态，中文支持方面大概有70%左右的内容现在可以是中文环境了。
PS5,今天也认识了一些在坚持写技术blog的朋友，具体我就不点名了，因为感觉太忙了，记忆内存实在不够用，可以看一下这里，内容不错，人也非常热心。
2016年1月9日星期六
产品设计 day3 2016.01.09
2016.1.9 晴 无风晚间有霾
磨蹭了2天，干了2个小时的活，把商户系统设计做的差不多了，本来是做了一个整套的流程，查看、预约、支付、定制等，后来竟然被我整合到一个界面完成了，哈哈哈。系统做的多了，还是有好处，至少…，一直在思考（也分人）。
门户、用户系统、商户系统的框架有了，现在该将需求细化了，今天开始做了一些数据库方面都设计工作，主要包括一些字段，开始寻找数据库设计相关的物料（powerdesigner），外网访问的速度实在总想让人问候GFW生产者的家人，但，他们也是为了混口饭吃（卧槽，去哪儿不能混口饭吃），这个理由显然不太能被接受！
还有管理后台，也是比较复杂的一套东西，要对门户、用户、商户分别进行管理，以及未来都各部门之间都流程衔接也要进行管理考核，这个东西大概需要3天(3*8H)的工作量吧。
这几天有点懈怠，还有点想谈感情的趋势，怎么才能努力不去想那些也是个需要解决都课题。
磨蹭了2天，干了2个小时的活，把商户系统设计做的差不多了，本来是做了一个整套的流程，查看、预约、支付、定制等，后来竟然被我整合到一个界面完成了，哈哈哈。系统做的多了，还是有好处，至少…，一直在思考（也分人）。
门户、用户系统、商户系统的框架有了，现在该将需求细化了，今天开始做了一些数据库方面都设计工作，主要包括一些字段，开始寻找数据库设计相关的物料（powerdesigner），外网访问的速度实在总想让人问候GFW生产者的家人，但，他们也是为了混口饭吃（卧槽，去哪儿不能混口饭吃），这个理由显然不太能被接受！
还有管理后台，也是比较复杂的一套东西，要对门户、用户、商户分别进行管理，以及未来都各部门之间都流程衔接也要进行管理考核，这个东西大概需要3天(3*8H)的工作量吧。
这几天有点懈怠，还有点想谈感情的趋势，怎么才能努力不去想那些也是个需要解决都课题。
2016年1月7日星期四
产品设计 day2 2016.01.07
2016.1.7 晴 大风无霾
昨天设计了门户的架构体系，其实没什么架构，只是几个栏目板块和需要展示的一些内容而已，今天主要侧重的是用户中心的设计，开始的时候考虑到比较复杂，光导航菜单就设计了一堆，然后开始考虑菜单处的内容，例如业务本身是构建在以用户中心为核心轴展开的，所有的资源以及服务的流程都集成到了用户中心，其体系模式更像支付宝，而非淘宝那种开放的市场资源都暴露在公众面前。
接下来，由于涉及到金融业务，就用户的安全以及认证方面也做了很多的思考。例如：在操作敏感数据（修改手机号或者银行卡）时是否需要二步验证这个问题上就做了无数的假设，是仅仅使用手机验密的形式还是其他都做了考虑。有朋友推荐不同的模块使用不同的安全级别，最终安全方案的结论是找保险公司，公司为用户的资产进行投保，这样增加了企业及产品的可信度又对用户的资产进行了有效保护，当然必要的验证手段还是要做到。
然后就技术选型进行了一系列的考证，例如选择php、python还是Java做了很多的讨论，就开发效率、扩展、安全性方面都进行了很多的思考，思考方向主要有php方面开源的优秀项目太多，可以很快的构建业务；而python则纯粹属于个人情结，且成熟度方面跟php也差不多，但存在的问题同样突出，工程师比较难找；而Java，Java这个问题市场很成熟，很多人，但也同样是因为人数太多，造成工程师在能力方面悬殊度会更大，这层面的担忧也是存在的，而且Java的概念太多，很容易出现很多靠忽悠的人，虽然号称是平台级、企业级的语言，但也有自己的弊端吧。有一个可用链接是关于知乎上关于php\python\ruby 比较的
那些认为php只能做web的人其实真的是不太懂php的人，这里请允许我“呵呵”一下，早在2008年的时候，就已经开始用php去做分析和遍历文件系统了，虽然效率方面…（这里不谈效率）。
最终技术选型的结论是使用php构建最初的业务系统，等资源到位后，或采用Java重写。
接下来是商户端的产品设计，第一期的产品应该不会嫁接很多资源进来，以完成流程为主。用户系统资源审核会放到系统后台进行，还有一些工作，例如和用户签订电子合同及服务有效期的问题，是在设计管理系统时需要考虑的；此外，关于支付和结算的业务也需要补一下课了，关于结算还有朋友说使用人工，其实在这个层面上我更愿意相信机器。
最后，就关于grails.org遭遇GFW发出一些声讨吧，技术类型的站点也受如此待遇实在是有些想不明白了。
昨天设计了门户的架构体系，其实没什么架构，只是几个栏目板块和需要展示的一些内容而已，今天主要侧重的是用户中心的设计，开始的时候考虑到比较复杂，光导航菜单就设计了一堆，然后开始考虑菜单处的内容，例如业务本身是构建在以用户中心为核心轴展开的，所有的资源以及服务的流程都集成到了用户中心，其体系模式更像支付宝，而非淘宝那种开放的市场资源都暴露在公众面前。
接下来，由于涉及到金融业务，就用户的安全以及认证方面也做了很多的思考。例如：在操作敏感数据（修改手机号或者银行卡）时是否需要二步验证这个问题上就做了无数的假设，是仅仅使用手机验密的形式还是其他都做了考虑。有朋友推荐不同的模块使用不同的安全级别，最终安全方案的结论是找保险公司，公司为用户的资产进行投保，这样增加了企业及产品的可信度又对用户的资产进行了有效保护，当然必要的验证手段还是要做到。
然后就技术选型进行了一系列的考证，例如选择php、python还是Java做了很多的讨论，就开发效率、扩展、安全性方面都进行了很多的思考，思考方向主要有php方面开源的优秀项目太多，可以很快的构建业务；而python则纯粹属于个人情结，且成熟度方面跟php也差不多，但存在的问题同样突出，工程师比较难找；而Java，Java这个问题市场很成熟，很多人，但也同样是因为人数太多，造成工程师在能力方面悬殊度会更大，这层面的担忧也是存在的，而且Java的概念太多，很容易出现很多靠忽悠的人，虽然号称是平台级、企业级的语言，但也有自己的弊端吧。有一个可用链接是关于知乎上关于php\python\ruby 比较的
那些认为php只能做web的人其实真的是不太懂php的人，这里请允许我“呵呵”一下，早在2008年的时候，就已经开始用php去做分析和遍历文件系统了，虽然效率方面…（这里不谈效率）。
最终技术选型的结论是使用php构建最初的业务系统，等资源到位后，或采用Java重写。
接下来是商户端的产品设计，第一期的产品应该不会嫁接很多资源进来，以完成流程为主。用户系统资源审核会放到系统后台进行，还有一些工作，例如和用户签订电子合同及服务有效期的问题，是在设计管理系统时需要考虑的；此外，关于支付和结算的业务也需要补一下课了，关于结算还有朋友说使用人工，其实在这个层面上我更愿意相信机器。
最后，就关于grails.org遭遇GFW发出一些声讨吧，技术类型的站点也受如此待遇实在是有些想不明白了。
2016年1月6日星期三
产品设计 2016.01.06
2016.1.6 晴 大风无霾
经过了几天痛并快乐着的市调，总算进入了下一个阶段，实际上还应该好好继续搞搞市调，但是…越发感觉，实际上没什么可以调查到了，总之都是要培养市场，所以还是把一些工作留给资本吧。
上午去谈了一下合作，本来成功的可能性也不大，所以也没抱太大的希望，结果不出意料，失败。哈哈哈。
下午，开始做产品和业务流程设计，计算了一下，大概有一个门户，一套会员系统，两套（至少两套）商用系统，一套管理后台，吃饭的时候还在考虑流程的问题，而且越想流程越多。
经过几个小时的努力，门户的需求设计算是有一个初稿了，还需要进行一些必要的修改和描述增加工作。门户方面主要侧重于企业形象展示、理念宣传、活动营销、客户展示等方面；接下来考虑的是会员系统的设计，主要应该包括会员资料管理、浏览业务资源、财务管理、优惠活动等功能。其中业务资源是C类业务的开始，不同类型的企业给用户消费的资源也不同，而我们这款产品主要是为用户产品进行增值服务，从这点上看，就跟其他消费型产品有质的差别了，所以用户接受起来还是很愉快的。
接下来几天的工作重点会放在商用系统设计、员工KPI系统设计、管理后台的设计及开发选型等方面，还要考虑与第三方合作以及资源对接的工作上。
明天约了一个设计师进行沟通，有很多设计的工作还是要放在本地来做，至少沟通上会方便很多。
还有那个一把钥匙一把锁的问题，我也需要进行跟踪，也会在融资的时候把这项专利技术合并进来，为了提高门槛（管控方便），做这些也是没办法的办法。
#2016我在一线
经过了几天痛并快乐着的市调，总算进入了下一个阶段，实际上还应该好好继续搞搞市调，但是…越发感觉，实际上没什么可以调查到了，总之都是要培养市场，所以还是把一些工作留给资本吧。
上午去谈了一下合作，本来成功的可能性也不大，所以也没抱太大的希望，结果不出意料，失败。哈哈哈。
下午，开始做产品和业务流程设计，计算了一下，大概有一个门户，一套会员系统，两套（至少两套）商用系统，一套管理后台，吃饭的时候还在考虑流程的问题，而且越想流程越多。
经过几个小时的努力，门户的需求设计算是有一个初稿了，还需要进行一些必要的修改和描述增加工作。门户方面主要侧重于企业形象展示、理念宣传、活动营销、客户展示等方面；接下来考虑的是会员系统的设计，主要应该包括会员资料管理、浏览业务资源、财务管理、优惠活动等功能。其中业务资源是C类业务的开始，不同类型的企业给用户消费的资源也不同，而我们这款产品主要是为用户产品进行增值服务，从这点上看，就跟其他消费型产品有质的差别了，所以用户接受起来还是很愉快的。
接下来几天的工作重点会放在商用系统设计、员工KPI系统设计、管理后台的设计及开发选型等方面，还要考虑与第三方合作以及资源对接的工作上。
明天约了一个设计师进行沟通，有很多设计的工作还是要放在本地来做，至少沟通上会方便很多。
还有那个一把钥匙一把锁的问题，我也需要进行跟踪，也会在融资的时候把这项专利技术合并进来，为了提高门槛（管控方便），做这些也是没办法的办法。
#2016我在一线
订阅：
博文 (Atom)