公司今年的年会，在东莞某五星级酒店举行。 会上，公司老总和部门经理们纷纷总结2008，展望2009。2008年公司效益不错，营业额是2007年的两倍还多，达到了近2亿元（公司不到200人），利润也比2007年多了不少。这让我对公司有了更多的信心和希望。希望能多发点年终奖，呵呵。 会上表彰了一批人，里面没有我。尽管我自己觉得已经尽职尽责了，但并不等于领佳节又重阳导也这么看。新的一年里，我可以做得更好一些。 抽奖也有一批人中奖，依然没有我。这个完全看运气，我从小到大买彩票都没中过什么奖（2元的除外），看来我还真的没什么偏财运，只能靠实力赚银子。 晚会的节目还比较丰富，老总们都亲自上阵，玩得很high。晚会后，大家K歌，玩色子，喝酒。新员工们很玩得开，一个个都是麦霸，从11点多一直吼到2点多，真厉害。 回想一下过去的一年，虽然辛苦，也没存着什么钱，但学到的东西还是不少的，这让我觉得踏实。没得奖，没中奖，虽然有遗憾，但总的来说，还是开心的。
曾经很天真，一厢情愿地以为，今年金融危机让很多务工者提前返乡了，票会好买点；却没想到像我一样去年没回去今年铁了心要回去的人，比那些早回去的人还要多； 曾经很傻，老乡公司可以集体订票，本来都帮我订到了，可是我觉得时间不好，让他帮我取消了； 曾经很有信心，心想着去年那么难订我都订到了，今年再努力下应该不成问题，事实却是订票电话比去年还难打，好不容易打进去那么一两次，也是提示“票已售完”； 不过，我还算是幸运的，因为我买到了票，虽然还存在着那么点不确定，但是，我有票了，拿在手里，心里真的是舒坦多了。 这年头，有钱不算什么，票才是王道！
实在懒得想一个冠冕堂皇的标题了，就杂记吧。 累。 最近做的事情，很大一部分应该是属于技术支持的人做的，虽然我是研发的，但领佳节又重阳导的安排还是要服从的。主要是因为我们的这个系统，技术支持那边没有人跟过，没有安装和配置的经验可以借鉴，而且系统调试和安装也比较繁琐，还涉及到地图数据的处理。于是研发的人就被派出去，带一带技术支持的，让他们跟一次完整的安装调试流程，以后就由他们自己去别的现场进行工程实施了。在客户现场工作，没有人管，但是工作量大，所以很紧张，中午也没有休息时间，吃过午饭就接着干，每天晚上也基本上是要加两个小时的班才能回酒店。从山西回来，我的左眼角一直跳就是因为睡眠不足，周末好好补了两觉才恢复正常。 出差回来，本以为可以安安心心编程写文档，但事实并不是那么简单。不知道什么原因，全国多个省市不约而同地要在年底前完成我们系统的建设，这下好了，我们人本来就不够，现在又要同时建，更加抽不出人来了。于是，技术支持的一个室悉数出动，兵分几路开始搞了。于是，我每天的工作，基本上就是接他们的电话，听他们描述安装过程中遇到的各种各样千奇百怪的问题，然后告诉他们怎么解决；因为他们对这个系统真的很不熟悉，有时候甚至要在电话里一步一步教他们操作。尤其是今天，三个省的人，电话轮流打，这通电话还没挂，那边已经打了好几次了，真是我方唱罢你登场啊，听得我耳朵发烧，脸颊发红。同时，我还要负责上海那边系统的升级工作，是远程拨号过去升。好几个晚上，偌大的技术支持拨号室里，就我一个人忙的不亦乐乎…… 该喜还是忧呢？ 当然，太累不是一件好事。然而，换个角度看，我从现在所做的事情里，还是能学到不少东西的。 首先，研发的不常出差，不常与客户直接打交道，但我经历了，也通过与客户直接交流了解到了一些我们当时需求分析和做设计时没想到或者想得不对的地方，这使我认识到开发人员真的不能只埋头做开发，需求虽然是有专门的人去获取和整理，但开发人员直接参与，会有意想不到的效果； 第二，在现场实际安装调试过程中，可以接触到一些平时在开发和测试环境下很难遇到或者根本遇不到的情况，通过解决这些问题，可以积累更多的经验，也可以对自己的开发有所启示； 第三，通过电话为别人提供技术支持，也是对自己快速理解能力、快速思考解决问题的能力以及表达能力的锻炼。他们所问到的问题，有的是较普遍的，有的是较个别的，对于那种普遍的问题，我会在他们描述到一定程度时判断出他们的关键所在，并告诉他们解决方案，对于那种比较个别的问题，就需要引导他们查看配置文件、日志记录等，一步一步去排查，最终找出解决的办法。他们电话话打得很频繁，有些问题被不同的人问到，尤其是今天，电话不断，这时候，我还得努力克制我的急躁情绪，尽量温和而清晰的和他们说话。但想起来有时候我还是显得有点不耐烦和急躁，应该更加平静些，耐心些，从某种程度上说我不该做这些事（我只是一个普通的程序员，只负责整个系统的一部分开发），但我毕竟是这个系统的创造者之一，我们同属一家公司，我们都有义务配合起来完成整个系统的建设。 我知道我做的这些并不能直接为我带来更可观的收入，因为领佳节又重阳导们或许知道我做的大体工作，但并不了解其中细节的繁琐，可是我应该觉得我委屈吗？不应该，因为我所做的并不是为了博领佳节又重阳导赏识，而是踏踏实实履行自己的职责，并从中学习，得以成长。不过，让领佳节又重阳导知道自己做了哪些事情，也是有必要的，要不然领佳节又重阳导在安排工作和考核业绩时做出的考虑和评估将是不全面的。这方面我也得注意：不刻意邀功，但也要让领佳节又重阳导了解我做了什么。 正如我在给公司年会写的新年寄语：在过去的一年里，我经历很多，因此成长很快；在新的一年里，我将继续努力，踏实进取，做出更大的成绩。
无意中看到有Windows Live Messenger 9.0 了，就想着升级一下，没想到到微软官方一下载安装，发现是整个Windows Live套件都升级了，包括Windows Live Mail、Windows Live Messenger、Windows Live Writer、Windows Live 照片库程序等。 安装完，启动Windows Live Mail，发现界面跟以前比，有了一些变化，程序图标也变了；随着启动的Live Messenger变化还挺大的，与之前的MSN Messenger经典的界面有了较大的变化，看着有点点不习惯，在联系人列表里面增加了“常用联系人”和“群”： 另外一个比较明显的变化就是在联系人列表下方，增加了“最近更新”区域，显示的是msn联系人的最新动态，如某某发表了一篇日志，某某更新了头像，某某更换了心情状态等等，很容易让人想到QQ及一些SNS网站的类似功能。这年头，SNS模式泛滥，微软插一脚也很正常，而且微软有自己的特色有自己的优势。 接着我就打开了Windows Live Writer，发现也有变化。记得之前用Live Writer发布日志到PJBlog程序的博客时，是不能设置关键字的，现在的设置项还是很完整的： 本篇日志就是用Live Writer编辑发布的。
之前出差，忙的一塌糊涂，虽然几乎每天都来看看，但是一直都没有更新博客，连那篇《非诚勿扰》的日志也没把它写完。今天上来一看，居然有了一条回复： 似乎有点冷清 还是留言都只有你自己看的到？ HLL的开张 可是希望不要像其他博一样悄无声息就不更新了 署名是“无名”，但我猜可能是认识我的人，或者是我Q上的好友。 说来惭愧，我这里的确相当冷清，虽然通过百度和Google每天都有一两个人进来，但是这并不是我想要的效果。没错，写博客是记录自己的经历和想法，但是如果仅仅是这样，那还不如写私人日记呢，博客写出来，自然希望有人看，希望有人评论，有交流和互动才叫博客，才能让博客产生意义。 我之所以选择自己买空间开博，是因为我觉得这样我会有更多的主动性，我可以自由发挥，可以根据我的喜好来决定我博客的一切，包括版面风格、程序功能等，尽管现在的博客服务提供商也都提供了比较丰富的模板管理功能，但总还是受到一些限制的。但是自己开博，一个很大的缺点就是，互动性相当差。在博客社区，你写了一篇新的日志，马上会被别人看到，感兴趣的的人会马上阅读到；而且阅读和评论的时候，系统会记录访问者和留言者的信息，方便博主回访；这种便利的立体网状互动性能，是自己开博客站所不具有的。自己的博客站，流量基本上来源于搜索引擎和友情链接，而且访客和留言者的信息是临时和单向的，不具备良好的互动性能。这点上可能可以通过一些技术手段来改善，我今后会做些尝试的。 但是，我相信，博客的生命力也在于坚持不懈的更新，就算是在博客社区，如果一个博客长时间不更新，它也会很快被不断更新的别人的博客所淹没；而相反，单独开博的某些比较有名的做得很有特色并长期坚持更新的博客，却能长盛不衰。 所以，我相信，冷清是暂时的，这个博客我会坚持更新，希望她有更长久的生命力，也希望看到本博的朋友们多多支持，谢谢！
片名：非诚勿扰 英文名：if you are the one 类型：喜剧/爱情 编剧/导演：冯小刚 主演：葛优 (饰 秦奋) 舒薄雾浓云愁永昼淇(饰 梁笑笑) 客串：范伟(饰 风险投资人) 方中信(饰 梁笑笑情人) 徐若瑄(饰 台湾富家女) 冯远征(饰 男同志) 胡可(饰 股票女) 车晓(饰 性冷淡女) 联合出品：华谊兄弟传媒股份有限公司 寰亚电影有限公司 浙江影视(集团)有限公司 监制：中国电影合作制片公司 联合摄制：中共杭州市委宣玉枕纱厨传部 上映日期：2008.12.18 剧情简介： 秦奋(葛优饰)的天才发明被风险投资人(范伟饰)出天价买断。一夜暴富的这位“剩男”揣着家底开始了“征婚”旅程。漫漫“征途”上，各怀心事者纷至沓来，一段“人间喜剧”演出2008世间百态。几经周折后，秦奋终遇倾心佳人梁笑笑(舒薄雾浓云愁永昼淇饰)。无奈，美人心有所属。秦奋究竟如何逆流而上？几番悲欣交集后，有志者事竟成！秦奋终于带着他的真爱开始一段全新征程…… 简单说两句 昨天（2008-12-20）去看了《非诚勿扰》。我的感觉就是这部片子最大的特点就是搞笑+广告。剧中角色间的对话，尤其是葛优嘴里蹦出来的那些，很可能又会流行一段时间。广告就不用说了，酒是威士忌，手机是MOTO，信用卡是招商银行的，还有证券公司，西溪湿地等，涵盖的范围可谓广泛。 这日志写的时间也够长的了，从2008年12月21日写了个开头就去参加朋友的生日聚会，然后是出差去太原，一直想着要写完它，并且写些新的，可是一直拖到今天了。这是插曲。 回归正题。现在想起来，《非诚勿扰》留给我的印象，依然是搞笑的台词+N多的广告，还有些莫名其妙的细节，再就是日本北海道的美丽风光。 这日志写得都跨年了，也该结束了。一句话：《非诚勿扰》，看看就行，成不了经典。如果再加一句，那就是：21世纪什么最贵？和谐！ 注：本篇开始写于2008-12-21，完成于2009-1-3
IMDB含义 IMDb全称：Internet Movie Database（互联网电影数据库），是一个关于电影、电影演员、电视节目、电视明星、电子游戏和电影制作小组的在线数据库。它是目前全球互联网中最大的一个电影资料库，里面包括了几乎所有的电影，以及1982年以后的电视剧集。 截至2007年1月29日，IMDb共收录了916,271部作品资料以及2,258,922名人物资料。 IMDb的资料中包括了影片的众多信息，演员，片长，内容介绍，分级，评论等。对于电影的评分目前使用最多的就是IMDb评分。 IMDb官方网站：http://www.imdb.com/ IMDB概述 IMDb上有丰富的电影作品信息，除了电影演员、导演、影评、剧情简介等基本信息，还有更深层的内容：比如影片拍摄相关的花絮、片中出现的漏洞、影片音轨、屏幕的高宽比、影片的不同版本信息等等。 演员、导演、作者和其他工作人员都在数据库中有自己的条目，其中列出他们参加过的影片，通常还有他们的传记。用户还可以在akas.imdb.com找到那些，在不同语言、不同国家发行时，使用的不同片名的电影。 如果你仅仅把IMDb当作一个电影和电子游戏的数据库，那你就错了。IMDb还提供每日更新的电影、电视新闻，以及为不同电影活动，比如奥斯卡奖推出的特别报道。同时，IMDb官方站点上的论坛也十分活跃，除每个数据库条目都有留言板之外，还有关于多种多样的主题的各种综合讨论版。 任何人只要有电子信箱，并使用接受Cookie的Web浏览器，就可以在IMDb上建立帐户，提交信息和参加各种主题活动的投票。针对自动化查询的需求，数据库的大部分都能以压缩的文本、文件格式下载，并用提供的工具解压。 IMDB发展史 IMDb创办于1990年10月17日，从1998年开始成为亚马逊公司旗下的网站。 IMDb前身是一个名叫“rec.arts.movies”的Usenet新闻组。当时一群热心影迷自发地组织起来，列出影片的演职员表，并为已故影人撰写小传（那时称作“死亡名单”）。1990年10月17日，IMDb的奠基人Col Needham写了一系列Unix程序，使得所有信息成为可搜索数据，这项至关重要的功能使新闻组上的信息变得更有用、更有意义。直到现在，强大无比的交叉搜索功能还是IMDb的金字招牌。 1993年，IMDb.com正式启动，成为互联网上第一个完全以电影为内容的网站。之后6年，这个网站不断发展壮大，在美国各大校园网中出现镜像，提交电影信息的用户也越来越多（IMDB的写入权力是开放的）。 1995年，随着海量数据带来的信息拥堵、对员工人数的进一步要求，IMDb走上另一个十字路口。Col Needham辞掉了他的正式工作，用自己的信用卡买下了第一台服务器，并使IMDb公司化。 1998年，IMDb的信息量继续以几何级数增长，民间自愿贡献的服务器空间很快耗尽，所有义务工作的编辑人员也被无穷无尽的处理工作淹没，所幸的是，全球最大电子商务网站亚马逊Amazon.com的创始人杰夫·贝佐斯买下了IMDb，使那些“白干活”的义工们终于拿到了薪水。 2001年3月，IMDB启动了帮助小演员成名的“宣传照”服务，2002年1月，专门针对业内人士的收费网站IMDbPro.com启动。 IMDB的评分方式 IMDb的评分包括两个分值，一个是算术平均值（arithmetic mean），一个是中值（median）。算术平均值大概就是平均数，中值是统计学中的中间数值，该值和比它大及比它小的数值是等差的。而最后我们查到的分数却既不是算术平均值，也不是中值。 IMDb的评分计算方法不是就做一下平均就ok了，在它的网页上也提到了它的计算方法是保密的。不过IMDb250佳影片用的是贝叶斯定理得出的加权分(Weighted Rank-WR)，公式如下：weighted rank (WR) = (v ÷ (v+m)) × R + (m ÷ (v+m)) × C 其中： R = average for the movie (mean) = (Rating) （是用普通的方法计算出的平均分） v = number of [...]
# oracle中nls_characterset与nls_nchar_characterset的设置及其影响 在众多的资料中，仅是说了 nls_characterset数据库字符集 nls_nchar_characterset数据库国家字符集或者国际化设置字符集 nls_characterset与数据库中char、varchar blob类型的属性字段有密切的关系 nls_nchar_characterset与nchar、nvarchar2属性字段类型相关 偶然的一个机会，让我怀疑，虽然，还没有查到确切的文献依据，nls_characterset Oracle数据库字符集的设置,对C/S结构下的数据库访问应用有比较大的影响。在这种结构中存在一个不起眼的细节，即在C/S结构下的数据库访问中，客户端经常将要执行的SQL语句发送到数据服务器端DBMS去执行，而这个SQL语句必定是要按照一定的字符集进行编码的。发送SQL语句编码的这个字符集或者是约定或者是客户端和服务器端协商得到的。但是，不管这个字符集是如何确定的，这个对我们要说明的问题影响不是太大，我们所需假设的即这个发送到服务器端执行的SQL语句是按照某种字符集编码。 一般情况下，服务器端只要对客户端发送过来的SQL语句解码正确，我们是不会发现其有异常的。但是，在国际化数据库应用下或扩展已有的数据库应用成为国际化版本时，如果nls_nchar_characterset设置欠乏考虑，就会出现写入数据库的数据，在字节级的信息就是乱码，更况论其显示值了，那就更是错误百出了，因为根基就是错的！观察表属性的字节级信息，在oracle里是通过dump(columnName,16)观察。 例如，在某个数据库中nls_nchar_characterset的设置为GBK，为了应付国际化，数据库应用对数据库表中可能包含非GBK字符集范围的列，全部定义为nachar（注：觉得应该是nvarchar）或者其他国际化属性类型。按照通常网上资料或者简明Oracle说明书，这样的设置应该是没有问题，但是，在这里再次强调下，我们出问题的不起眼的源头，某些C/S结构下的数据库访问，客户端是通过发送SQL语句到数据库执行的方式，达到访问数据库的效果。这样架构下，就会牵扯数据库服务器端，会以何种字符集，让DBMS统一看待、处理SQL语句呢？我想，这里Oracle数据库系统，可能会简单地以ASCII字符集处理SQL关键字、分割符，而以nls_characterset设定的字符集应对SQL语句中非关键字，例如查询条件、赋值等。或者它会以更简单、明快的处理方案，将客户端不管以何种编码过来的SQL语句串都转换到nls_characterset设定的字符集，统一进入SQL后续执行的核心区。不管Oracle可能会采用这两种可能的哪一种，对于客户端发送过来的SQL语句中非SQL规范关键字范畴的部分，数据库服务器端可能都会采用nls_characterset设定的字符集在后期进行处理，这样，在后面的继续处理中就会发生问题。 关于Oracle客户端访问程序，其发送过来的SQL语句的字符集可以和Oracle数据库nls_characterset设置是不同的，而不是像有些网上文档说的两者之间要保持严格相同。实际上，Oracle可能提供了对客户端不同编码格式的数据进行解码的过程，但是,Oracle解码完成后的终点基座、最终的目标可能是Oracle自身设置的nls_characterset数据库字符集。 呵呵，在这里声明一下，我也是以概念逻辑上的推测、猜度别人，而非查到第一手的关键文献资料。但是，上面所有基于猜测，都是某次Oracle故障后，自己找出的唯一比较近乎合理的解释！我也没有强求这个文档的真金白银的价值，只希望对大家有用，提供一个可能的新视角，对其价值看做仅作参考即可。很多时候，我喜欢的编程生活是，不需要懂得太多的技术细节，只需要知道它的概念逻辑即可，即其可能的实现是什么就可以了！懂得太深，会耗去很多宝贵的时间的。而且，只要你懂得其概念逻辑和模型后，后面的全部只是时间问题，也和具体实现语言也没有太大的关系，这就是概念逻辑的优势，在没有硝烟的战场是取得胜利。在这里将这次的故障总结写入博客，也是希望有人能够指出其中纰露 ：） 基于上面的所有分析，我们就可以看出来，如果客户端JDBC访问以utf-8方式将要在服务器端执行的SQL语句发送到服务器端，而其insert或者update的值域信息里面含有非nls_characterset，这个时候，请注意，字节级的乱码就出现了。因为两个字符集间utf-8<-->nls_characterset的映射关系，在事实上确实也并不是完全包含的。当然，你可以严格限定你的客户端发送到服务器端的utf-8字符编码，就是nls_characterset的一个子集，这样你也就不会出现乱码问题。但是，当你扩展你这个数据库应用，来应付更多的国际化的时间，你一定要小心了。虽然，Oracle JDBC驱动为了处理国际化的问题，已经将自己发送到服务器端的SQL语句的字符编码按照utf-8字符集进行实施，它可以是被认为近乎无限的语言处理能力，但是，你的数据库服务器端，在Oracle9i版本，未必有能力能够处理，因为它可能按照nls_characterset字符集的设定去处理客户端发送过来的SQL语句。不过，实际上Oracle可以作的更多，它可以进一步分析，如果SQL语句中含有nchar的属性列的处理，就不能以nls_characterset来处理SQL中的"值域“信息，我们程序员的控制力是还有很大空间的 。从故障的各方面分析来看，在Oracle9i版本好似还没有这样的特殊智能。 验证我这个推测的一个佐证是查看V$SQLArea视图的定义，可以看到其SQL_TEXT列的类型为varchar(1000)，即这个号称可以共享SQL语句的缓存统计表，处理客户端发送过来的SQL语句，其存储的字符集为nls_characterset！ 欢迎大家指正！ [face32]以上文章是我在写上一篇《ArcSDE启动发生GEOMETRY_COLUMNS相关错误的解决办法》后查nls_characterset相关资料时找到的，粗略看了一下，没有细究，但觉得很有见解，收藏。
同事去客户现场安装调试ArcSDE时遇到问题，SDE安装过程很顺利，显示成功安装。但是在启动SDE时却报了一个错误。 [sde@SDE_SERVER bin]$ ./sdemon -o start -p sde@sdedbsid ------------------------------------------------------- ArcSDE 9.2 for oracle10g Build 1081 Sun Sep 17 16:01:22 2006 ------------------------------------------------------- ST_Geometry Schema Owner: (SDE) Type Release: 1007 Instance initialized for ((sde)) . . . Connected to instance . . . Inconsistent data type in GEOMETRY_COLUMNS table. Could not start ArcSDE -- Check Network, $SDEHOME [...]
