1、Linux下

find . -type d -name ".svn"|xargs rm -rf

2、Windows下直接通过SVN工具，这里说的是TortoiseSVN 的export功能，选择相应的项目目录，导出即可。

先看看Axure的Demo吧：http://www.axure.org/demo/

做过前端的人应该会更有感觉，操作上不会感觉太难，很快就可以上手，这要得益于Axure强大的组件库，基本上常用的组件都有，另外还有其他一些特殊的第三方组件提供下载。

这次项目中用Axure主要原因是界面框架的原因，如果UI和前端(我做)做完页面，把网页给客户看，那估计要费时不少，加上随时的改动，到后面会越做越忙，越做改动越大，所以就早动手，先用Axure把网站的各个页面框架和页码流程搭起来，跟客户一一确认，尽快完成这块的内容，再由UI去跟客户确认配色的问题，前端这个时候就可以开工了，跟之前的项目流程比，至少框架不会大动了！

第一次拿做好的页面框架给客户看，客户以为这么快页面就出来啦，很有兴趣，当然我就得必须解释解释了，这个只是框架图，和最终的效果图是有些距离的，这些页面只是将页面框架和流程展示下。

学习Axure，最主要就是多用，多看别人的Axure例子，如果一个效果自己一下子无法实现，可以在网上找别人的rp文件，仔细研究下，很快就可以自己做出来了！

再者Axure现在有好些模板，不一定就得自己去实现，Axure只是个工具，不管从哪个方面入手，达到你要的效果即可。

推荐区国内Axure推广比较有名的网站：http://www.axure.org/ 上面有很多教程和例子，可以进一步帮助学习Axure的使用。

本周主题：Web 项目开发中的常见问题

一、中文乱码

建议统一使用UTF8，或者全局做个filter处理。

二、表单校验

使用第三方校验框架， 而非自己去写，可以减少很多工作量。

三、Ajax的使用

首页尽量少用ajax，页面初次加载时常会加载不上来，尤其多个Ajax实例同时运行。

四、UI 规范

UI最好是出Demo，跟客户确认，定终稿，然后开发按最终效果图实现页面最好，否则没有页面或者效果图，即使有统一的规范，还是会浪费很多时间去调UI问题。

五、浏览器的兼容问题

虽然IE6基本上淘汰了，可老机器上使用IE6的还是不少的，Css 在处理兼容问题时，建议分开处理，在页面进行浏览器version判断，读取不同的css，这样管理和调整起来都方便。

六、比较完整的测试数据

页面框架搭完了，看着效果不错，可是填完数据后会发现和想象的不太一样。

七、用JPA Or JDBC 与数据库交互

JPA与JDBC相比之下，使用JPA大大减少了编程人员的工作量，因此还是偏向使用JPA，特殊环境下再选择JDBC

最近Twitter成为我获取信息的主要途径，几乎每天醒来第一件事情是躺床上翻推。

黑莓

换黑莓了，本想换android的手机，无奈太贵，忍住诱惑，先玩玩黑莓过些时间再折腾android。

学车

囡囡开始学车了，法培已考，办理了上车手续，不过元旦前可能比较小，海淀驾校太火爆了，约车难。

项目

年底前又开始了一个紧时间的项目，春节前要完成M1并上线，加上手上的未完项目要同时进行，这段时间几乎是掐着时间算。

出游

本来计划1月份出游的，折腾了几天，最终还是计划赶不上变化，黄了，只能安排到年后了。

预计本周四结合公司的培训内容，出一个有关JQuery的入门介绍，这个内容顺便就补给上周的周主题。

顺便预告下：接下来这周和下周会整理有关Java.Net包下一些常用类的使用，包括HttpClient的使用，以及XML Parser方面的汇总。

是关于JTable的打印，之前就因为嫌麻烦没搞彻底，简单表格的打印功能提供了，复杂点的就没弄，和业务员交流，导出Excel也可以，于是就直接让导出Excel再打印了，结果今天一个电话，和业务流程使用不相关的一个小头让全部统一提供打印功能，无语了！

