解惑

解己之惑,解人之惑

2007年1月 (第1页共4页)

人品很好

今天的事情证明我这个人的人品还是不错的,用ATM机的时候发现里面有一个卡,别人忘记了拿走了,可以直接取款,还停留在查询余额状态,不过我没有见利忘义,把卡取出来以后交给了银行。这个年头像我这样好的人是不是不多啊。回来跟同事说,他们说我就算起贪心别人通过监控录像也可以找到我的。不知道一个银行会不会为了另外一个银行(我去的民生银行,卡是广东发展的)的客户查看监控录像并追查元凶,或者说为了几百块钱而这么大费周章的从一个监控录像的影像查找这个人的身份(能否查到是另外一个问题),再通过其它的渠道得到这个人的联系资料,然后给这个人打电话要求还钱,不还钱的话。。。。。。

电子机票

今天老婆买了回家的机票,一般的代理都没有折扣了(2月10号),但是她自己原来买票的一个代理有8折的电子机票,而且还送保险,不过保险起见还是上网查了下是否有假的,结果还是不乐观,等票送到的时候,费了好大的劲在网上查,机票信息是真实的,电子机票号验证通过,但是行程单验证失败,一直说位数不对,我也不知道应该输入哪些位。后来就直接打电话给航空公司,查询了下,也说是真实的,说只要电子票号和旅客姓名一致就可以了,票的那个印刷序号不是很重要(这个和我在网上查到的说法不太一致),无所谓了,想想也对,只要能上飞机就行啊。

表现层的一些想法

上次也说过表现层是最难解决的,主要是解决复用和开发速度,目前的一些基本想法:

  • 有一个类似ECS的通用页面基本元素模型
  • 在上面的基本元素的基础上有项目需要的粒度更大一些的组件,例如下拉列表、表格甚至页面模版
  • 页面Builder,根据一定的规则可以自动创建页面的框架,然后开发人员只需要做一些小的调整
  • 和项目的模型层绑定,这样很多地方拿到模型后,使用Builder就可以使用非常少的代码得到外观一致的页面了
  • 引入AJAX,特别是一些过滤条件,根据一定的规则获取并更新到(可能增加一个客户端缓存),特别是Intranet应用,大部分可能都可以考虑使用AJAX
  • 基于规则的请求转发,不需要进行配置

其实,考虑这么多,主要是现在的视图层太灵活,因此代码风格以及解决问题的风格太不一致,维护起来简直是噩梦,给开发人员提供一个沙箱,他们只能在这个沙箱中发挥,那么产品整体的可维护性和一致性会大大提高。而且,开发的工作量也可以减少一倍以上,当然,搭建这个框架也需要很长时间,但是可以慢慢来,逐步的重构。

PR值到3

呵呵,刚刚发现的,昨天还是0的,今天变成3了,值得高兴。
这段时间非常的忙,主要是因为公司的产品要发布了,而且我也买房子了,焦头烂额的。
下个月可能也不能写多少了,要过年,公司的事情也不可能忙完,不过到了3月份可能要好一些,应该好好的考虑一下我的大轮子,并且把公司的产品重构一下,提出一个比较好的解决方案,现在的产品代码中重复的代码实在是太多了,这次因为增加一个小功能看到的,简直是触目惊心。

深度克隆的简单通用实现

今天看ECS的源代码,发现一个深度克隆的简单通用实现,当然这个实现会克隆所有的成员,因此如果你的类有一些不能保存或者克隆的成员,那么这个就无效了,但是如果你的类就是简单的POJO,那么这个还是不错的,正在为我的持久层的克隆发愁,这个应该是我正想要的。我也相信这个对很多人一样有用,虽然性能可能不是很好:

    /**
        Allows all Elements the ability to be cloned.
    */
    public Object clone()
    {
        try
        {
            ByteArrayOutputStream baos = new ByteArrayOutputStream();
            ObjectOutputStream out = new ObjectOutputStream(baos);
            out.writeObject(this);
            out.close();
            ByteArrayInputStream bin = new ByteArrayInputStream(baos.toByteArray());
            ObjectInputStream in = new ObjectInputStream(bin);
            Object clone =  in.readObject();
            in.close();
            return(clone);
        }
        catch(ClassNotFoundException cnfe)
        {
            throw new InternalError(cnfe.toString());
        }
        catch(StreamCorruptedException sce)
        {
            throw new InternalError(sce.toString());
        }
        catch(IOException ioe)
        {
            throw new InternalError(ioe.toString());
        }
    }
   

