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的朋友，具体我就不点名了，因为感觉太忙了，记忆内存实在不够用，可以看一下这里，内容不错，人也非常热心。
2016年1月10日星期日
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发出一些声讨吧，技术类型的站点也受如此待遇实在是有些想不明白了。
订阅：
博文 (Atom)