唉，看看明天去摆扯的结果了，弄不好还得把剩下的打印功能加上，就看JasperReport和Swing绘制哪个稍微能不麻烦点！:(

客户可以说是一家老国企, 我们所接触的客户方面从上到下分三层, 最上面是大头, 其次是部门小头和他们的技术部门小头, 再者是项目的最终用户,部门成员, 大头定方向, 部门小头按部门需求定框架,技术小头呢想到哪说哪, 最后的部门成员根据自身需求定细节.

项目从大小来说不大, 不过从开始做到现在并没有觉得比大项目好做.

首先是接受问题, 部门成员大都上了年纪, 电脑除了工作, 连网页浏览都很少用, Email不会用, 接受能力欠佳, 都喜欢按部就班, 能不改就不改, 能不动就不动, 那怕他们手动去处理.

其次是需求问题, 客户没有需求文档,我们自己整理,结果是大头说个大概, 小头们是想到哪说哪, 今天这个不错, 明天突然又想起那个好, 三天两头有新的需求变动, 部门成员更是从自己的切身利益想方设法让我们做变动.

再者就是我们自己的问题, 一个成长中的团队, 必然有好多东西需要学习和积累.

或许也是因为在这个项目上走了不少弯路, 遇到了一些问题, 近来更是吃到一些前面犯下错误的苦, 才导致这几天一直在考虑自己在此应该注意的一些事情, 以免后面再犯.

1. 开始编程之前, 计划和规划一定要做好, 而不是一股脑的先实现了基本功能, 然后再去这修修那补补, 这样导致的最直接后果就是项目做的越久Bug越多, 以至到了项目结尾了, 数据结构还在变化, 因为没有一个牢固的基础.

2.一个模块的代码最好由一个人完成, 其他人接手也最好将之前的代码吸收掉, 而不是直接拿来就用, 不然出了问题都不知道怎么回事, 到头来还得按照自己的想法来做.

3.需求变更, 这个问题几乎是所有项目都要遇到的, 目前所做的项目更是普遍, 虽然我们也做了一些和客户确认等工作, 但是没有发现有什么效果, 这因人而已, 因客户而已, 在前期将需求调研做到位,只能说尽量去做好.

4.注释, 尽量在自己写的代码里加上注释, 尤其是一些逻辑比较复杂的方法里面, 首先其他人不好理解,再者过些时日, 自己也要从头慢慢体会了.

5.结对编程, 之前一直对这个编程方式不是很感冒, 但是在最近的工作中发现还是值得提倡的, 尤其是在一些自认为比较费时的编程部分, 找人一起写, 这样时效性最好, 不然你在这部分花费的时间绝对是Double以上的, 而且过程可能还很痛苦, 两个人搞, 第一取长补短有交流, 有收获, 第二能大幅保证进度和正确性.

6.引用李笑来老师的一句对自己提醒: "别装, 千万别装, 你也没什么可装的". 时时刻刻谦虚学习.

7.需要统一的东西, 从刚开始遇到就去做统一, 不然等大家都各自弄完了, 标准不一样, 再去做统一工作, 任务就大了.

8.发现别人的代码规范不对, 或者实现有问题, 不是帮他修正, 而是提醒他, 让他自己修正, 不然他不会知道, 而且下次很有可能再犯.

9. 一些公共的事务, 比如服务器管理, 系统部署等大家都要用到的东西, 至少有2个人可以胜任, 不然就一个人管理, 总会有一天, 这个人会因其他事情而耽误团队时间.

10. 这个问题可能稍微严重了点, 那就是变更系统实施方案, 到了项目后期, 如果这个还在变动的话, 那就是前期没做足调研, 这里面的风险不小, 首先否定了一直使用的方案, 团队接受是一个问题, 其次新方案有没有足够的调研,会不会产生其他问题, 最后是客户方面, 需要去说服,来接受新方案.

11. 时间观念, 团队对时间观念的不重视, 必然会导致项目的拖延.

12. 分享和活动, 团队应该定期或者不定期的举行一些技术甚至非技术的知识分享或者其他活动, 一方面有助于团队技术的提高, 另一方面有助于凝聚团队力量.

13. 这个应该是最重要的了, 有了规定, 规范, 团队应该去执行, 定了但不执行或者执行力度不够, 不但前期的投入白费了, 而且影响了后期的项目建设.

14. 备份工作, 说到这个就不得不说下, 我们客户竟然在不通知我们的情况下格盘重装系统, 导致数据丢失, 不过也从另一方面说明我们的备份工作没做好, 没辙, 一些数据得重新录入.