痛苦的浏览器兼容

今天又遇到一个浏览器兼容的问题,IE和FF的时间添加机制不一样,FF是addEventListener,IE是attachEvent,但是这个还不是全部,如果添加多个,这个顺序依然是不一样的,FF按照添加的顺序执行,而IE按照添加的倒序执行!
为了修正这个问题,只能使用变态的setTimeout避免这个,将对前面的结果有依赖的那个函数的调用放到setTimeout里面延迟执行。

电脑依赖症

感觉自己有深度的电脑依赖症,症状如下:

  • 没有电脑好像自己就什么都不懂了
  • 感觉很累,很疲劳的时候,如果坐到电脑前面就没有事情了,精力十足的样子
  • 除了用电脑外不知道还喜欢干什么,一般是上厕所的时候看一会书,坐地铁的时候读报,极少看电视,连续两天不用电脑是无法想像的
  • 视力下降严重,但是怎么也不能少用电脑,离开电脑就感觉没有事情可以做了
  • 用电脑和人聊天游刃有余,和人面对面聊天就不行,特别是陌生人
  • 做什么事情之前都先要上网搜索一下,看看相关的东西。

交了订金

历经磨难,总算是敲定了一个房子,交了一万的定金(呵呵,回来以后偶然看到一个文章说定金具备法律效力,而订金不具备,赶紧把收据找出来看了下,是定金),交的时候心里还真是有点惴惴不安,还是有点担心以后遇到各种问题。估计这段时间事情会比较多,公司的进度也比较紧张,而且还是快过年了,头疼啊。
可能是前段时间看到的负面信息太多,搞得我很害怕。这次交易的对象人比较老实,家里很不幸,四十多岁老公就因为癌症去世了,现在女儿还在读高中,她们家原来应该是有些钱的,97年装修的房子,装修花了8万块钱。所以我们好像也没有什么太担心的。希望一切顺利吧。

CVS开发方式是软件维护性的杀手

呵呵,不要误会,这里的CVS不是指版本管理的CVS,而是指程序员们最熟悉的三个快捷键:CTRL+C(复制)CTRL+V(转贴)CTRL+S(保存),一个软件产品中的很多代码都是这么得来的,以我们公司产品为例,最典型的莫过于Action的execute方法的前面对session是否过期的判断,以及调用后台的Session Bean的时候的异常处理,以及JSP中的大段类似代码。一旦需求发生变化,这些相关的代码可能都需要修改,我到这个公司的时候就发生过一次这样的事情:一个简单的修改要在百十几个Action中重复进行。
以我这些年的开发经验,我更加倾向于给开发人员提供一个受限的开发环境,可以供选择的接口很少,只有在必要的情况下才增加接口供开发人员使用,共通的功能只能通过共通的接口进行,否则你的工作量可能是使用正确的接口的十几倍。当然,这个开发方式比较适用于产品开发,因为项目的情况差异太大,而且开发周期相对比较短,这样做反倒延缓开发进度,增加成本。
至于如何提供那些接口,就是一个渐进的过程,开始的框架是一个宽泛的接口集,如果一段代码被重复三次,并且以后可能还会重复或者有类似的片断,那么就要马上对原来的代码进行重构,这样在第一个版本出来之前,我们就会得到一个比较好产品。在每个版本的开发前期、中期和后期都做一次代码检查,发现类似这样的代码重复问题并及时修改。

关于AJAX的一些思考

公司的产品中也引入了AJAX,但是是很简单的,代码都是自己写的,开发经理Paul看到Yahoo的新邮箱后感觉不错,期望我们也使用AJAX(实际上我们已经在使用了)。
使用AJAX,个人感觉有一些问题,首先就是开发难度,JavaScript的调试比较困难(相对于Java),而且还要解决浏览器兼容问题,另外一个就是性能,如果使用不好,对于性能反到是有害的,很多站点的解决方案都是一个大框架页面,剩下的块块都是使用AJAX一个一个加载(我们也是),这个对服务器端的负载实际是加重了。
当然也并非没有办法解决,首先就是要有一个合适的AJAX的框架,开发人员需要考虑的问题相对较少;其次就是和服务器端的交互,可以使用某种客户端缓存机制减轻负载并加快用户操作的相应时间。如果页面一直保持不完全刷新,那么这样的AJAX方案还是可以接受的,最怕的就是要经常完全刷新页面,或者是internet应用,需要对搜索引擎友好。

更早的文章

© 2025 解惑

本主题由Anders Noren提供向上 ↑