出于对Q3ACN一个讨论的回复。
视频……
你也不说清楚。
你说的视频压缩和视频是两码事。因为视频压缩属于单指令多数据流典型应用,也叫矢量运算,所以sse这样的指令扩展就很有用。但是怎么说AMD和Intel都不是矢量计算机,差距本质上不大,只不过AMD支持sse还是遮遮掩掩,受制于专利呀,所以优化后的程序Intel比较快。
但是关于视频渲染可就不是这个样子了,压缩器都是在具体平台通过编译器优化过的,所以AMD的超强浮点性能就体现出来了。你看现在那些大片不还都是AMD平台么(当然是因为性价比)。
Intel再牛也干不过专业硬件,视频压缩完全可以通过压缩卡来完成,绝对比CPU快。通用的干不过专用的。
前两天去听Java的一个会议。Jams Gosling(Java之父)在谈起下一代计算机的时候还在说,多内核是方向,低主频的集群会是好的解决方案。
http://forum.hibernate.org.cn/viewtopic.php?t=6947&postdays=0&postorder=asc&start=0&sid=19cfb9f49ed6092478ad38654751f38c![]()
叫做struts和webwork双体验。
这里讨论的非常好。
虽然很长,但是值得认真看,里面讨论了很多MVC的核心问题,让框架一下子便得扁平了,那些复杂的东西其实不过是非常简单的概念。你也就理解了Struts的思想,还有Webwork的思想,以及他们的优缺点。不过本贴似乎都比较偏向于Webwork2。
不过说句公道话,ActionForm的确烂,写得恶心。Webwork那种Model-Driven真是看其来简单,而且Xwork有是IoC,还支持AOP(Inteceptor),所以我也希望摆脱Webwork。而转观Tapestry,虽然我以前评价过这个东西的view层非常有特点,但是Tapestry后面的东西还是非常丑陋的(Tape3后面很复杂,而Tape4用了HiveMind以后更复杂),而且Tapestry这个东西有严重的Apache通病,自己家东西杂烩,还特别乱七八糟的,代码一塌糊涂……
所以,看完这篇评论,你会非常清楚Struts应该怎么用可以避开它的弱点。
还有,坚定了由时间一定要学习Webwork2的信念。很多人说懂了Struts,学会Webwork2只需要一个下午![]()
1、我跟踪了Hibernate的SQL,它里面的SQL的临时命名后面都加了“_”,这个东西造成我们的Domain的所有id在update时不管用,也就是说涉及存储和修改时,只有insert可以,因为这个时候的id是自动生成的,否则只要set Domain里面的id就会出错。
后来仔细察看,发现Mysql的字段名里面最好不要有“ _ ”,字符,否则Hibernate就会出问题。报告“could not execute query; bad SQL grammar”。解决方法就是把字段里面的“ _ ”去掉,比如我把user表里面的user_id改成了userid。
问题就解决了。2、解决了上面的问题还是有问题。我们的Manager的update方法不能用。会报告session里面不能有两个相同id的domain对象。
我写了个UnitTest却可以update。所以感觉很奇怪。
后来看到这里的解释:http://www.matrix.org.cn/thread.shtml?topicId=25286&forumId=23![]()
搞明白了问题。因为我们有UserAuthenticationManager,它里面会检查登陆用户的个人信息。而我在LoginAction的生命周期中UserAuthenticationManager一直处于激活状态,所以Hibernate的session也一直打开,而LoginAction里面再调用UserManager的update方法保存时就会出现session中调出两个同id的Domain对象的情况,Hibernate就会报错,然后rollback……
正好那里有解决方法,用merge方法就不会在SaveorUpdate的时候检查冲突对象了,问题就解决了。
所以希望大家注意:
1、把目前数据库中的_id这样的命名修改为xxxid这样的命名。
2、大家写的DAO中涉及到update操作的地方请使用getHibernateTemplate().merge()方法。
* AJAX 技术
* Syndication of data in RSS/ATOM
* Aggregation of RSS/ATOM data
* 简洁而有意义的 URLs
* 支持发布为 weblog
* RESTian (preferred) 或者 XML Webservice APIs
* 一些社会性网络元素
昨天有幸再次见到Michael Chen,他这个人真的很平实。
他说,我这个东西不是想做个框架,就是想提供一个客户端的异步通讯的工具。
看了这篇文章,更加加深了我对他的认同,他也认为应用决定使用什么技术,Ajax再火,在目前的xmlhttp+javascript的不完全可靠实现下也只能用在一写改善用户体验的小地方,全局的应用只不过是被技术冲昏了头脑。
我昨天和郑浩也在讨论同样的问题,我们都同意两个重要的标准:
1、技术要改变用户体验。如更好、更快捷、更清晰。这是一种功能指标。
2、技术要带来性能的提升,或者硬件的节省。因为性能我们觉得是技术的重要评价指标。当然首先要保证稳定。
而现在更多看到戴着幽雅帽子的编程技术,总是充斥着复用的话题,但是说实话,感觉真正的复用太少了,更多的是一种技术狂热,或者Open狂热。
所以我想用一个名词形容他们,“OpenMania”,开源综合症,中间还是有不少可怕的狂热症状的,不过郑浩说的很好,患了此症的人都是好人,而且是大好人。
这是闲话。
上午花了些时间把buffalo的js给精简了一下,成果不算很明显:
buffalo.js(12,007Byte) ->> buffalo_shrink.js(8,725byte)
xmlcallback.js(3,732Byte) ->> xmlcallback_shrink.js(2,785byte)
等测试完毕发给Michael Chen。
要这么想,接近缩小了1/3,也就是说带宽可以……我已经OpenMania了![]()