最近入手敏捷开发工具，比较了一番之后发现YouTrack比较优秀。同类产品中leangoo太过简单，JIRA要收费，很贵！功能也很不错，但是安装复杂。其它国产的什么禅道、leangoo之类的，毕竟没有大气风范

遗传算法属于NP完备问题，不确定问题需要大量离散的数据进行线性处理。

对于发展很小的公司来说，单台服务器支撑整个公司的运转是常见的事情。但是随着用户量的增加，随之而来的数据量也会跟着增加，这就导致更多地用户会使用查询select我们的数据库，从而导致性能急剧的下降。例如，查询缓慢，用户等待时间长等等，高并发，大数据，负载均衡甚至是集群，这些方案都是小公司不会采用的，一方面成本极高，需要运维维护，这已经抵n个程序猿的工资了，所以一般不会采用这种模式。

仔细的分析一下，这种情况，其实更多地是来源于数据库mysql的承受能力变大，一方面需要读操作，另一方面有需要增删改操作，那么多人同时请求肯定受不了啦！
有人说使用缓存，但是再想想mysql的缓存是有限制的，并不是一味的去缓存就可以，又有人说使用redis缓存，存储在内存中，然而事实上运转的时候redis缓存并不能全部给你缓存，有些数据需要实时的查看，而且redis缓存过多，导致cpu直接上涨，严重的话，机器直接运转停止。

Slick的全称是"Scala Language-Integrated Connection Kit"，它是类型安全的函数式关系型映射库，简称FRM - Functional Relational Mapping。专门用于Scala对关系型数据库的操作。它带来了函数式语言的便利性，可以通过Scala的丰富集合对数据库转换。Slick适用基于Play 和 Akka 框架的功能实现。

Slick底层实现了DBIO的响应式设计，它是一个Reactive Stream的实现，因此有一下一些特性：

• Clean separation of I/O and CPU-intensive code: Isolating I/O allows you to keep your main thread pool busy with CPU-intensive parts of the application while waiting for I/O in the background.
• Resilience under load(负荷回弹): When a database cannot keep up with the load of your application, Slick will not create more and more threads (thus making the situation worse) or lock out all kinds of I/O. Back-pressure is controlled efficiently through a queue (of configurable size) for database I/O actions, allowing a certain number of requests to build up with very little resource usage and failing immediately once this limit has been reached.
• Reactive Streams for asynchronous streaming.
• Efficient utilization of database resources: Slick can be tuned easily and precisely for the parallelism (number of concurrent active jobs) and resource ussage (number of currently suspended database sessions) of your database server.