1.颈椎问题的严重性：会引发脑部供血、脊柱神经、睡眠等问题。不是专家，网上可自己查找相关资料。
2.原因。久坐少动。肩颈部肌肉劳损以至骨骼、软骨受损。
3.我的解决过程。
  买了个太空枕，睡觉时可支撑颈部。效果不明显。
  后来每周按摩1小时。你要想有点效果一定得到正规的地方，还得受得了疼。按一次，得疼三天。有是有点用，回想一下，这不是花钱找罪受么？
  然后去了曙光医院，医生给开了一些药，问了，大概都是缓解症状的，不能治本。

  ---我一向不同意程序员30岁转行的观点，难道我过不去这个坎？---

  转而采取日常生活中自己注意保健。一般来说，主流的意见是多运动。包括体育运动和针对性的保健操。
  我在家实践了两个月，3天一次长跑或羽毛球，每天一次散步和多次保健操。效果不算明显。
  后来我从源头上着手。
      硬性的就是减少坐在电脑前的时间，打游戏不打了，工作时想问题就起身。这个也不易。这个对工作有一定影响，但也是重要方法之一。
      软的是调整桌椅高度及坐姿。桌椅一定是符合三个90度：坐着膝盖90度，大腿和上身90度，肘部90度。
  肘部一定要有依托，至少有椅子的扶手，我现在是用了大桌子，对着90的圆弧，两肘都放在桌面上。

现在我的颈椎问题已经好多了。
总结一下，方法是综合的。但效果最明显的就是桌椅。其中最关键的就是肘部的依托，肘部放在桌面上我觉得是挺有效。
另外，不能觉得没有时间想健康问题，否则结果是不得不想。拿出你打游戏、写程序的劲头对待健康，肯定能解决问题的。

1. 免费软件,非开源软件。

2. 纯JAVA开发，B/S架构。目前支持MySQL5.0.21及以上数据库。

3. 预定义了多种缺陷处理流程，可选择使用。

   • 小型团队自由流程
     由当前处理者指定下一个处理者，流程比较灵活。
   • 小型团队受控流程
     以项目经理为中心的流程，提交后的审核、转交程序员、修改后的验证等步骤都由项目经理控制。
   • 单人流程
     只有一个使用者的流程。适合个人软件的开发过程。

4. 缺陷统计功能。使用琴棋报表。

5. 邮件提醒。流程转入下一步骤后，系统会自动发邮件给下一处理者。

6. 字典数据可自定义。优先级别、严重程度、项目、模块等等。

7. 基于角色--用户组--用户的权限控制。

这个问题想必大家都碰到过，但各有各的 做法。本人与若干同事讨论过，将各种做法总结一下。

1. 物理删除，即用delete SQL删除。如果字典数据被引用，则会抛出违反外键约束的异常，将其封装为可读的信息提示给用户。JDBC中的异常类为SQLException，如何判断是违反外键约束的异常呢？有方法如下：
   • 利用SQLException中的errorCode，这是数据库特有的错误编码。
   • 利用SQLException中的SQLState，在JAVA API DOC中说明这个是SQL99或XOPEN 标准的编码，而且可以用connection的meta data来判断符合哪个标准。经过的试验，说明这个meta data不太好用，但是SQLState还是较为统一的。

     	mysql5.0.21	sqlserver2000	oracle10	postgresql8
     ANSI99 SQLState标准的违反外键约束编码为：23000	23000	23000	23000	23503(可能要在BatchUpdateException的nextException中才能取得)
     Connection的meta data中的getSQLStateType()，符合SQL99标准应该为2	2	2	0	2

2. 逻辑删除。即置表中的一个标记字段为已删除。查询时不可见，但实际还保留在表中。 好处是不用处理数据被引用的情况。它的缺点是，如果数据没有被引用，那么它其实可以被物理删除，但确留在系统中成为垃圾数据；其次在数据有唯一编码的情况下，被逻辑删除的数据实际上还占用着一个编码，有时用户会疑惑，明明表中查不到这个编码，我在新增的数据中使用这个编码却总提示编码已存在。

    各位又是用的什么方法来处理的呢?你的方法有何优缺点，不妨一同讨论一下。

