Read Sean

Read me, read Sean.
posts - 508, comments - 655, trackbacks - 9, articles - 4


IDG旗下的Computerworld今天发表了一篇关于Vista的文章,作者Scot Finnie是从2003年便开始测试Vista的beta tester,文章的标题是: "The Trouble with Vista",以下是原文链接:

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9009961
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9009961&pageNumber=2
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9009961&pageNumber=3
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9009961&pageNumber=4

文章中不乏对Vista在原来版本Windows改进,以及微软整个team在Vista上所下功夫的肯定,但主要还从背后驱动Vista的动机来解释为什么Vista会做成现在这个样子。微软变了,不再是10年前那个关注用户体验,站在最终用户角度考虑问题的公司,而将注意力集中在以下两点:1- 尽量避免在公众领域的负面影响;2- 确保高端企业用户满意。在后"微软vs反垄断"时代,用户不再是上帝,微软也不再倾听。什么该有什么不该有早早就被确定下来。文章从Security、升级方式、DRM、Software Protection Platform (SPP)、定价5个方面一一进行分析。最终的结论是尽管Vista有很多受欢迎的改进,也一定能够成功,但它已不再让人兴奋,也不再有趣,"I don't absolutely have to have it. You don't either."

你会升级到Vista吗? 如果你问我,我的答案是: 现在还不会,将来有可能,不过如果上天给我这个机会,我将收拾行李,逃离MS和Windows。


posted @ 2007-02-01 21:30 laogao 阅读(645) | 评论 (0)编辑 收藏


http://www.alittlemadness.com/?p=76

今天读到这篇文章,原来和我想的一样,不过DRO这个提法的提法比我提炼的要更好,呵呵。


posted @ 2007-01-30 23:09 laogao 阅读(659) | 评论 (0)编辑 收藏


The greatest of faults, I should say, is to be conscious of none.
- Thomas Carlyle

Thomas Carlyle是19世纪英国历史学家、评论家、作家,试着翻译一下:“我得说,所有过失中,最严重的,莫过于意识不到它们的存在。”


posted @ 2007-01-29 19:33 laogao 阅读(704) | 评论 (0)编辑 收藏


接着上一篇的思路聊。既然我们可以把开发者社群看作一个整体,copy-paste别人的blog文章就是在违背DRY的精神,其实所谓"重造轮子"道理也是一样,既然别人都已经做了相同的事情,并且把它开源了,并且你看了它的代码以后,觉得做得不错,为什么还要自己费心去实现同样的功能呢?自己来实现能给你带来什么好处呢?

我可以列举一些我认为可能会让我们选择自己来做的理由:

  1. 我比其他人更了解我们自己的需求。
  2. 自己实现起来更容易,代码量更小,也更好用。
  3. 我是做技术的,能够DIY,就DIY,这样更能体现我的价值。

这些理由有它的道理,但是我们有必要仔细掂量掂量:

  1. 我比其他人更了解我们自己的需求。这是软件开发中很常见的一个误区,客户的需求难以把握,随着时间的推移,我们自己的技术层面的需求实际上也在不断变化,开源的框架往往经历了更多的考虑和验证,并且有一群热心的维护者帮你做bug-fix和升级,甚至我们自己就可以成为这群热心人中的一员。
  2. 自己实现起来更容易,代码量更小,也更好用。一开始确实是这样的,开源的框架为了满足不同的需要,往往需要比我们自己写代码要更加复杂和冗余,但是自制框架意味着我们自己定义的接口规范,这个接口规范能不能够在整个项目周期保持稳定暂且不谈,就算接口实现的再简单,项目中其他人也需要时间去理解和消化,然后记住一个定义好的调用方式,今后新加入的工程师也需要学习这个接口规范。开源框架则做得更好,一方面在这个项目中积累和学习到的知识,可以直接用在其他采用同一框架的项目中,另一方面新加入的人如果有过该开源框架的开发经验,上手时间可以缩短。
  3. 我是做技术的,能够DIY,就DIY,这样更能体现我的价值。我必须承认,我本人就亲身经历过这样的情况。在即将结束的这个项目中,我甚至自己DIY了一个简易的.NET报表引擎,为的是甩开Crystal Reports。一开始能够DIY报表引擎的想法让我兴奋得睡不着觉,最终前后花了3天很满意的完成了设计和开发,并交付报表开发人员重画报表。可是真正用了一段时间之后,基本的需求满足了,基本的可扩展性也具备,但是缺少可视化设计器、更灵活的公式、更丰富的报表元素,基本上就定型了,没有人有时间和精力再去维护它。

