2007年3月31日星期六

Imagine Cup 2007 Web Development 第一轮出线啦!

200多支队伍参加比赛,第一轮有30队能够出线,我们队出线啦,好开心哦!第一轮比的只是策划,把策划推销出去就行了,接下来要努力把实现做好,才可能在第二轮出线。如果真能第二轮出线进入决赛就好啦,能够去韩国哦。

2007年3月24日星期六

Adobe Apollo vs Joyeur Slingshot

如果觉得这世界上有Microsoft WPF/E vs Adobe Apollo还不够刺激的话,那么我们可以看看刚刚加入这竞技场的一位新选手:Joyeur Slingshot。Joyeur Slingshot是谁?我想你应该看看它背后那个阵营标记,没错,就是Rails这5个字母!

Slingshot有什么明显的好处吗?使用Microsoft WPF/E和Adobe Apollo都要将思维模式由B/S改为C/S,将设计重点转移到运行在客户端的代码上来,不再是考虑服务器端代码如何处理客户端请求,而是考虑客户端任务如何通过请求服务器端服务完成。然而Slingshot的思路不是这样,它希望Ruby on Rails的程序通过小规模的重写就能实现offline模式的支持,就如通过小规模的重写就能将整页提交改为AJAX操作。如果你不是很清楚这在RoR中有多少工作量,就想像一下ASP.NET用上UpdatePanel和Extender所需要作出的修改吧。

Slingshot是怎么实现的?其实大部分RoR程序员都是用“offline”的模式来开发的,也就是在自己机器上装一个RoR的平台。要在一般的客户端机器上装一个RoR并不难,也就和装一个.NET Framework差不多。Slingshot提供的就是客户端和服务器端同步数据的能力,至于何时何地同步什么数据,这就由开发者决定了。同时Slingsot还强调文件的拖放传输,你不在需要一个一个选择文件然后点击上传,在Slingshot附带的客户端浏览器中你可以直接将文件拖放到页面上实现文件选择与上传下载。

使用了Slingshot的框架之后,网站还能用不同浏览器访问吗?这显然是可以的,用户看到的还是老样子的RoR网站,只不过无法使用Slingshot提供的一些功能而已。Slingshot将于4月底发布,最终和WPF/E以及Apollo的对抗将会如何呢,让我们拭目以待吧,或许Rails将继续以它的敏捷性在Web2.0领域获得较大的市场份额。

2007年3月23日星期五

更新中……

之前一段时间只看技术书,有些麻木了,所以现在改为开始看小说,更新一下大脑里面的信息结构,否则我真的没创意了。

另外最近Blog*Spot又无法从大陆访问了,大家要访问我的Blogger最好通过Feed吧。

2007年3月19日星期一

Adobe Apollo Public Alpha

Adobe Apollo Public Alpha出来啦!一直尝试去学ActionScript,却一直都学不进去,现在机会又来了,直接学习AS3,到底我能否用Apollo做点什么东西出来呢?嗯……暂时还不知道呢。

2007年3月18日星期日

你有 < table / > 强迫症吗?

上次讲到“欲练 CSS ,必先宫 IE”,如果你宫了IE然而还是觉得不得要领,那就该怀疑自己是不是有传说中的table强迫症了。

CSDN社区上,时不时能够看到一些页面整体布局的问题,要求用div做一些table才能做到的,否则就以此为把柄说XHTML+CSS布局方法不好。其实,首先要做的是改变思维,以适应XHTML+CSS的布局。

面向页面设计而非面向浏览器设计

XHTML+CSS能够实现的是一种流布局,也就是随着内容的长度自动增长区域,并且最终导致整个页面增长,这时候浏览器就必须显示滚动条。table强迫症的一个征兆就是极力避免流布局,希望以浏览器的可视区域为布局目标,要求在可视区域中划分内容区域而不是在页面上划分内容区域。实际上XHTML是无法针对浏览器设计的,因为它仅仅包含语义,或者说是内容,而浏览器如何去表现这些内容是我们无法确定的。CSS提供了我们控制表现方式的一种途径,但这仅仅是针对主流浏览器的,而且浏览器支持的“指令集”还有稍为的差别(说到这,我真希望能够为一个浏览器写CSS然后编译为全平台兼容代码),最后这些指令暂时还仅仅支持针对页面的流式布局控制。因此,如果你决定要开始写符合语义的XHTML并且仅仅用CSS控制布局,首先就要把思路转变为面向页面(或者说是文档)的布局控制,而非面向浏览器可视区域的布局控制。

