Tiny | 易学教程

悠然乱弹：WebMagic VS TinySpider

阅读更多关于悠然乱弹：WebMagic VS TinySpider

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 上次 @黄勇提到与 @黄亿华 WebMagic比较的问题。我在后面简单回复了一下下，现系统整理一下，不一定正确。两者都是可以用于网页数据抓取，都有良好的扩展性及架构设计，但是由于定位稍有差异，因此在开发的时候各有侧重点，今天就写一篇专门的文章进行比较，由于对WebMagic学习得还不够，因此有些地方可能是错误地，欢迎指正或板砖伺候。一、扫描方法的差异 a.WebMagic的扫描 WebMagic采用的是遍地撒网、愿者上勾的方式，怎么解释这个遍地撒网呢？在进行内容抓取的时候，与事先定义好的处理器中的匹配规则进行匹配，匹配成功则处理之。把所有的超链接找到并添加到待处理列表中，然后对新找到的链接继续进行处理。所以WebMagic会把所有的页面都扫描一次，在扫描的过程中进行匹配，匹配上的进行处理。 b.TinySpider的扫描 TinySpider采用的则是抽丝剥茧，精确打击的策略。什么个意思呢？在进行内容抓取的时候，首先有个入口页面，然后在上面定义了许多Watcher，实际上就是关注点了，只有它关注的点匹配的，才会执行其后续的动作触发，也就是扫描哪些页面或者后续扫描的走向是由程序员完全把控的。所以TinySpider在扫描的时候，不一定会扫描所有的页面，只扫描自己关心的内容。当然

新增TinyMessage，并实现邮件接收处理

阅读更多关于新增TinyMessage，并实现邮件接收处理

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 序言我们在业务处理过程中，经常要处理各种信息，比如：站内信息、邮件信息、还可能有短信、彩信，甚至可能与各种IM软件进行对立的信息系统。 Tiny框架也需要面对这个问题，不一样的是我觉得这几种类型的信息处理模式都是一样的，因此试图采用统一的模式进行处理。在开始之前，我们先梳理一下需求：可以支持各种信息系统如：短信，彩信，邮件，IM，站内信息的接收与发送在接收或发送消息的时候可以进行各种逻辑处理，比如：收到某种类型的邮件怎么处理，收到某种内容的短信怎么处理。邮件收到的时候，可以不删除，可以删除，也可以改成已读等各种状态发送邮件的时候，可以附加各种附件，比如：来自文件的，来自内存的等等概念抽象因此，我们就抽象了下面的几个概念： MessageAccount：接收信息或发送信息时，需要帐户，因此抽象一个信息帐户概念。 MessageReceiver：信息接收者 MessageSender：信息发送者 Message：要发送的信息，对应于邮件，短信，彩信之类 MessageReceiveService：用于提供信息发送服务 MessageSendService：用于提供信息接收服务 MessageException：用于在出现问题的时候，抛出异常 MessageSendProcessor

《企业级JavaEE架构设计精深实践》预售结束

阅读更多关于《企业级JavaEE架构设计精深实践》预售结束

如果有同学还想买书，请访问连接 http://item.jd.com/11944458.html 如果买了书，但是没有收到，请及时和我们联系，站内信或QQ都可以。 ====================================================================== 目录：首先感谢 @红薯 @黄勇为本书作序：红薯的序我不明白为什么相比于其他的编程语言，Java的世界充满了各种框架和架构。可能是因为Java太过于灵活，或者是因为官方对Java EE规范所提供的 API 都是非常底层的东西，很少牵扯到具体的业务需求。虽然这样可以在一定程度上保证规范本身的兼容性和适应性，但也因此导致了用Java开发一些具体业务应用时显得过于繁琐，不够轻便和快捷。于是出现了Struts等开源框架，再就是后来Javaer们耳熟能详的SSH三大框架，直至今天琳琅满目的各种开发框架。所有的这些框架，其唯一的目的就是简化业务逻辑的开发，其手法无不是利用各种各样的设计模式对 API 的各种层次进行封装。我曾经发文公开反对初学者在对 Java 知之甚少的情况下学习各种框架。主要原因有两点：一是知其然而不知其所以然；二是更换框架后学习成本很高。因为这样先入为主的思想作怪，当本书作者（我们姑且就叫他的网名悠然吧）第一次将他的Tiny框架提交到“开源中国”的时候

