Bill Refactoring

今天和大二时曾经偶然认识的同学的同学吃了个饭，深感我这二十多年是过的很萧条，从来没有试图用比我当前年龄成熟、宽广的视角考虑问题。

1、技术没有绝对的高超，所有成功归根结底都是人与人的沟通

2、软件行业会越发趋于平庸，因为社会对它的需求与制衣行业本无任何不同

3、对于创业，不应该冒进，不到你摸清涉足行业的每一条通路，或者找到此方面精通的合作者就不应该始动，否则结果大半是失败

4、对于其他行业的了解是成功的关键，人对机遇的敏感性明显与知识面的广博有极大的关系

5、IT行业容易产生自大和膨胀情绪，但是这肯定是

6、每个人都相同的，都是为了自己的老婆孩子而努力

7、成功的人只有两点：精明+吃苦

8、与计算机交流太多的结果是人过于单纯，所以最容易统领的公司就是IT公司，因为IT行业里的精英大多很单纯

9、每个成功者肯定都栽过大把的跟头，所以失败不可怕，重要的是从失败获得经验，而不是失去信心

10、保持平和的心态，抱怨没有好处~~30岁的人应该比20岁的人拿的多

11、在社会打拼更有意思~~！！

要点很混乱，但是确实推翻了我很久以来对生活的认识，我才发现，这么多年来我所搞的东西是其实只是自我满足而已，没有为社会或者为我的家人创造任何价值

聊了那么多，问了问他今后再创业的计划，他说5-6年，WOW，突然觉得我的2-3年论，是如此突兀，与他现在成熟的思路比起来

我没有成型的人际网络

没有成型的产品

没有成型的经营观

对于大部分涉足的东西我还没有全面的认识

==========

最后还是要自我暗示一下

我需要更多的积累~~加油！

由于工作的需要，除了本身我们在使用的框架，我认为最重要的就是应该能对WAP有个全面的认识，我想这主要是因为

1、WAP的终端种类非常繁杂

2、各种微浏览器所用的核心代码都不相同

3、各地的移动、联通运营商所提供的网关都不同

这导致我们实际面对的环境要比WEB协议复杂的多~~

在WEB开发工作中，我几乎只和IE打交道，几乎只和WINDOWS用户交互，碰到兼容性问题，我可以说我们只支持的WinXP和IE7，其他一概不支持

而现在，我可不能说我们只支持Opera或者UCWEB，又或者我们只支持Nokia~~反正，无论啥问题都得硬着头皮上~

今天找了个大拿，跟着屁股后面跟了一个问题，然后总结了一些内容

上面是个WAP的结构图，是我从网络上Copy的

大概的结构是对的，终端-》网关-》应用服务器，只是我觉得他说的WAP网关的作用不太正确，在我看来WAP网关应该只做协议间的翻译最多再加上内容的过滤，好似没有必要提供WML编码器吧~我们直接通过应用服务器就可以返回WML了啊~感觉移动终端的微浏览器应该起到的是解析的作用~~

一般情况下我们认为从终端这里上来，到WAP网关被转换协议，一般都不会出现任何问题，最可能出现问题的实际上是在WAP网关与应用服务器的交互上

而最可能出现问题的一般是包头不被匹配，比如，WAP将某一请求转发到应用服务器后，应用服务器返回的response的包头格式与WAP网关兼容的包头格式不同，则很可能出现不能正常返回给终端，在应用服务器给网关Response时就会报错。

我由于没有找到一本很好的系统的介绍WAP的书籍，所以内容比较繁杂~~今天和大拿交流还碰到了一个新的情况，比如虽然手机展示一般使用的是UTF-8的编码格式，但是手机提交上的输入项并不一定是 UTF-8的编码格式，这样有可能导致用户上来的输入内容可能被解析成乱码或者错误的内容，为了解决这个问题，目前我们采用的办法是在隐藏域中加入一个识别中文，调用应用时会首先去用这个域里的编码和已经写好了中文的多种编码格式对比，这样一旦匹配我们就可以知道这个中文究竟是什么编码了，同样我们就知道浏览器给我们返回的内容应该用什么编码解析了，这样就解决了大部分编码的问题~~

找兼容性问题的基本思路是

定位问题

比如我们的应用

1、自己搭一个WEB应用，访问其中的静态页面（确定WS得到IIS转发页面请求无问题，问题可能出现在IIS转发页面请求之后）

2、自己搭一个WEB应用，访问其中的Servlet（确定WS得到IIS转发Servlet请求无问题，我认为同上）

3、访问原有我们BTT应用,访问其中的静态页面（确定通过App返回给WS的页面请求无问题，问题出现在App返回中）

4、访问原有我们BTT应用,访问其中的Servlet（确定通过App返回给WS的页面请求无问题，同上）

==========================================================

其实，WAP就是WEB，只是个变种的而已，目前我缺少的不完全是对WAP的理解，而是对WEB，对TCP/IP的理解，所以只有全面提高才行啊~~最近，帮忙查WAP兼容性问题的机会实在是难得，要珍惜啊