很高兴啊，我们做项目的时候选择性更强了。

不过在我一个实际的网站项目中，发现事实和看上去的不太相同啊。是否支持这些特性和支持得多好毕竟是不同的问题！比如在使用Oracle时，发现在9i上能正确执行的统计SQL到8i上居然报错，无非是多用了几个嵌套的子查询。Oracle尚且如此，MySQL也的确不能有太高期望。

下面列举一下MySQL5的问题：

版本5.0.16中对视图进行排序时，会导致服务器崩溃。如:select * from 视图名 order by 某字段。所幸5.0.21版本解决了这个问题。不过我这只是随便一用就能碰上这种致命错误，谁知道还有多少bug隐藏着呢？
存储过程更是不太爽。居然不支持递归，SQLServer和Oracle都早就支持了。郁闷，在处理树形数据时，只能写点固定树的深度的视图了。
1.1.20版本的Query browser和1.1.9版本的Administrator客户端工具稳定性好差，每天能崩个几回。不过功能比以前强些了。Query browser中多粘贴点SQL脚本就能搞死它；CREATE 某东西，按执行多两次、或快了些也能搞死它。只能说比没有强，凑合用吧。
其他基本功能用起来还不错，没碰到什么问题。当然MySQL有如此影响力肯定有他独到之处，对我来说除了免费外就是速度快、用户群大（则技术支持会比较多），否则可以考虑免费的其他数据库，如PostgreSQL，它的客户端工具就专业多了，初步感觉跟SQLServer的差不多了。

2.各种方法的目标
  结构化编程。重点是是控制结构，可看作是基本程序语句(无子程序)的结构；
  子程序化编程。似乎没有相关的历史潮流,但我认为加入认为的加入它会使整个方法的发展过程更加完整。也许这个大家都认为是当然的了?子程序(或过程、函数、方法)是模块化、面向对象编程的最重要的基石。
  模块化编程。重点是将数据和子程序逻辑相关的组合;
  面向对象编程。在模块化的基础上重点加入了模块之间的关系。这里的模块已演化为类。
3.方法体系
  上述几种编程方法可以归为一类，属于一个方法体系，其重点在于编程本身，力图有效管理并降低程序逻辑的复杂性。
  随其发展，管理的代码单元越来越大，越来越复杂，其方式也越来越接近日常的思维。
  其辅助技术或方法有编辑器、调试器、UML、软件工程等。
  我认为此体系中新的方法还未出现。现在流行的方法中:AOP面向方面编程，仅是此体系有益的补充；SOA面向服务架构，重点在于用统一的方式调用，而不依赖于底层技术，是组件化的一种形式，这不是这一类的主线方向。
 

4.总结：
      以往的编程方法和原则在现代的方法中得到了保留和发展，这对新手是一个挑战，不循序渐进的学习这些技术，想要短期学会现代方法(如：面向对象编程)是困难的。
      记住这些编程方法的主旨是很有好处的。
      新的编程方法必将是历史方法的继承和发展，所以学好这些旧的方法非常重要。
      掌握这些在各种层出不穷的新语言和新工具中不变的精华，或许，你可以不再那么疲于追赶新的技术潮流。

好熟悉的话！现在社会上的确是这么个风气。回想当初我毕业时，也基本是这么个态度。不过我当时对本专业基本没兴趣，当时本专业工作也难找，在一个中南地区的省会城市工资3、5百。当然也有好点的1千多，不过那是给成绩好的人留的。不是我这种不务正业的主可以触及的。

当初的考虑是基本上要先能养活自己。独立！在我心中是第一位的。上大学时，我就已经耻于每月向我爸要300月生活费了。我的考虑是：