Tiny模板语言(VelocityPlus)初步入门

阅读更多关于 Tiny模板语言(VelocityPlus)初步入门

1 关于用户手册本文主要介绍如何在模板中使用Tiny模板语言，通过查阅本手册，可以对Tiny模板语言 TTL(Tiny Template Language)的用法有一个较全面的认识，并学会如何有效地使用Tiny模板语言。同时，本文提供了较多的例子帮您来学习并掌握它。 2 Tiny模板语言概述 Tiny 模板语言是一个参考 Velocity 语法的模板语言，它对 Velocity 模板语言中一些功能不太完全及使用过程中比较不方便的地方进行全面的扩展和升级，同时为了更好的适应Web界面层的开发，还提供了强大的布局功能。本文中的例子都使用Tiny 模板语言来开发。 <HTML> <BODY> Hello ${customer.Name}! <table> #for( mud : mudsOnSpecial ) #if ( customer.hasPurchased(mud) ) <tr> <td> ${flogger.getPromo( mud )} </td> </tr> #end #end </table> </BODY> </HTML> 感谢您选择Tiny模板引擎！ 3 Tiny模板语言能为您做什么？假设您是一家专门出售Mud的在线商店的页面设计人员，让我们暂且称它为“在线MUD商店”。您的业务非常繁忙，客户下了各种类型和数量的Mud订单

TinyAdmin前端展现框架

阅读更多关于 TinyAdmin前端展现框架

一直在苦苦寻找一个合适的前端框架，少说也看了几十个。 ext太重，而且有内存泄露，在IE下就是个悲剧。 dhtmlx，速度比较好，开源是GPL不适合企业应用，商业的要钱，倒也不贵万把块钱，但是样式比较接近于传统管理台应用，另外一个弊端是比较小众 Dojo，其实架构比较好，但是比较小众 Semantic：非常好的一个框架，但是成熟度不太好，对IE支持尤其比较差，另外比较小众 easyui：相对来说，也是一个不错的框架了，但是样式有点接近ext，也存在内存泄露 wijmo：非常完善的前端框架，但是比较小众，对IE8兼容方面有些问题 kendoui：也是非常不错的前端框架，比较小众，后台应用开发包要收费 jqueryui：非常不错的前端框架，应用面够广，但是组件相对少一些 JQuery：本身只是个基础库，当然有许多的插件，但是不同插件之间的样式啥的不太一致，自己去整合费效比较差 Bootstrap，不错的框架，组件相当来说少一点 ......还有许多知名不知名的前端框架，但是比较可用的，真的很难找其实我的要求也不是太高，只要满足下面的就差不多了：组件丰富些，自己不添加也足够用兼容性好一点，最好IE8以上都能兼容的修改容易点，我想要就要，不想要就不要扩展方便点，我想增加就能增加，我想修改就能修改性能能好点，即使在老旧如IE8，操作系统为XP的环境也，可以跑出不错的速度来。

Tiny前端展现框架开源了~~~

阅读更多关于 Tiny前端展现框架开源了~~~