===========================================================

在扯个不一定对的内容，所有有WEBServer，且WEB Server为IIS的WAS应用的请求都是首先访问到这个应用的WEB服务器的80端口，然后转发请求到App服务器的某些端口~这是通过某插件实现的，今天出现的问题就是在IIS上看到日志成功解析了上下文和资源，但是转发直接报了404，可是404这个错误在IIS plugin的日志里完全没有看到，所以估计是IIS没能正常转发该请求

===========================================================

[1]<!--[if IE]>
<?XML:NAMESPACE PREFIX = GDOC />
<![endif]-->

我对商业其实没什么认识，只是最近可口可乐收购汇源的新闻铺天盖地，从sina，到各个论坛都是各种各样不利于收购的新闻

本来我没觉得怎么样，只是被这么一折腾，我突然觉得是不是有什么人在背后搞鬼，现在网络力量强大，舆论的影响力也很大，我可不想不明不白的被谁利用了

大概读了读各个方面的文章

认为不该被收购的：

1、汇源是中国的品牌，是少数经营状况等等都很优秀的中国品牌，作为中国最好的希望，不能给老美了

2、可口可乐已经习惯了吞并其他竞争对手，不能让他得手

3、垄断，必须是垄断，涉嫌垄断

这些都是一开始的口径，后来又说可口可乐让舆论闭嘴，等等，总之，现在可口可乐就是青面獠牙的魔鬼

可口可乐是否真有那么恐怖我不知道，我只知道，其实很多网民的爱国情绪被别人歪曲并煽动了

收购汇源本身是个两情相悦的事，为什么外界压力如此巨大，原因就是利益相关的企业

如果可口可乐能够顺利收掉国内最强的果汁饮料的企业，就意味着可口可乐能够直接参与国内企业的市场竞争，这种强强的联合会很快夺得中国市场份额，很难想象其他国内厂商在诸如Coca Cola和Pepsi以及其他外国大品牌的排挤下还能有良好的生存空间

所以，这时候很多站起来大叫的人就是这些企业的声音....我可以理解他们，也能接受他们的作为~~

应该有自己的看法~~~

/**

*本文由Bill Xu编写,如需转载请联系作者本人,bill_figting@live.cn

**/   

Chrome终于亮相，作为一个普通用户，Google带来的是巨大的惊喜，更低消耗的启动、更快的上网速度、简洁的界面，我认为，其实Chrome的推出不应该被定义为一个纯粹的浏览器，更多的应该被看做一个通道，一个打通google网络应用程序和用户之间隔阂的通道，也正是因为这个定位，Google的网络操作系统规划也亮出了獠牙。

作为一个浏览器，可能Chrome还有很远很长的路要走，它还没有Firefox一样强大的plugin阵容，也没有IE一样打上了垄断标记的用户群，甚至它的User-agent信息也还没被大量的站点接受....但作为一个通道，一个通向Google多年来一直在强调的网络应用的通道，它已经初露峥嵘。随便点点Google.com上的常年来悄悄发展的网络应用程序，我看到的不是通常互连网企业给我们的工具package，数数他的条目，画个表格，我们一点也不难看到一个操作系统的雏形，或许操作系统的名称并不准确，但却给了Google的这些网络应用一个骨架，将他们穿在一起。

先抛开个人的使用倾向不谈，就以上四个Google已经有比较成型产品的方面，我们就不难看出网络操作系统的诞生将对个人计算机产生何种革命性的改变。 

已经具备很好功能的google Docs

经济投入：

    一套Basic版本的Office需要RMB 800块

    ACDSee此类软件标准版注册费用在50$左右

    金山词霸标准版本RMB 200块

    其他一些小工具包的注册费用总和100$

    -------------------------------------------------

    2000块人民币 瞬间省下了

    其实，不仅如此，比如我们不需要Windows的操作系统来运行这个通道，可以变成linux等等，还可以节省一些钱，再此不做赘述

硬件成本：

    由于几乎全部网络应用程序的硬件资源消耗都已经转移给了提供商，那么我们的终端不需要为新版本的程序而提高配置，我想至少能让我们当前的配置减少一半及以上的硬件开销。由此为全球垃圾硬件处理所做的贡献也不再做什么赘述了。

RSS工具也同样犹如普通应用软件一般

交流成本：

    当代社会所有的财富都来自于Share，老美的FaceBook，咱们的豆瓣，还有SKype\QQ......交流网络成为了互联网这个物理载体的一个新的意识形态。而现在我们要交流我们的文档、相片流程应该是什么样子，从设备采集-》保存到本地-》选择部分文件发布到网络，而网络应用程序则在Share方面形成了最大化，我们需要的是从所有文件中选择不分享的内容，其他的全部分享；这才是一个真正的交流，才符合共享最大化的初衷。