在很多开发团队,大家经常碰在一起讨论具体的技术和设计,这很有必要,有时也不可避免。但是也许Joel Spolsky说的对,软件设计很难,但是比设计软件更难的,是同整个team一起设计软件。做技术的,对于自己了解、掌握、做过、尝试过的东西,对于自己熟悉和信任的东西,多多少少有些偏袒,而对于新的、自己不了解、不熟悉的东西,则难免心存疑虑。这就难怪很多设计讨论会最终很难达成一致。这个时候,要么由技术上的最高权威直接拍板,定下来是什么就是什么,要么就分歧双方或多方各自陈述,然后由项目外部的实体进行独立仲裁。

我看好开源框架,尤其是那些经过考验广泛被采用的框架,因为相比自制框架,它们有着更大的优势。


posted @ 2007-01-26 00:32 laogao 阅读(960) | 评论 (0)编辑 收藏


如果你使用Firefox或Opera并且看到我上一篇随笔WYSIWYG这一个词,你可以看到它下面是用一串点标注出来的,如果你鼠标悬停在上面,会有工具提示"What You See Is What You Get"。HTML源代码是:

<abbr title="What You See Is What You Get">WYSIWYG</abbr>

可惜微软的IE并不能正确render这个tag,尽管它是标准(X)HTML的一部分。


posted @ 2007-01-25 23:23 laogao 阅读(1135) | 评论 (2)编辑 收藏


http://www.garrettdimon.com/archives/aspnet-vs-front-end-architecture

该文作者细数了他在使用ASP.NET进行开发的过程中遇到的6点不爽的地方,主要都集中在前台架构上,包括大量内联的风格标签、不同浏览器生成不同页面代码、失败的标记设计、缺乏语意一致性、服务器端label和客户端label的脱节、服务器端ID和客户端ID脱节等等。尤其当你想使用标准的CSS,构建数据结构和表现分离的清晰页面时,ASP.NET的一些默认的内部处理可以让你对ASP.NET为何这样做完全无语。比较有趣的是本文后面的回复,其中有不少与楼主同病相怜的网友,还有来自微软员工的为ASP.NET辩护的声音。

我一直对MS在很多设计思路和决定上心存疑虑,不明白为什么MS硬是要自成风格搞自己那一套蹩脚的所谓"规范"或"标准",似乎在鼓励大家follow一个并不清晰、多少有些混杂无章的设计架构,其实为了方便它实现更cool的WYSIWYG开发工具。就拿今天来说,本来我们项目定义好所有模块都按BO和UI分开,BO里面的类和UI里面的类各施其责,原则上UI依赖BO,而不是反过来,按照我的理解和期望,Windows.Forms命名空间应该是由UI层来依赖,而非BO层。很显然,因为我们的form都放在UI层,肯定是依赖Windows.Forms了,而我们尽可能把所有业务逻辑代码放到BO层。但是为了临时实现一个文本文件形式的log,因为我们的业务逻辑代码都在BO层,所以为了记录有意义的log,我们的log逻辑自然而然只能放在BO层。但是一个基本的获取程序运行路径的方法属于System.Windows.Forms.Application类,让我们不得不using System.Windows.Froms。这其实还好,我们也许不应该强求Windows.Forms一定就是只针对UI上的应用。问题是你每天都在面对类似的情况,每天都或多或少在和.NET API和框架其他部分在打架,当你使用.NET的API时间久了,自然而然你就被它带到它的那一套思路中,你的设计也就自然而然跟着它走了,业务逻辑和UI逻辑交织在一起,当你回过头来想把层次理清理顺已经成为Mission:Impossible。因为抛开MS推荐的方式,自己实现一套自认更清晰的架构,相较"官方"的blueprint设计,代价实在有些高。

所以虽然我没有真正开发过ASP.NET,尤其是2.0版,但我很能理解他们遇到的尴尬。


posted @ 2007-01-25 23:01 laogao 阅读(752) | 评论 (0)编辑 收藏


http://mikeomatic.net/?p=138

挺有趣的一篇文章。Java在桌面应用这个领域始终得不到广泛的认同,虽然Java 6和SWT/RCP都为改善桌面版Java应用做出了自己的努力,但Java在这个领域的坏名声已经难以挽回。造成这一现状的始作俑者是谁,是什么原因导致人们对桌面版Java心存偏见,使用Java开发桌面应用的朋友也会经常会觉得力不从心呢?该文作者提出了三点:

  1. Sun没有意识到这样一个事实:任何一款桌面框架的实现,假如不能无缝的运行在Windows上,都注定成为“也能运行”的一种GUI技术,始终无法和native的版本抗衡。
  2. 他们认定解决(实现)高级桌面控件的方法是通过Swing这种方式,为了“跨平台”,所有东西本质上都是通过JFrame自己在canvas上画,而不是利用现成已经实现的东西,带来额外的开销和重复劳动。
  3. 他们早应该把官方的开发工具做得更加完善,现在NetBeans发展很好,但是不是有点太晚意识到这个问题了,而不论OS X还是Windows,都在这方面积累了一大批忠实用户。