以前发表过一篇文章： TinyAdmin前端展现框架，其在线演示路径为： http://www.tinygroup.org/tinyadmin/ ，应该说有许多人还是感觉兴趣的，但是由于这个是基于SmartAdmin框架改写的，虽然我们自己买了SmartAdmin的授权，但是广大用户如果要用的时候，就会有授权相关的问题，这会大大影响一些人的使用决策--尤其是会再发行的朋友。再一个原因是SmartAdmin初看不是不错的，但是实际用起来，里面的问题比较多，对IE8基本上可以说是不兼容，虽然我们努力进行了一定的修正，但是还是兼容性不够好。有些用户体验方面也有改进的空间，这就越来越让我思考，是不是要有更好的解决方案？直到AJian和密缘之友加入我的团队之后，我觉得是时候比较彻底的解决这个问题了。果然，在风淡芸轻、AJian、密缘之友的通力合作下，只用了一个月左右的时间，就拿出一TinyUI的初始版本，目前已经基本完善，当然我们还在进行系统性的测试，相信还存在一些小问题（有些我们自己已经发现，正在修正中），欢迎感兴趣的同学们一起来参与改进。在线演示地址： http://ui2.tinygroup.org/ 源码地址（必须托管在高大上的开源中国GIT仓库）： http://git.oschina.net/tinyframework/TinyUiEnterprise 开发环境构建

如何让程序员更容易的开发Web界面？重构SmartAdmin展示TinyUI框架

阅读更多关于如何让程序员更容易的开发Web界面？重构SmartAdmin展示TinyUI框架

序言如何让程序员更容易的开发Web界面，是一个持久的话题，所有的从事相关开发的公司都会碰到这个问题，并且被这个问题所深深困扰。 Tiny框架也不得不直视这个问题，确实来说，想解决这个问题，也是非常有难度与深度的，业界也有各种各样的尝试，这也是有各种各样不同框架出现的原因。 Tiny框架构建者认为，完全采用一种框架解决所有问题，是不现实的。而且即使目前找得到一种非常好的框架，暂时可以满足应用需要，但是随着技术的发展，业务的进化，就会慢慢变得不再满足业务需要。因此，Tiny框架构建从不再把做一套UI组件去适各种需求作为自己的目标。反过来，我们看看在做Web应用中，可能会碰到的问题： UI中JS的引入与顺序，JS合并的问题 UI中css的引入与顺序，CSS合并的问题 UI中碰到性能问题时的影响范围，比如：一个树出现问题，要改动许多用到树的地方代码重复的问题，同样的内容在许多地方都有，如果要改动就要改动许多个地方整体布局调整困难的问题程序员需要关注的内容太多的问题，JS,CSS,布局，后台业务，前台展现，尼玛界面工程师必须得是全才才可以搞得定所有问题。开发效率的问题执行效率的问题，前台响应要求速度更快集群的问题国际化的问题 ... 因此，我在以前写过一篇文章： UI开发的终极解决方案感兴趣的同学，可以去看看，今天的目标是利用TinyUI框架的重构SmartAdmin

悠然乱弹：竹子与开源：扎根是为了长得更高

阅读更多关于悠然乱弹：竹子与开源：扎根是为了长得更高

端午节到了，人们都在讨论屈原不屈不挠的精神，以及龙舟、粽叶等世界文化遗产。粽叶清淡，给人无限的遐想。或者，你很容易想起和粽叶形状比较类似的竹叶，以及屹立挺拔的骨感竹子。竹在清风中瑟瑟的声音，在夜月下疏朗的影子，都让文人墨客深深感动。而竹于风霜凌厉中苍翠依然的品格，更让诗人引为同道。苏东坡曾在《于潜僧绿筠轩》里宣称，“宁可食无肉，不可居无竹。无肉令人瘦，无竹令人俗。人瘦尚可肥，士俗不可医。”当年郑板桥曾作《竹石》，细细品味，也给人许多思考。作为开源参与者，其实我们可以联想到很多和竹子相关的典故，以及和竹子相关的精神。端午节前，困顿的晌午，我决定穿越时空，会一会屈原。一、对话屈原为此，我溯江而上，穿越雄伟险峻的长江西陵峡，抬头眺望长江北岸，有一座气势雄伟的建筑，半遮半掩在桔林与翠柏之中，这便是世人瞩目的屈原祠。拾级而上，来到屈原祠里，一番膜拜之后，我准备与屈原做一次详谈。“屈大夫，我不想继续做Tiny框架了，你能给我一个让我坚持的理由吗？”我问。屈原回答 : “你看看我的祠堂四周，看到那些山蕨和竹子了吗？去年我播种了山蕨和竹子的种子后，给它们光照和水分。山蕨很快就从地面长出来，茂密的绿叶覆盖了地面。然而，竹子却什么也没长出来。一年过去了，山蕨长得更加茂密。竹子的种子仍然没有长出任何东西。 2 年过去了，竹子的种子还是没有发芽。然而，到了第 5 年，地面上冒起了一个细小的萌芽