安全成本：

    有人会说，安全成本是网络应用程序的最大短板，因为我们将所有的数据都交给了运营商；其实不然，我认为安全与否并非取决于你的资料存储在谁的地方，而在于谁对这些资料负责，显然运营商能够提供的保护，是绝大部分人都无法达到的水平。当然运营商的选择很重要，不过即使现今只有Google能选，你对他很不放心么？

B/S结构优势：

    B/S的优势我不需要太多的描述，简单的说，就是客户不需要为了升级程序而一遍一遍购买光盘，也不需要每次重做系统都安装一次各种光盘的内容。C/S当然也是目前非常流行的结构，有众多优点，客户体验则是这么多年来C/S依然能够稳定发展没有受到B/S应用毁灭式影响的重要原因。

    实际上B/S构架的C/S应用一直都在被每个Web工作者所思考，Ajax\ActionScript\SilverLight等等技术的出现都映证了这点，只是所有这些技术都是以网络浏览器为基础的，有种寄人篱下的感觉，无论什么标准，什么对象，什么控件都需要浏览器的支持，显然无论是IE\FF异或是现在的Chrome，它们的发展显然不可能没有资本家式的垄断情节，支持某种标准的同时也会为了打击另一厂商推荐的标准而断掉另一种通路，这种作为导致了Web工作者花费大量的精力在程序的兼容性上，最后也不可能得到完美的结果，为了达到厂商不断升级浏览器的要求不停的修改程序陷入泥潭，将工作量投入这无形的黑洞。

    所以，Chrome的出现可以让Google脱离其他厂商的瓶颈，专心开发属于自己的网络应用，同时以类似于通道的理念出现在大众面前，则是优秀的定位，这样我们可以和进入Word一样在桌面上找个图标，然后开始编辑、恢复、新建文档，也可以象Windows Live一样，点开一个工具界面就有了RSS、记事本、图片工具等等和生活紧密相关的社区工具。至此，我心中已经有了未来网络操作系统的样子，开机，也许我们只有64MB内存、500MHz的处理器，但是我确拥有所有我可以使用的应用软件，从视频、游戏、办公软件，甚至是未来软件开发平台等等，其实我们需要都只是个界面而已，运行完全相同于Office\Quake\Realplayer\Visual Studio.NET等等的强大软件只是需要Google有足够的资源就可以了，与我没有任何关系，这样其们的终端只需要一个显示屏，一些交互设备即可，终端的工程师不需要再为那些性能强大的功耗巨人留空间了，最小最便携的终端+无比强大的网络应用的情景终会诞生~

前言 - 2008-8-24

我们工作里的很大一个重点就是写交易流程,目前都是靠自己写脚本,重新写一个Op的时候其实还好,因为一切都是你自己的思路,但是比较头疼的问题则是一般情况下我们会去接手其他人完成的一些功能,大部分类似的功能一开始是毫无头绪的,可能需要大量的时间去分析Op文件,自己再画出流程图再进行修改........这样花费了人力,但由于大部分的项目都是以补丁的形式制作的,所以很多流程都被改的面目全非,这时我们就很需要一种能够把流程分析的很清晰的工具来提高工作效率

分析

前台显示部分

界面:Winform,我甚至想不出任何可以替代他的东西,最友善的对待用户

绘图:GDI+是首选,因为可以为这个分析工具提供一个比较全面宽松的环境,虽然可能比较简陋,但是越是离底层API近,就能越灵活,在对GDI+做了一些实验以后,我认为GDI+已经完全可以满足我们对图形绘制的要求

前台功能部分

读取交易文件显示交易流程

这是一期最重要的工作,就是展示,对于屏幕展示分支,流程,应该可自由拖动,自由删减

做内存结构的变更

我希望所有的变更都是由内存操作的,这样的好处就是我们可以随意撤消操作....也不会影响中间文件

其他功能(二期)

保存为Visio文件,保存为图片,对实际交易流程做操作

后台数据原型部分

对交易流程进行一次排序,我的第一感觉应该是给步骤分层,能够比较完美的显示

肤浅的想法是做遍历的同时做深度遍历,把做出来的结果做一次对onDo下层对象的位移,保证所有下层对象都位于内存结构的次级

生成中间文件给前台功能

一期DeadLine: 10月1日

二期DeadLine: 12月5日

展示(一) - 2008-8-31

经过了2周的协同开发,我和刚刚被伤病打倒的同事开发出一个一期的雏形,现在感觉代码显得不够清晰,可能在二期前会重构代码

目前支持的功能与一期预计的功能已经基本相同了,这里我专门录制了一个目前功能简单的展示

下一次展示可能不会有太多的变动,主要的一个修改会是修改文件处理机制,现在的处理机制是调用一个外部的exe生成原型,由于对Shell不熟悉,所以目前只会使用进程执行,但好象在进程关闭打开之间会有一些问题,导致程序不是非常稳定,所以觉得后面把这个原型工具改用DLL调用,或者直接在程序里新写个生成中间文件的类,都能够充分提供工具的稳定性