我认为,不管桌面版Java过去的名声如何,能够跨平台运行,越来越好的虚拟机环境和性能,越来越好的API和工具支持,庞大的开发群体和开源框架/工具,Java仍然是开发企业级桌面应用的一个相当不错的选择。


posted @ 2007-01-25 21:30 laogao 阅读(1095) | 评论 (4)编辑 收藏


http://www.artima.com/weblogs/viewpost.jsp?thread=192781

Artima上刚发表了一篇关于开发人员按照对待单元测试的态度和接受程度划分的三种不同的基因:
T1 - 天生接受型,给他们演示一下单元测试的概念和用法,他们立即一拍即合,编写单元测试案例成为他们开发中一个理所当然、不可或缺的步骤。
T2 - 易于接纳型,给他们足够的时间和鼓励,能够理解单元测试的好处并在开发活动中执行,但遇到项目压力,他们会选择代码优先而忽略单元测试。
T3 - 先天免疫型,不论你如何给他们灌输单元测试的好处,他们都不会领情,如果让他们把单元测试作为开发中的日常活动,他们宁愿不做开发。

我提议大家想一想,自己属于哪一类?自己所在的团队中的其他人,属于哪一类?我们希望自己和自己的团队是哪一类?希望单元测试在我们日常开发中扮演什么样的角色?


posted @ 2007-01-25 20:47 laogao 阅读(557) | 评论 (0)编辑 收藏


作为开发者,我们必须要学会defensive programming,尤其是对要求高可靠性和无人职守的企业级应用中,需要特别留意我们的设计和编码,必须尽可能做到足够defensive。

什么是defensive programming?举个大家都看过的例子:

String str = ...
if ("".equals(str)) {}

在这里我们不写str.equals("")而是反过来,就是为了防止出现不必要的NPE – NullPointerException。

运行期异常是最最需要特别关照的一种非正常状况,除了像上面这类要求我们采用相对较好的编码习惯之外,为了减少运行期异常的发生,通常也需要使用try-catch代码块来把我们相对脆弱,或者需要格外保护的逻辑包起来,对于外部传进来的参数,一定要assert它们的合法性,即assert它们是否能够安全的被后面的逻辑所使用。

通常意义上,defensive programming主要cover的是避免不必要的运行期异常发生。我们可以更进一步,更广义的运用defensive programming的核心思想:在企业应用中,除了运行期异常,对于有些看似严重的极端的错误,如网络超时,连接丢失,数据库提交失败等情况,需要我们具体问题具体分析,并非所有checked exception都一定需要我们去一一catch然后处理。更多的时候,尤其当开发无人职守的后台程序,我们可以采取重试、报告、修改外部数据等方式处理,能够自行解决的,就不要动不动就报错,或等待用户确认,不能自行解决的,则要及时报告并停止运行,避免更大的错误发生。

举个相对具体的例子,两个异构的系统,通过一个中间层的消息平台相互发送消息,通信协议采用最基本的socket方式,这三个系统随时都可能出现宕机或链接中断的情况。为了保证数据的完整性,我们拿其中一个需要发送和接收消息的系统来细说:

一个可能的实现方式是:该系统所有要发送的消息保存到数据库,给它一个初始状态;另一个独立进程从数据库按照时间先后拿出消息,更新拿出的这条消息的状态为处理中,并尝试发送消息;成功后根据需要,更新消息状态为成功发送或者直接删除,如果遇到失败或异常,消息恢复为初始状态,线程sleep一段时间,然后再次尝试,多次尝试或者尝试跨度超过一定时间范围,则停止处理,向管理员汇报(通过邮件、短信等途径)。对于接收到的消息,同样是先存入数据库,然后再由后续的进程用类似的方式取出并处理。如果程序崩溃,可以自动重新启动(应用或整个服务器)。这样不管哪一段通信线路出现故障或阻塞,或者宕机,系统都可以一步一个脚印,确保任务主动而自动的执行,并且忠实记录下有价值的状态信息,出现问题时管理员可以很直观的看到在哪个环节出现故障,从而快速找到问题关键并有效解决。