Tiny软件开发过程管理暂时不再开源

阅读更多关于 Tiny软件开发过程管理暂时不再开源

SDPM1.0暂时不再开源，有需要源码的同学，请加入群 228977971 获取 SDPM2.0已经开工，敬请期待~ 悠然一直想做一个我不是级的TINY示例，但是这个东东工作量巨大，不是3下5除2可以搞得定的，于是这事儿也就放了下来，直到2015年8月，悠然觉得应该启动这个事情了，当时想得是利用群里的Tiny爱好者来开发，于是就发动了一下，结果有20多名同学准备加入，悠然非常开心，但是实际上也有一些问题，就是这些同学们热情是有的，但是无奈于都是社会中的同学，有的受工作影响，有的受家庭影响，有的受女朋友影响，实际进展不太有利。正在此时，悠然所在公司的某个部门有十名按C语言招进来的应届毕业生，拟转到Java方向，呵呵，由于原部门Java力量薄弱，该部门经理请求悠然代为培训。哈哈哈哈，这不是瞌睡的时候来了个枕头，正好用这批小鲜肉来做个试验，第一验证一下0基础的人员学习Tiny需要多长时间，另外也看看能不能利用这批人员快速的构建一个系统。第一步当然是做培训了，为了表示重视，悠然亲自出马给他们培训Tiny的设计思想及各种高级特性，当2个小时讲下来的时候，悠然发现他们眼神迷离，一脸茫然，才意识到对牛弹琴了。好吧，悠然承认小心脏受到了打击。于是接下来的2周只好安排Java基础培训、Html培训、Xml培训、SQL培训、Spring培训。唯一令悠然开心的是小鲜肉们的上进心还是非常好的

Tiny微信框架是怎样设计的？

阅读更多关于 Tiny微信框架是怎样设计的？

微信对国人而言，想必大名鼎鼎，活跃用户数已经突破6.5亿，足以说明这款应用的生命力。但是使用人数众多，不代表微信的API设计优异，有过微信公众号开发经验的人，想必复杂的报文，众多的服务API以及各种公众号资源与权限设置搞得头痛。其实Tiny框架设计理念之一就是简化开发人员的工作，设计Tiny微信框架可以一定程度上减少一般开发人员的难度。前段时间本人写过一篇博文《微信框架的几个层次》，提到了十个层级，介绍之前先说一下微信的消息通讯机制，主要分为被动推送和主动请求两种模式：一、被动推送模式。此时微信服务器是通讯发起方，用户服务器是通讯接收方。这种模式下推送报文分两类：消息和事件。如用户在微信客户端发送的文本消息、图片消息在通讯层面上就是消息报文；而事件报文一般用于处理异步响应，比如用户点击微信菜单触发菜单事件等。二、主动请求模式。此时用户服务器是通讯发起方，而微信服务器则是通讯接收方。主动请求场景很多，微信开发平台提供的大部分API都是这种模式，如自定义菜单、素材管理、支付等。而微信服务器与微信客户端之间的数据更新有以下两种方式：服务器主动推送信息。如微信的群发消息接口，在用户服务器触发群发消息后，由微信服务器往目标客户端主动推送消息。客户端拉取信息。如自定义菜单的管理接口，在用户服务器修改了自定义菜单的内容后，微信服务器并不会主动推送内容

订阅 Tiny