接下来肯定有人要说,“那你就是承认了有些布局老方法很容易做到,但新方法很难做到啦”。这是当然的,然而这不成为我们继续使用table的理由。这时候要反过来探讨原始目标了,我们是为什么要控制布局?低层次的需求是为了美观,谁都希望同样的内容能够以更好的视觉效果展示在用户眼前;高层次的需求是为了控制受众的浏览方式,让他们能够按我们预先设计好的方式来区分页面内容的轻重点,按我们的期望优先浏览某些内容,同时也帮助他们更快的找到他们想要的内容,而不会在我们的网站内感到沮丧。既然我们确定了这时控制布局的目标,那么我们再来看看CSS是不是“没办法把事情做好”。首先,CSS也能做出美观的页面,虽然某些布局做不到,但是在CSS的限制下做到同等美观程度的页面是肯定没问题的。其次,CSS也能让设计变得友善,不会说CSS的设计就肯定是“干净”到用户无法一眼找到他想要的功能。因此,虽然CSS无法实现某些特定的布局效果,但对于设计师来说它能够达到老方法所能达到的同等效果,这就足够了。

从XHTML中去掉内容无关的视觉元素

另一个table强迫症的征兆就是,习惯为每一个视觉上的元素对应一个XHTML元素。在table中,无论视觉效果有多复杂,我们总能不停的切割table,甚至table套table,直到准确定位每一个特定的元素。然而应用了CSS之后,这就是不必要的,甚至会给设计师带来麻烦,因为XHTML+CSS就是为了内容和布局分离,所以如果一个视觉元素与内容无关,那么它就不应当出现在XHTML中,自然也就不会对应一个XHTML元素。

例如有一个网站当前栏目的徽标,这个徽标没有任何的语义,而XHTML中也有文字内容描述当前栏目了,那么这个徽标就并不一定要对应一个<img />元素。如何让徽标显示出来呢?它可以是当前栏目文字描述区域的background-image,同时通过一些定位技巧让它显示出来。如果你认为有这个徽标就不需要文字描述时,你还可以通过定位技巧将文字隐藏掉,这样单纯看XHTML或者在不支持CSS的浏览器上就只见文字描述,而在支持CSS的浏览器中则看见会标。从这个例子,我们可以看得到一个视觉元素不一定要对应XHTML中一个实实在在的内容元素,或者对应一个文本元素而非图形元素。XHTML包含的是内容,那就不应该包含与内容无关的视觉元素描述,而通过CSS你可以事后增加有关的视觉元素。

又例如:before和:after这两个伪选择器,允许你创建插入在匹配元素前后的元素,这样就能够实现非内容视觉效果仅在CSS中插入。常见的用法包括,插入clear到浮动元素之后以确保父元素的完整包含,又或者是引用语句的前后自动加上引号。事实表明,CSS是很适合于将非内容的元素从XHTML中分离出来的,因此我们在设计XHTML时就不能够总想着要有什么效果,而应该单纯想着信息的组织形式。

最后,如果要我为table强迫症开处方的话,我还是会选择《CSS Mastery/精通CSS》。看完之后,你自然能够解除上述的烦恼,理解到CSS布局带来的便利,从而选择开始用纯CSS的思维来进行设计。如果你关注CSS方面的内容,可以考虑订阅我的blog:

将来我会和大家分享更多关于CSS的思考,以及使用CSS的技巧。

2007年3月16日星期五

国内 Web 2.0 网站缺少的一个按钮

无论是web2.0网站,还是一些比较奇特的blog,都缺少一个about按钮。

明白我在说什么吗?你的网站太创新了,我都不知道是做什么服务的,又不在显眼的位置放个about,那我就真的不知道自己是否应该注册了,或者说是值得注册。有些网站还好,在页面底部的导航栏有“帮助”或者“规则”这样的东西,但这显然也不如直接在页面顶部导航栏放一个about好,因为谁会注意到底部导航栏呢?