Defensive programming可以让我们的应用更健壮,在保证数据正确性、完整性的前提下,面对困难也能更加独立自主。和defensive programming相关的话题我想大家如果感兴趣,可以展开更多更深入的探讨,这里只是给大家做个介绍性的铺垫,能抛砖引玉当然更好。


posted @ 2007-01-25 00:03 laogao 阅读(1372) | 评论 (1)编辑 收藏


链接:
http://wordpress.org/development/2007/01/ella-21/


posted @ 2007-01-24 21:04 laogao 阅读(490) | 评论 (0)编辑 收藏


本文假定你有CD-ROM光驱以及Linux Live CD (如Ubuntu),并使用GRUB作为bootloader。

安装好Windows基本系统后,用Live CD启动,进入Linux桌面,打开Terminal,sudo -s切换到root,然后执行如下步骤:
  # grub
  grub> root (hd0,7)
  grub> setup (hd0)
  grub> quit
  # shutdown -r now
机器重启后,熟悉的grub界面又出来了。:)

注意在root命令和setup命令后都有空格。另外稍微解释一下hd0和hd0,7的含义:hd是Hard Disk的缩写,0表示第一块硬盘,7表示编号为7的分区。如果不确定原先的Linux安装所在的分区编号是多少,可以在敲完"root (hd0,"后敲[TAB]键,在列表中即可通过文件系统类型和分区大小一目了然的找到。


posted @ 2007-01-23 21:14 laogao 阅读(5102) | 评论 (4)编辑 收藏


详见:
http://www.linux-foundation.org/wordpress/?p=286


posted @ 2007-01-22 23:59 laogao 阅读(677) | 评论 (0)编辑 收藏


DRY为何物?DRY是Don't Repeat Yourself的缩写,不要重复自己,这是一项软件开发中的重要原则,或者至少是一个很好的习惯。同样的数据、逻辑,我们应该尽量避免在代码、配置文件、数据库中重复,如果实在没有其他更好的办法,也应该尽可能不要手写这些重复的内容。

既然是闲侃,我想就没必要那么一本正经,索性天马行空一把,想到哪儿写到哪儿吧。

一直不习惯用桌面版RSS阅读器,最近又从Newsgator回到了熟悉的Bloglines,由于工作忙,经过几周的积累,Keep New的条目数超过500。唉,又欠下一堆的阅读债。几经删减,订阅的RSS Feed源还是有80个之多。

一直在犹豫要不要取消BlogJava的综合区RSS订阅,一方面舍不得,毕竟自己在BlogJava安家,怎么说也得捧一下场,而我也需要持续了解这个圈子的人眼下都在做些什么想些什么;另一方面,实在有些难以忍受无数不做删减,原封不动照搬照抄其他网站内容的blog文章,其中不少我早已从其他渠道看到过,或者没什么特别的内容,整段整段的代码,这样的文章看了就是一句话,头痛。

当然了,别人怎么写blog,我无权干涉,但是我是不是可以在这里呼吁一下,引用其他网站内容,能不能不要整篇照贴,要么给个链接,让大家自己去看,要么适当的引用你认为最有价值的段落或句子,或者适当给出自己的见解和评论?否则很难让别人相信你的诚意和动机,这是对原文作者、你的读者、以及你自己起码的尊重。

换个角度来看问题,如果我们把软件开发社区看作一个整体,而我们就是这个整体中的一员,那么原封不动的拷贝粘贴这个整体中另外一个个体的文章内容,又何尝不是在广义上与DRY背道而驰?既然互联网给我们大家提供了分享信息的便利,为什么我们自己不懂得去维护这个本该服务于我们自己的环境呢?


posted @ 2007-01-22 23:22 laogao 阅读(754) | 评论 (1)编辑 收藏


"Personally I'm always ready to learn, although I do not always like being taught."
- Sir Winston Churchill

这是邱吉尔的一句名言,“就我个人而言,我总是乐于学习,尽管我并非总是喜欢被教导。” 我们通常认为与learn对应的词当然是teach,但是学习和受教其实是两回事。不断学习是好事,但总是被别人指手画脚是什么感觉,相信所有人都能够理解。


posted @ 2007-01-21 19:14 laogao 阅读(533) | 评论 (0)编辑 收藏


虽然官方网站显示最新版Rails还是1.1.6,RubyForge上已经可以下载1.2.1版。

[UPDATE] 官方已正式宣布: http://weblog.rubyonrails.org/2007/1/19/rails-1-2-rest-admiration-http-lovefest-and-utf-8-celebrations


posted @ 2007-01-19 09:20 laogao 阅读(594) | 评论 (0)编辑 收藏

仅列出标题
共34页: First 上一页 6 7 8 9 10 11 12 13 14 下一页 Last