1. 干本专业如果有人要我，有个5百块我也就勉为其难的去了。不过由于我不感兴趣也就没有好好学，成绩单上是比较难看的，估计不找点门路也不会有人要。总之想来想去这条路可行性约等于0。
2. 那我有什么拿手的？好像还有门手艺，倒是玩了4年吉他，也有不少大学毕业的去酒吧唱歌。不过本人嗓子容易哑，不适于干这个职业。
3. 我应该找我喜欢干的，又比较能赚钱的。计算机，就是它了。我十分想当程序员，这个名称对我，那就是一个梦想啊。就跟刚玩计算机时，对“电脑高手”名号之渴望一般。

 结果我走了第三条路。不容易啊，其间辛苦和曲折一言难尽。简而言之，就是尝试了考研换行的（考计算机）的路子失败，卖过10台品牌电脑5周后试用期后被开除，两次进过我哥同学的公司干活。成功的是第二次进我哥同学的公司，做ASP+SQLServer开发。

我当时对ASP连听都没听说过。填面试单时，我在期望工资上写的是500，我想基本上能维持大学生活的水平，够自己活下去就行了。面试时，那边就是我哥的同学，他问了些学什么专业之类的问题，我据实以告，他似乎不太满意。看到我的期望工资时，他有些愤怒，说我们这里3000以下的都不要！后来他想了想，给我的500前面加了个"1"，因为这个是公司对毕业生的平均水平。

面试完那个狂喜阿，让我下周一去上班。我回家时在路上就暗下决心，一定要好好抓住这个机会！给我一个月的试用期，说一个月后水平可以就留下否则就走人。我的压力很大啊。买本书自己看，项目经理偶尔回来指点一下，前两周我基本上是在公司自学。后来让我做个简单的数据查询页面。搞出来就算通过。

过了好多年了，对那时的心情还是如此清晰。感谢我哥和他的那个同学让我步入了这一行。不容易，不容易。

毕业后的几年，本专业忽然热了起来，一点不比计算机挣得少，但是比干编程的轻松多了。真是30年河东，30年河西！不过我基本上对这个选择没有后悔，因为我当时也不是把赚钱当作唯一的或者第一的目的。主要是因为喜欢。

所以，逢老婆的堂弟即将毕业、找工作之际，说两句心里话，不要把钱看作是好工作标准的全部，钱的多少是可变的。综合考虑行业未来的发展、自身的兴趣等多方面因素，才是比较正确的方法。

2.如何编写线程安全的代码
  很多书籍里都详细讲解了如何这方面的问题，他们主要讲解的是如何同步线程对共享资源的使用的问题。主要是对synchronized关键字的各种用法，以及锁的概念。
  Java1.5中也提供了如读写锁这类的工具类。这些都需要较高的技巧，而且相对难于调试。
 
  但是，线程同步是不得以的方法,是比较复杂的,而且会带来性能的损失。等效的代码中，不需要同步在编写容易度和性能上会更好些。
  我这里强调的是什么代码是始终为线程安全的、是不需要同步的。如下:
  1)常量始终是线程安全的，因为只存在读操作。
  2)对构造器的访问(new 操作)是线程安全的，因为每次都新建一个实例，不会访问共享的资源。
  3)最重要的是:局部变量是线程安全的。因为每执行一个方法，都会在独立的空间创建局部变量，它不是共享的资源。局部变量包括方法的参数变量。
    struts user guide里有：
    Only Use Local Variables - The most important principle that aids in thread-safe coding is to use only local variables, not instance variables , in your Action class.
    译:只使用用局部变量。--编写线程安全的代码最重要的原则就是，在Action类中只使用局部变量，不使用实例变量。

 
总结：
    在Java的Web服务器环境下开发，要注意线程安全的问题。最简单的实现方式就是在Servlet和Struts Action里不要使用类变量、实例变量，但可以使用类常量和实例常量。
如果有这些变量，可以将它们转换为方法的参数传入，以消除它们。
    注意一个容易混淆的地方：被Servlet或Action调用的类中(如值对象、领域模型类)中是否可以安全的使用实例变量？如果你在每次方法调用时
新建一个对象，再调用它们的方法，则不存在同步问题---因为它们不是多个线程共享的资源，只有共享的资源才需要同步---而Servlet和Action的实例对于多个线程是共享的。
换句话说，Servlet和Action的实例会被多个线程同时调用，而过了这一层,如果在你自己的代码中没有另外启动线程，且每次调用后续业务对象时都是先新建一个实例再调用，则都是线程安全的。