最近我们学校有一个学院书记就大胆说出了中国学校门户的不好,“都是那些给当官的人看的新闻”,他认为学校门户就应该学习国外的,应该是服务导向的,也就是说学生和教师应该能够很方便的通过网站获取到自己需要的服务。举个例子,如果你是新生,登录你们学校门户,你知道该从哪里查询成绩吗?相信大部分人都不知道,必须有人告诉过你,你才知道哪个链接哪个链接走下来就是查询成绩的地方了。

这就是中国网站的缺陷,中国人就是特爱面子,就是纯粹做show,完全不理会网站必须服务了目标人群才算是成功的网站。

2007年3月14日星期三

什么样的 Code 更像是 Configuration

Code is Configuration这篇文章中,说到了我对Ruby on Rails优点的理解,那就是RoR的代码相当于是配置,所以能做到习惯优于配置。有人说,这是动态语言的优点,然后把动态语言和静态语言区分开来讨论各自的优劣,然而我觉得这是不能绝对划分的,语言的动态与静态是一个过渡。

举个例子,virtual函数的override也算是一种动态,因为程序是运行时查表寻找最顶层的override函数然后执行的,和所有的动态特性一样,这需要牺牲一些效率。然而我们没有把C#称之为动态语言,因为它还是要经过静态编译才能执行,但这不妨碍它拥有部分的动态特性。因此,语言不能简单的话分为动态与静态两类,这之间是可以平滑过渡的。

既然语言没有动态与静态的绝对划分,那么代码就是配置的概念也应该没有绝对的划分,我们只能讨论怎么样的代码更像是配置。为了说明为什么代码可以说是“更像配置的”,这里就再举一个例子。同样是创建一个复杂的Toolbar,在MFC里面大部分的代码都是用来“实现”这个Toolbar的,虽然MFC已经对Win32API进行了封装,但使用起来还是很像调用API的风格。而在WinForm创建复杂Toolbar的话,大部分代码都是创建控件然后设置属性,这样看起来就更像是“配置”。所以使用WinForm的代码比调用MFC的代码更像是配置。注意我这里说的是“更”,既然存在B比A更好,那就还可能存在C比B更好。比WinForm更好的是什么呢?WPF和C# 3.0,前者能够隐藏更多的实现细节,后者能够让属性设置代码更简洁,让代码看起来更像是在配置控件。

如果抛开执行效率不说,给你设计一门全新的语言,应该如何做到Code is Configuration呢?这先要看看单纯的Configuration是怎样的,例如XML,抛开背后的实现细节,单纯用XML来写程序,或者说是“配置程序”,你又愿意吗?肯定不愿意,因为虽然它的层次结构好,然而写起来很麻烦,和自然语言的差距太大了。因此,理想中的语言应该尽可能贴近自然语言的情况下,同时也能够尽量隐藏实现细节提供高度抽象的可配置性,而后者通常越是动态语言就越容易做好。说到这两点特性,你是否突然想起一门正走向消亡的语言呢?贴近自然语言一直是BASIC所强调的,而同时又是动态语言的,那就是VBScript了。然而最大量使用VBScript的应该就是ASP了,而ASP正在逐步被ASP.NET取代。或许将来有一天,VB.NET能够重新加入动态语言的特性,配合非编译的ASP.NET,能够打造一个好像ASP那样适合RAD的ASP.NET。

2007年3月2日星期五

Vista + GeForce 6600GT = 不给我玩游戏

游戏过程中,甚至是Vista自身的3D屏保,都可能出现问题,接着黑屏。幸运的话,过一会儿能够恢复显示,并且提示“显示器驱动程序 nvlddmkm 已停止响应,并且已恢复”;不幸的话,整台机死掉,只能reboot。

用Google搜索"nvlddmkm",发现问题出在NVIDIA的显卡驱动上,而且出问题最多的就是6600,哎……怎么这么不幸。而有些人通过重装驱动,或者停止超频甚至是降频解决了问题,说明这可能和主板、内存的稳定性有关,可惜我暂时找不到有效的解决办法,只能怪主板太cheap。