【软件介绍】 TinyFramework 是值得拥有的企业级 j2ee 应用开发框架套件，专业团队开发，完整的生态体系，活跃的社区氛围，无限的水平扩展能力，7*24不间断运维能力。
项目地址：
http://git.oschina.net/tinyframework/tiny 官方地址：
www.tinygroup.org 
作者：
@悠悠然然 【正文】 1.请简单地介绍一下你自己（技术背景、学习经历、工作经历）。 主要技术领域为 J2EE 及应用开发平台领域，涉猎广泛，在模块化、元数据、模板引擎、数据库分区分表、SOA 等等领域等都有较深入实践，吃过 N 多的亏，上过 N 多的当，当然也积累了N多的经验。
在业余时间也热心于参与开源软件相关工作，在进行软件开源的同时，也编写了大量的技术博客，从问题、原理、实践进行了深入浅出的讲解。
2.开发 TinyFramework 的初衷是什么？ 其实在开发 TinyFramework 之前，也在公司的体制下主导了开发平台的开发，但是由于在公司体制下，需要完全按照公司的要求和规范来开发，实际上就是要做许许多多的妥协，而这些妥协可 能会对一个框架产生比较严重的伤害。而笔者期望做一个各方面比较均衡的开发平台，于是就从各种小的专题性验证开始，比如：流程化编程、模块化设计、数据库 分区分表等等一一进行验证，当验证的范围越来越大，涵盖的领域越来越多的时候，才真正开始决定做一个开源框架。
因此，追本溯源，最初的初衷就是对自己思想的一些验证而已。
3.前段时间 TinyFramework 刚推出 2.0 版本，新的版本里有哪些新的特性？在一年的开发中，有哪些值得记录的故事？ TinyFramework 的立意是企业级的开发平台，因此在方法论、设计理念、开发体系、设计原则、生态圈、模块化、热部署、水平扩展、元数据等非功能性要求方面做了大量的探索和实践，当然在这些领域也都有了完美或者不错的解。
当然在功能性需求方面，也有非常多的突破，由于 Tiny 框架涵盖的功能太多，因此只能拿几个有代表性来简单介绍一下：
- TinyDBRouter(数据库分区分表)：基于 JDBC 层实现，可以支持 SQL92 规范下的各种数据库进行透明的数据库分区、分表读写分离等水平扩展。
- TinyTemplate(模板引擎)：一个类 Velocity 的模板引擎，但是功能更强大，添加了许多 Velocity 不支持的特性，运行速率大致是 Velocity 的4倍。
- TinySqlDSL(数 据库开发框架)：基于领域查询语言方式的数据库开发框架，可以在 Java 中用类似于写 SQL 的方式来进行数据库编程，比较好的解决了数据库与 Java 两层之间结合时的问题(要么两者是分离的如 iBatis，要么引入一种全新的语言 如 Hibernate 的 HSQL，要么就是在 Java 中进行大量的 SQL 拼接)。当然数据库的开发方案有许多种解，各种解有各种解的优缺点，DSL 方式也是一种实现方案，有其自己的优缺点。
- TinyUI(界面引擎)：主要解决 WEB 应用开发中的模块化及 JS、CSS 及各种静态资源管理的问题，主要解决静态资源 Jar包化、CSS 合并打包压缩、JS 合并打包压缩，UI 模块之间的依赖关系等等体系性问题。
- TinyStudio(集成开发工具)：提供了可视化界面设计，可视化流程编排、模板引擎编辑器、代码生成器，服务编辑器、元数据编辑器、数据库设计器。
4.你平常是怎样维护 TinyFramework 项目和社区的？ 在早期，我们还是默默无闻的，因为我们不想在框架还是一个半成品的时候就拿出来，直到我们已经开发完毕并且在自己的项目中进行了充分验证的时候才真正的在社区或相关网站进行露面。我们大致是从以下几个角度维护项目和社区的：
通过上面的一些与项目相关的社区、博客、QQ群等形式与广大Java框架、Tiny爱好者进行了充分的互动与交流。不管是学习者、参与者、交流者、使用者，都有自己的收获，在这个过程中，我们也受益匪浅，对开源这两个字也有了更深入的理解。
5.TinyFramework 有哪些优点和特点？有没有哪些特殊的或者创新的技术运用？ - 设计理念决定了设计的目标 使 用灵活：可以整个使用它，也可以只用它的一个或几个部分。Tiny 构建者认为，一个完整的框架可能需要有许许多多个部分组成，但是对于实际应用的用户来说，它可能只需要其中的一部分功能。构架一定要有这种能力，可以由使 用者进行点菜式，使用，避免只要用一点点功能，就要引入许许多多的内容。
学习成本低、上手容易:框架的学习成本必须非常低，这样才可以让使用者更容易上手，避免由于学习难度大而导致的学习曲线太陡、太长。
保持核心的稳定性:Tiny 框架是立足于在需要稳定、安全要求非常高的应用环境中使用的，因此其稳定性就是框架构建者首要思考目标，核心部分只使用经过充验证及广泛应用的第三方包。
资产的可积累性：只有易于知识积累，才可以真正做到越用越强。
- 设计原则解决目标冲突时的解决策略 约定优于配置原则-COC
不要重复你自己原则-DRY
减法原则 :减法原则是我们自己提出的，意思就是给程序员做减法。
模块化原则 :模块化对于软件开发过程中开发、高度、集成、发布、维护过程中所起的作用及节省或花费的巨大成本。因此提出了 Business Unit 的概念，使得与模块相关的所有内容都可以放在一起。
自动组装原则 :在整个 Tiny 框架的构建过程中，都非常注重集成过程的自动组装，要求做到扔进去不用管，由框架自动集成。
下级服从上级原则 :Tiny 框架则从框架层级做了限制，使得下级必须服务上级。
单一原则 :通过单一原则进行强制性的约束，使得一个模块只解决单一模块应该解决的问题，从而避免不同的问题放在一起解决所导致的胡子眉毛缕不清的问题，同时也避免了不恰当的依赖及模板引用。
集中配置原则 ：在 Tiny 框架我们对配置做了大量的工作，一个是 COC 方式，如果不配，则采用系统默认的值；一个是集中原则：把需要人工需要配置的内容都集中起来统一配置；一个是对于不需要人工干预的配置，那就集成在Jar包中，作为发布者发布项的一部分。
- 一些创新性的技术应用 SOA：Tiny 的服务是一次开发到处使用的，也就是一旦完成了服务的开发，你可以用 RMI，WebService,Json,Xml 等等，各种你想到想不到的方式进行服务调用。
服务水平扩展能力：在遵守 Tiny 开发规范的前提下，可以方便的进行接入和服务层的水平扩展。也就是说如果你的处理能力不足的时候，只要加一台机器就可以增加处理能力，而不必对现有运行的环境进行任何变化。
模 块化技术：Tiny 的模块化的设计思想是没有什么不能进行模块化，也就是说所有的文件都可以放在 Jar 包中。为此我们做了大量的研究与实践，做到了所有的文件都可以放入到 Jar 包中，甚至连 Jsp 也可以放入Jar包。通过模块化技术，可以方便的进行模块分隔与复用。
自组装技术：Tiny 的自组装设计思想是所有的模块都可以做到加入即可用，去除就消失。也就是说，如果你用别人的一个组件，你只要通过 Maven 依赖它即可以；如果你不想用了，取消 Maven 依赖即可。这样就会大大减少集成相关的工作量。
热 部署技术：关于热部署的实践，这个有许多种，比如 OSGI 等等，但是不管哪一种，都有一定的强依赖性，或者说是侵入性。Tiny 的热部署实现机制则简单的多，只要按照正常的方式来开发Jar包，并且配置一个 Bundle 声明文件即可。实际应用当中，即可以按照 Bundle 机制运行，也可以按照普通Jar包来运行。
UIML 技术：UIML 也就是统一界面描述语言的意思。通过这一特性，再加上配套的可视化界面设计工具，就可以实现一次开发到处使用的界面开发目标。
AOP 缓冲框架：可以有效剥离缓冲与业务代码，可以透明的切换缓冲方案切换，可以大幅降低缓冲相关代码编写的开发与重构成本。
文档生成框架：凡是按照Tiny开发规范进行开发，许多的文档都可以通过工具自动化生成，文档与代码不一致不再是一个问题，同时还可以节省大量的文档编写时间 。
6.目前 TinyFramework 使用情况如何？成功的应用案例可以和我们分享下吗？ TinyFramework 从初版出来，目前主要在自己公司进行推广和应用。目前已经有许多企业级和互联网级产品基于 Tiny 开发，并在几十家客户中使用。在开源以来，许多团队或企业也在使用 Tiny 开发自己的应用，在应用过程中提出了许多好的意见、建议、需求，有的甚至直接帮我们提交了 Pull Request。一年来，Tiny的社区环境越来越完整，期望在2015年，在外部用户数上有一个较大的提升。
7.能否稍微介绍一下你们的开发团队？你们平时都是怎样进行沟通协作的？ TinyFramework 的开发团队是由稳定的团队成员组成的。我也尝试过招募一些愿意参与的爱好者，实际执行效果不太好，当然原因也是各方面的，我也非常理解没有坚持下来的参与者。
团队成员的沟通方式主要有如下几种：
- 聚众吃饭：基本上一年当中，聚众吃饭的次数得有20多次。吃饭的理由千奇百怪了，家里添丁要请、技术晋级要请、获奖了请等等，当然最多的请客理由还是由于出 现严重 BUG、有严重的设计缺陷、提交了影响开发的代码等等技术相关的理由，边吃边聊边打闹，同时就提升了大家的能力，同时也让大家认识到这种类型的错误，会导 致请客吃饭的后果，下次自然是坚决不犯了。
- GIT 中的 Issues：团队有句口头禅，嘴巴讲的不算。所以不管是需求还是 BUG，都要统统录到 Issues 当中，于是提出问题、批注问题、解决问题、跟踪问题、关闭问题，都在 Issues 当中进行管理。当然，所有的过程也就成为呈堂证供，抵赖不得。
- 开源中国 team：在开源中国推出了 team 之后，我们是第一时间使用的用户之一，我们的周报，全部在 team 中进行提交。当然后来又提供的git提交记录可自动作为日报内容功能，自动提交日报功能等等都大大的方便了我们的团队协作与交流。呵呵，目前我们的团队人 数已经有12人，估计是除了OSC团队之外，第二大团队了吧？
不论是线上还是线下的交流，对于我们的团队协作与和谐都起了非常大的作用，互为补充。
8.Team@OSC 新增了代码跟任务自动关联功能，请问此项功能对于 TinyFramework 的开发有无实质性的帮助？具体表现在哪？ 呵呵，这个功能太棒了，自从有了这个功能，大大降低了我的管理成本。开源中国的同仁们不仅是开源社区的组织者，同时也是开源软件的实践者（BTW：谁告诉我 红薯写的J2Cache为什么会有那么多的粉？），他们急开源者之所急，想开源者之所想，做的功能太实用了。不要骄傲呀，最好的永远是下一个功能。
9.你能否谈谈你对开源的理解以及国内开源技术和产品的看法？ 这个问题有点大，就拿我以前写的一篇博文中的内容来回答我对开源的理解。
关于收入的问题，如果期望开源能够快速给自己带来收入，这个可能绝大多数的可能是会失望的。一般来说，一个开源产品，从开始，到发展，到最后能有收入，能营收平衡，这个一个漫长及艰难的过程。如果靠这个买米买肉，估计要饿死的。
那开源不关心收入，为什么还要开源呢？我可想可能有如下可能：
- 获取精神上的满足
比如，你做了一个好东西，但是又卖不了钱，放在自己兜兜里，一点成就感也没有，拿出来开源，让大家使用使用，自己获得一下成就感，满不错的。 - 获取社会的认可
通过开源，获得相当的社会认可度，有可能东方不亮西方亮，获得更好的发展机会或工作机会，或者获得与别人合作的机会。 - 收集需求
一个人在那里做，总是有这样那样局限的，即使你是超级牛人， 通过给别人免费使用，别人给你提出这样那样的意见和建议，可以帮你快速丰富和完善产品。 - 用户测试
有时候，你做了个东东，自己也不知道到底好不好，现在有许多用户来使用，实际上也同时给你做了测试。 - 获取用户群
有时候，一个产品放在那里没有什么价值，但是随着用户群越来越大，可能就可以有盈利的潜质了。同时也是潜在用户的一种培育，免费使用的人多了，可能就有愿意掏钱获得更好的服务与产品或者定制开发的人了。 - 一种市场营销手段
本来产品做也还可以，通过开源，获得市场认可，提高知名度，为后续推广奠定基础；同时让人们看到内部的实现，从黑盒变成白盒，让人们放心的选择。
当然也可能是其中的几个或者全部。总之，开源是一个艰辛的选择，需要长久的坚守，需要不急不燥的一份态度。
所以，开源是一种修行，有可能是没有成果的凡人，也可能是小有成就的佛子，也有可能大有成就的尊者，还有可能是至真至高的佛。
接下来回答国内开源技术和产品的看法：
实 际上，开源这事儿也是一个螺旋式发展的代表，好几年差几年。整体来看，国内对开源的认识也在由拿来免费用的初级理解向更高级别的层次发展。比如，在开源中 国及其他开源相关网站，也涌现出越来越多的国人开源产品。从整体来看，国人开源的技术和产品相对还处在一个初级阶段，比如：仅仅是把代码开放出来，没有后 续的社区建设，也没有形成生态圈等等各种问题。但是由于国内的开源产品基数太大，我们可以看到越来越多的优秀开源者和优秀开源产品涌现出来，这也符合量变 引起质变的客观规律。Tiny框架与这些优秀开源产品相比，还比较稚嫩，还有非常大的差距，不过我们相信，只要能切实践行我们团队的格言“Think big, start small, scale fast！”，我们就一定会成功优先的开源产品之一。
10.你对开源中国有何意见和建议？ 开源中国是我见到的对开源者服务最到位的开源综合性网站之一，自从 TinyFramework 入驻到开源中国之后，在开源中国的全方位服务下，也有了相当大的进步。也对我提出的各种意见和建议秒级响应，虽然也出现过一点小问题，但是瑕不掩瑜，依然 对开源中国持100%的信任。
如果说到意见和建议的话，那就提一个：
建立较客观公允的 GIT 发现排序算法：
目前是采用 star+fork 排名机制。这两个指标确实是比较重要的指标，但是相对来说还不能够充分体现一个开源项目的全貌。相对来说还是非常容易被“刷分”的。个人以为，除了 star 和 watch 数据，提交者人数、提交数、Issue 数、Issues 关闭比例、最近一个月提交数等等更是对一个托管项目活动性的体现。因此，重构发现排序算法或者提供多维度排序是不是可以考虑一下？
关于开源访谈 开源访谈是开源中国推出的一系列针对国内开源技术发展的访谈，以文字的方式记录并传播。我们希望开源访谈能全面的展现国内开源软件、开源软件作者的现状，着实推动国内开源软件的推广与应用。
posted on 2015-06-23 22:18
柏然 阅读(121)
评论(0) 编辑 收藏