jiming
- 浏览: 271262 次
- 性别:
- 来自: 北京
-
最新评论
-
lishen：
caomeiliang 写道ibatis需要写SQLibati ...
我为什么选择 iBatis 而不是 Hibernate(对于正在选型的人的建议) -
caomeiliang：
ibatis需要写SQLibatis需要写SQLibatis需 ...
我为什么选择 iBatis 而不是 Hibernate(对于正在选型的人的建议) -
yp0123456789：
这篇文章是假定h没有namesql和execute的基础之上写 ...
我为什么选择 iBatis 而不是 Hibernate(对于正在选型的人的建议) -
abc382410124：
jiming 写道引用 jeffrey_gao 5 小 ...
我为什么选择 iBatis 而不是 Hibernate(对于正在选型的人的建议) -
wpc009：
我觉得Netty的卖点一是NIO， 二是事件驱动。 这在高并发 ...
Netty 性能测试(与Tomcat 对比)
文章列表
一些鲜为人知却非常实用的数据结构
作为程序猿（媛），你必须熟知一些常见的数据结构，比如栈、队列、字符串、链表、二叉树、哈希，但是除了这些常见的数据结构以外，还有没有其他不是很有名，但却非常实用的数据结构呢，有人在 stackoverflow 上问了这样一个问题，得到了很多热心观众的回答，我们今天就来看看那些鲜为人知却非常实用的数据结构吧。
首先，维基百科上的一个页面列举了常见的数据结构，你可以先去那个页面看看。下面我们就来看看一些不是很常见的数据结构吧：
最大危难在你内心
为什么一个老板再难，也不会轻言放弃，而一个员工做得不顺就想逃走，说到底，你在一件事，一段关系上的投入多少，决定你能承受多大的压力，能取得多大的成功，能坚守多长时间。 冯仑说，伟大都是熬出来的。为什么用熬，因为普通人承受不了的委屈你得承受，普通人需要别人理解安慰鼓励，但你没有，普通人用对抗消极指责来发泄情绪，但你必须看到爱和光，在任何事情上学会转化消化，普通人需要一个肩膀在脆弱的时候靠一靠，而你就是别人依靠的肩膀。 孝庄对康熙说:孙儿，大清国最大的危机不是外面的千军万马，最大的危难，在你自己的内心。最难的不是别人的拒绝与不理解，而是你愿不愿意为你的梦想而作出改 ...
应该好好利用起来
http://www.planabc.net/2008/09/01/window_name_transport/
很多很好的特性
http://net.tutsplus.com/articles/news/perfect-workflow-in-sublime-text-free-course/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+nettuts+%28Nettuts%2B%29
有的时候开发项目的过程中需要编辑一些资源，但是这些资源又不是跟项目紧耦合，所以它们不在项目目录下。可以使用如下方式让 maven 管理。
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<configuration>
...
优势：
快
本地版本控制
分支功能超强超容易
如果命令记得熟的话，用起来很顺
只在根目录有 .git 文件，不象 subversion，每个目录都搞一个 .svn
劣势：
学习曲线高
GUI 客户端还不太成熟
权限控制不太好
以上为初步认识。
在实际环境中我们都会用 ext-all.js, 但是在开发调试的时候，我们使用 require 的话它可以动态加载单个的 js 文件，便于我们定位错误。
Extjs 3 中是这样定义类的：
MyApp.LoginWindow = Ext.extend(Ext.Window, {
title: 'Log in',
initComponent: function() {
Ext.apply(this, {
items: [
{
xtype: 'textfield',
name : 'username',
fieldL ...
很早就开始使用 jQuery 了，那时候还是 0.9.x 版。在当时刚接触到它的时候，那种感觉就是惊艳。所以这么多年来也一直坚守着它、期待着它有更加惊喜的进步，尤其是在 UI 方面。这么些年下来，其中的确有一些令人激动的新功能的出现。但是在 UI 方面，进展实在是太慢了。而且直到现在，也没有一个明确的给人以信心的路线图。
反观 Extjs，进步非常快，UI 组件异常丰富并且有非常好的融合。而且在 4.0 版本中还提供了 MVC 和 data 功能，使得编写复杂的应用更加轻松和清晰。
虽然是收费软件，但是简单的成本核算一下就可以很容易的发觉它的超值的价值。
配置管理，监控，群集等功能。是我一直想做而没有时间做的一个模块。虽然还有些功能没有包含，但是可以想些办法解决。
jBPM 是我很早就关注过的一个工作流的引擎了。当时他还是 2.0. 他的文档写的很好，自我描述也很棒。可惜深入研究后发现他不行。
后来又遇到过客户或者朋友在项目中使用 jBPM 的，已经在使用的，会向我抱怨这个东西不好。我已经很久没有跟踪过他的发展了，所以也不打算深入的探讨他的优劣。不过最近还是遇到了在项目中抛弃 jBPM 的情况，所以在此说一下。如果要采用他，请三思而行。
其实对于绝大多数的工作流需求，我们根本不需要使用 jBPM. OSWorkflow、自己开发（需要对工作流的机制有较深的了解）或者直接使用脚本语言，都是不错的选择。