#2018.6.1
32位python的list限制是 536870912 个元素。
64位python的list限制是 1152921504606846975 个元素
#2018.6.27(图书馆管理系统开发的心得)
需要改进：
由于是第一次设计许多地方经验不足，流程图都是分步画的统一性不好，还丢了一些(重装了系统没备份)，接口也没提前统一设计好，对语言特性不熟悉优化没做好(py的优化还是很有必要的)，导致打包后程序体积大，前端设计的时候页面置换和隐藏更改显示费了些力气，一开始没做好布局后面再重新加布局非常麻烦。写代码没有规范，模块注释不注意，接口透明性，文档，使用驼峰命名法语义化等方面。时间也不太够不过已经开发完基本的模块后面都是重复的工作了.后面还会不断的开发，渐渐的把软件工程中学到的思想应用到平时写的东西里去。
开发注意事项:
开发的时候应该遵循一定的规范与设计模式和代码思想，便于以后修改程序，应该留下完整的文档，写代码的时候要留出修改空间和考虑从重构重复利用代码。模块上下文联系继承自哪里被谁调用，调用了哪些接口。修改时间等。多使用OOP，封装性可以解决很多问题，封层有利于后期修改代码，但是分层过多也使代码逻辑更加复杂。这次开发收获挺大，也对自己的水平有了认识，发展方向也明确了。
关于模块透明性：
重数据库开发很好地利用了数据库之间的关系，减少了代码量比如外键约束直接try就可以了，不用再选出来比较，运行时间短，而且很好的利用了数据库的事务commit保证了数据一致性情况下的回滚，适用于软件快速开发。看到一篇重语言模式的开发，其基本思想是将每个数据库尽量独立，不使用自带外键查重等，交给后台来做，选出数据对比然后返回结果。缺点是代码量会有所增加，对前端或者后台数据的审查更加严格，优点是对表间的依赖会少很多，避免许多奇怪的错误，当需求频繁变化的时候只改数据库和底层少量字段名称就可以了，适用于需求变化频繁的开发。
关于java:
在开发过程中对子窗口的处理，一些处理技巧借鉴了老师给的Java代码，自己想的话只能想出更愚蠢的办法来处理，其实就是代码量和知识储备不足。Java只开发了两个模块。开发进度太慢而且重复性工作多。前端对接也很容易出错，但是代码的逻辑思维都是一样的，注重软件的组织过程，这更让我认识到语言只是工具，重要的是逻辑思维和解决问题的能力核对工具特性的熟悉程度
#软件的高可用性
计算机系统的可用性用[1]平均无故障时间（MTTF）来度量，即计算机系统平均能够正常运行多长时间，才发生一次故障。系统的可用性越高，平均无故障时间越长。可维护性用平均维修时间（MTTR）来度量，即系统发生故障后维修和重新恢复正常运行平均花费的时间。系统的可维护性越好，平均维修时间越短。计算机系统的可用性定义为：MTTF/(MTTF+MTTR) * 100%。由此可见，计算机系统的可用性定义为系统保持正常运行时间的百分比。图书《可伸缩架构：面向增长应用的高可用》
# 短网址服务
#纠结树莓派还是萤火虫
有点担心萤火虫资料不全被坑，但树莓派感觉性能有点低。。。不过资料全啊。。考完网络再说。