怪怪 | Nothing, Everything

"有过一个发疯的时刻,有感觉的钢琴以为它是世界上仅有的一架钢琴,宇宙的全部和谐都发生在它身上." - 狄德罗
随笔 - 101, 文章 - 3, 评论 - 1994, 引用 - 42
数据加载中……

2008年7月12日

回帖整理

原帖

 

回帖整理的目的是经常性的提醒自己那些已经想明白但做不好的,并在那些还比较模糊的问题上记录思想的轨迹的改变。

 

 

@辰

其实这样的话我也说过,不过现在反思,但是我不是站在多个名字的LZ这个角度。

 

毕竟, 前件为假,后件为真,命题为真。


问题是: 你这位大牛老师,n年后, 他相对别人也就属于早生几年的人了(前件),会不会有拿他的名字命名的用屁股想出来的算法?(后件)

前件为真, 后件为假, 那么命题就一定是假的了。

 

至于经验的传承,还是有很大必要的, 把泡沫过滤掉就好了。


@YITIAN Studio 还是 @千冰念 ?
几层意思, 都清楚啦? :)

先解决生存问题, 然后处理好自己的欲望问题,最终,找到自己喜欢的就是最重要的。

其实中间这个过程才是大多数人都痛苦的, 两个选择:

1. 实现。 实现就要评估两方面, 结果和成本, 比如也许没有一个漂亮姑娘就寝食难安。

2. 打消。 打消是因为也许你发现其实你并不需要,比如BMW能给你的一切也许VW就够了。

posted @ 2008-08-25 08:10 怪怪 阅读(222) | 评论 (3)编辑

有关云计算和我为什么反对云计算

     摘要: 无论未来会怎么样, 我坚信一点, 新的革命所带来的改变,要比瓦特发明蒸汽机到现在的一切改变加起来的总和还要多; 而且, 在我们有生之年, 就会看到它。问题就像是巴顿说的,那时候, 你、我, 还有我们现在折腾的一些所谓的“技术”, 我们在哪里?  阅读全文

posted @ 2008-08-25 03:14 怪怪 阅读(2257) | 评论 (64)编辑

八月要过了, 好像园子里又开始新一轮了...


呵呵, 谁知道我指的是什么?

 

总结: 这一年居然又是过度的一年: 了解和思考了一些对做事、 做软件真正核心的东西, 而且逐渐的可以开始用这些“虚”的东西, 来对照“实”的问题; 遗憾的是, 这些东西除了偶尔作为反潮流的后盾, 对我来说还远远不能用于实践。

 

这可以认为是它们的深度广度远超目前流行一些大框架(不是指Framework这种具体层次的)内的尝试, 也可以认为是我的能力还不足以把核心概念真正的化为己用; 可以认为是实现一套完整的东西工作量太大, 也可以认为是我太菜所以承担不起。

 

但是这一个过程, 是我万万没有想到的。 我怎么会走到今天这个样子? 这条路还要走多远? 我的选择正确吗? 这些问题似乎总也不能摆脱,古人说30而立,以前去中关村,少则叫人家大姐, 多则叫大叔, 现在很多老板年纪比我还小了, 真是....

 

时间不多了。

 

说点别的。 这些天手机坏了,背灯不亮。 先去的西单Nokia客服, 直接说我LCD坏了; 因为觉得他们胡诌, 就去了维修摊子: 第一个, 修了两个星期, 把电路修断了一根, 毛病没解决; 第二个, 修了一星期, 屏蔽罩又少了一个。 最后送到中关村的一个Nokia客服,1个小时背灯就亮了,真是挺高兴的。

 

可是,断了的那根线路没修好, 就继续放在他那。 昨天他们快下班时,说好了, 我就急匆匆的赶过去, 发现屏幕多了些水印, 他们跟我说几天自己就好, 当时他们一堆人等着下班走人, 不好意思, 就交了钱。 后来仔细一看, 修好的那个断线的线路的摁键, 一摁, 就会串到若干个键上, 屏幕似乎也不是小问题。

 

今天再去, 不承认了, 非说像我这种问题(疑似进水, 我没承认过, 因为我似乎是因为充电器短路才弄坏了的), 有水印很正常。 串线的问题, 也告诉我基本修不好,只能凑合用。 呃, 我的感受是, 再次体会了弱势群体的滋味。回来看了看手机线路图, 明白了, 他们飞线接电路时, 肯定把那根线给接地线上了, 这就造成, 表面上好了, 实际上根本走的不是原来的线路, 而是乱窜的信号误打误撞, 同时传到了两块控制电路的若干个角。他们还跟我说串线不是大问题, 确定是如何串线的确实不是大问题, 往地线上一接, 这事情可就说不好了。

 

说的再远点。 我混进几个手机维修论坛看了看, 也浏览了几个卖收费手机资料的网站, 我就一个操, 国外热心人放的资料, 全成稀罕东西了。 维修人员们粗心手糙也就算了, 获取信息和学习的能力也真是成问题。 也许就像别人说的, 电子产品, 属于那种坏了就要准备扔的, 交给维修人员, 无论是不是客服, 是好是更坏绝对都会变成一个概率问题。 不过, 仍然有一些经验可以说。

 

了解了一下, Nokia的客服分为1、2、3、4四个级别, Nokia规定,1、2级, 没有资格修核心部件出现问题的手机, 也绝对不许动电烙铁, 至少对于在保修的手机, 如果被1、2级给动了, 以后就别想保了。 对于不保修的, 很显然, Nokia不让他们动, 就是不放心, 千万不要贪图便宜个1/3,或者地理位置方便, 就轻易的把机子交给小的客服, 你给了他们, 动不动那是他们说了算的,多修一个多拿一份钱, Nokia也不可能把所有这些客服都管住, 事实上我认为它根本就不打算管。我不知道国内怎么分级, 但那种小型承包商承包的, 管它是几级也不能信。

 

至于大客服, 信口胡诌, 说实在的咱们也没办法, 可以换一家同样规模的再检测一下再说, 不过现在检测也开始收费了。 如果都胡诌, 那也最好就按他们胡诌的来, 能修好就得。 当然, 要是价格太贵, 我看就只当废朔料一块就好了。

 

最终, 我买了一个万用表, 一套改锥, 准备有空自己动手, 丰衣足食了, 毕竟咱也是干IT的。电烙铁没买, 因为我手太笨,如果需要处理BGA的焊接,又完全不可能准备工具; 这个活看看附近有没有手细的,同样属于弱势群体的维修工(NB的我是不敢指望了), 让他们代劳吧。 妈的这都赖我自己, 不搞应用搞研究, 弄得手头紧, 不得不考虑修一下算了, 结果反而弄的窝窝囊囊。 如果过两天自己坏了, 或者让我折腾坏了, 最终还得买, 几百块的维修费就成了浪费不说, 更关键的是我宝贵的时间和心情。

 

再说一个怪事。 买了两条1G内存, 芯片不一样, 家里还有4条512, 两条现代, 两条三星。 换成1Gx2, 512Mx2,如果是两条相同品牌的512,居然过不了自检, 反而是一条533的现代, 一条667的三星, 配合这俩不同芯片的金士顿, 一点问题也没有, 真是彻底折服了。

 

最近流年不利, 我得小心点, 别再碰见什么乱七八糟的情况了。

 

Update:

突然发现,似乎我的音箱也要完蛋? 我到底是怎么了....

 

http://vse.guangztr.edu.cn/radioschool/bga-cjx.htm


Update:

有一件事忘了写了,本来去中关村那天一冲动, 想买N78或者6220c的港行版, 正好原来在网上查到两个商家, 号称绝对是真的, 我就去看了; 差点买之前, 我女朋友建议到一个刚认识的卖配件的哥们那里上网再查一下,结论如下:

 

中关村绝对(意思是101%)没有卖真港行的,但是他们现在确实越做越真了。 比如过去说HKC的标, 假的中间缺少两个横线, 现在大的HKC假标签已经有了。 比如我看的第二家, 网上说的“Nokia Care”的标是应该有皱褶的, 他们也有了, 而且印刷相当强悍, 比真的做工还好; 港行的发票,过去网上说是针打的,他们现在也换针打了。

 

至于哪儿还不够细心, 这个我就不想多说了, 早说一天, 他们早改进一天。 建议大家看看淘宝上的香港人联诚阿井那里, 虽然我最后打消了买手机的念头,但是如果再买港行手机,已经认准他了;据说购买后香港那边商店活动赠送的礼品都不会少的。 如果在村里买, 就买亚太版的或者后港的, 确认配件是真的就可以了。 至于我说的这两家, 初步判断, 他们的配件应该是真的, 但是价格比亚太或后港贵300左右。

 

关键在于, 如果冲着全国联保去的, 我们就无法保证假Nokia Care和假发票客服永远不会仔细验证。 在Baidu上查询中关村保证百分之一百港行的,一共出来的就那两家在大型IT网站上的商家页面,弄这么真的北京没几家,也不容易(可惜做事的素质低点,行百里而半九十), 具体名字我就不点了。

 

希望这些信息对大家有用。

posted @ 2008-08-16 03:03 怪怪 阅读(775) | 评论 (15)编辑

回帖整理和其他一些想法

原帖

 

Borland C++ 3.2? 只用过3.1, 还装过4.0和4.5,但没成功: 最初我家机器的4M内存有一位是坏的, 4.0以上的版本不能正常运行。

我最怀念的VB版本则是3.0~ 另外,自从Visual Studio出了1.5以后, 基本就没再碰过Borland的东西了~

虽然年纪可能比老兄小,我从那个时代过来,到今天也已经十几年了, 也不过是个初学者。 和老兄也许有所不同的是, 我当过一阵子张嘴某某方法论、 闭嘴框架式解决方案的人。

但是有一点我是很清楚的, 真正走过来、 回顾过去, 就发现, 95年之后东西, 与其说是给程序员准备的, 不如说给工程人员而且可能更多的是给*不合格*的工程人员准备的:

这是为了提高他们的效率,防止他们作出不恰当的事情。 真正的程序员的需求, 就不是大中小型商业组织和出版商最关心的事情了;当然这也是因为,好的程序员总能快速的自给自足。

变的其实不是真正的技术, 而是基于那些技术构造的工具; 而工具玩家当然也自有其乐趣。 最苦的就是两边不靠或都靠的人了,过去他们是第一代被争取的对象, 现在却被遗弃了。

我至今还记得, 十几年前的毛毛细雨中,一个人骑自行车十多公里去中关村带着特有异味的胡同中买盘的情形。 之所以每次都去其中一家, 很大程度上还因为那儿有一个漂亮的小姐姐....

现在那片平房先是被海龙、接着被一系列大楼占领了,而我唯一喜欢过的市场,海淀黄庄的中关村电子配套市场也不在了。

时代真是变了...

 

 

个人总结及多余的话:

 

近年来,对我最大的一个影响应该是加入博客园了。 我在这里学到了很多,这不代表我想说什么恭维的话; 恰恰相反, 在博客园,我真正得到的、思考的、加强的, 恰恰是我的一切不认同。 而我之所以偶尔被骂, 也不过是因为, 我自己也不过仅仅是一个不那么合格的工程人员, 却试图给自己带上*真正的*的程序员的帽子,还要不合时宜的传播自己未必正确的价值观。

 

想想我刚来的时候, 一副“理智使用面向对象”的丑恶脸孔, 到后来因为不轻信的个性,对一些国外方法论开始初步质疑; 到今天, 我脑子里开始有一些模模糊糊但真实的概念。 一言以蔽之, Strustroup、Anders,这些是真正的程序员, 而Fowler和其他一些明星则是好的工程人员; 前者的工程能力我无法了解; 但如果管后者叫程序员, 毫不客气的说, 是对程序员的侮辱。

 

这是我第一次如此极端的表达一直吞吞吐吐的观点。 又有几个真正的程序员会不了解, 比如对于类似“用测试也可以充分保证正确性”这样的可笑言论, 在30年前就被迪杰斯特拉轻描淡写的一番话,科学的、根本性的枪毙了。诚然,真正的程序员也必须向当前有限的手段妥协,而求助于工程上的解决之道; 但是他绝不会通过强调工程、人文的考虑, 在谬误上建立自己的阵地。

 

这看起来我还在执着于人与对错, 其实它表达的是,如何就我们面对的这些信息进行一个相对正交、且有一定严谨性的分类; 它同时还能指导我, 从不同种类的师傅那里,可以学到什么, 又应该小心什么。虽然我现在脑子中的部分结论还是支持我过去的一些臆测, 但其意义已经有所不同了。这个成长过程,固然和我浪费了大量时间取证有关,但起点却是从质疑引发的讨论。

 

从现在开始, 我希望这一切和我无关。  我个人必须、也绝对有能力去施行很多工程上的做法, 同时, 我也不会轻易的被蒙蔽双眼;和其它一些方法论支持者、反对者相比, 我也可以确信自己是经过更多的调查与反思的; 总而言之, 知道何时、采取什么样的策略是相对有益的, 以及初步学会探测风险所在,这足够了。 再继续下去,只能是深入论证, 那实际上是缺乏建设性的。

 

当然, 否定一个极端不代表走向另一个极端。 我个人一直对纯算法的练习持相当大的抵触情绪, 我自己很少进行这种训练,并认为那是不切实际的。 大多数算法都是为了解决实际问题而诞生的; 但无论是针对这些算法的练习, 还是发散练习,如果占据了太多的视线, 对于“掌握算法背后的思想”这一目的来说,恐怕是边际递减的; 最终不但不能算法大成, 甚至可能走向反面。

 

在博客园, 我就各种问题跟不同的朋友争论过多次, 也和一些其它兄弟待过同一个战壕, 这对我是一个非常难得的经历。可最终我却发现, 也许就像上次“纸毛巾”同志说的, 我和大多数人, 也许很大程度上都不是一个路子的。所以无论我对别人, 别人对我, 赞同也好反对也好,恐怕在根本上都是鸡同鸭讲; 这个结论让我有些失落, 恐怕也会让一些把我当朋友的人失望。

 

一个正确的态度是什么呢? 我是来学习的。 很早我就说过, 曾经不屑于“深入XX”、“XX技巧”这些对手册二次消化的知识的我, 最终明白了, 如果没有这些资料的支持, 我个人也不可能在选择另一条路的同时, 可以快速的掌握任何一种工具的使用; 这实际上全是兄弟们的无私奉献。 而更广泛的, 对于一些我质疑的东西, 哪怕真是垃圾的,不用就是了, 又何必抱有抵触情绪呢?


总要有人把这些拿出来说, 我才能去判断好坏, 筛选出其中有利用价值的方法。 过去Allen Lee说,我的冲动来自于“权威”尤其是“伪权威”对独立思考的扼制, 不过从另一个方面来说, 别人认可流行文化不代表人家没有反抗的能力; 毕竟是另一条路上的人, 他们又能怎样呢?即使是对真相的漠视也自有其道理, 目的不同造成了选择的不同; 从人生的角度来说, 谁受了蛊惑还不一定呢。

 

也许我以后还会跳出去说些什么, 不过至少这一阶段, 已经结束了; 或者说我希望它结束。 该收收心了。

posted @ 2008-08-02 07:11 怪怪 阅读(1263) | 评论 (6)编辑

讲授“最后一课”的兰迪·波许教授去世

来源: 驱动之家

 

不知道是否有朋友观看过卡耐基梅隆大学的计算机科学、人机交互及设计教授兰迪·弗雷德里克·波许(Randy Frederick Pausch)著名的“最后一课”演讲并也为之感动,兰迪·波许教授已经于7月25日因胰腺癌在家中去世,终年47岁,在生命中的最后时刻妻子和三个孩子 始终陪伴在他身边。

 

2006年9月,兰迪·波许被诊断患有胰腺癌,尽管进行了手术和化疗,他还是在2007年8月被告知癌细胞已经转移至肝臟及脾脏,至多可以再生活6个月。

 

美国很多高校在资深教授退休前都会为他们安排讲授一堂面向全校学生的“最后一课”,表达学校师生对其的崇敬和感激,让教授为自己的教学生涯划上一个 完美的句号。卡内基梅隆大学将其命名为“旅程(Journey)”,希望演讲者能和听众一起分享自己的个人或学术旅程。波许虽然还没有准备退休,但是鉴于 他的病情,他在2007年9月18日做了题为:“真正实现你的童年梦想”的最后一课演讲。

 

在演讲中,兰迪·波许教授告诉观众永远不要放弃梦想,当面对困难时他说“但请记住,阻挡你的障碍必定有其原因!这道墙并不是为了阻止我们,这道墙让我们有机会展现自己有多想达到这目标。这道墙是为了阻止那些不够渴望的人,它们是为了阻挡那些不够热爱的人而存在。

 

以下是这段演讲的Google视频:video.google.com/videoplay,更清晰的带中文字幕的视频文件可以在:www.verycd.com/topics/267576/下载。

 

 

 

posted @ 2008-07-27 13:52 怪怪 阅读(184) | 评论 (1)编辑

文章推荐

http://space.itpub.net/14674535/

 

这个系列的文章深入浅出,表达能力不是一般的强。

 

我的感受呢? 如我这样关注这些话题已经有一段时间的人来说,主要是找不到新意和铺垫稍多; 但即使是这样, 我仍然得到了一次难得的重新捋一遍记忆和思路的机会;同时,在表达能力上的差距也给我上了一课: 不仅仅是写文章, 我们思考时, 第一个接受表达的对象就是我们自己。

 

强烈的表达一下我的推荐, 多的就不说了。

 

update:

Microsoft Visual Studio China Middle School Power Toy 1.0

 

 这个东西似乎给中学水平的人启蒙不错,现在的小孩真幸福。

posted @ 2008-07-26 05:12 怪怪 阅读(873) | 评论 (6)编辑

书单

除了对我现在做的事情有直接作用的书,外加一本数学玩物,一本YY读物,还有三本算法: 这个选择主要是因为《算法导论》,说实话, 无聊到一定地步了; 我想看的是大脑的活动, 而不是使用手册,手册虽然是必需品,但是读书讲究的不是这些。

 

书名
 [41119]  P2P网络技术原理与C++开发案例
 [38253]  编程语言:原理与范型(第2版)
 [26775]  算法引论:一种创造性方法
 [34357]  算法设计
 [967596]  ACM图灵奖-计算机发展史的缩影(1966-2006)(第三版)
 [18133]  深入理解计算机系统(修订版)
 [178655]  怎样解题:数学思维的新方法
 [9508]  如何求解问题——现代启发式方法

 

简要说明:

 

41119可以肯定是一本没什么太大价值的书, 作为一个纵观的了解, 省得费劲查些最简单的东西了;或者说, 查之前也会对过去的发展形势有个了解。

 

38253是脑袋的推荐, 我个人认为它对我的意义是速成: 了解该了解的, 防止在已经最成熟的问题上自己走弯路,或者干脆做了民科的工作。 这本书脑袋说翻译的极差, 已经退掉了。 另外,选则替代品的过程中,注意到了《程序设计语言原理(原书第8版) 》和《程序设计语言理论基础》,前者和脑袋38253有比较大的交集,作为所谓的“经典”,也很全面; 但是考虑到我自己的具体需求, 还是收了后者,可惜是本老书,新的进展不知从哪里可以看到。

 

26775的作者似乎现在是Google的首席算法师, 实际上这书我本来不打算买, 不过也不多这么一本啦。看在后面有些并行算法的份上,外加号称归纳证明和设计实现并进,看看有无新意吧。

 

34357在有些人的心里和《算法导论》齐名, 据说有一些启发式的作用, 又不是《算法导论》所擅长的枯燥罗列; 那就买一本试试咯,万一真能让我把一些东西读进心里去,那就真是大收获了。

 

967596没有什么说的, 纯属追星, 在此之外,则是用来培养自己的感觉, 感觉有时候是相当重要的; 本来想一起收的还有一本《来自圣经的证明》,不过考虑到数学和英文的复杂性一交叉, 我就玩完了, 算了吧。

 

18133估计意思不大。 但是看目录是一本非常全面的书, 对我辈软件人员, 该了解的东西, 找一本类似的书放在手边,没事瞎翻翻, 还是必要的; 既不过, 又不会不及: 更艰深的虽然不是说一定没有必要, 但要考虑到自己平时会不会打开。

 

178655既然那么多人说不错, 只当玩一玩吧。 其实不客气地说,个人认为大多数玩这些的软件人员都误入歧途了;不过我不会,我天生对数学具有高强的自我防御免疫系统 :P。

 

9508从目录上看,又是一个不是从具体算法如何做的层次关注这个方面的书; 希望作者的功力真能够对我这种白痴级读者作出一个好的引导。

 

最后多说两句。

 

我不认为这些书有什么了不起,任何一个想干30年技术而且能吃饱饭的,甚至想真正能从技术角度做好管理工作的,都应该看这些书, 而且一定能看懂。 Gates是一个“应该”的例子,M$的初期发展过程中,他作为技术决策者和管理者,虽然已经不再亲历亲为,可他不但知道一个软件该怎么做,而且知道实现一个功能,其难度和代价如何。

 

我自己是一个“能行”例子, 我曾经认为自己是计算机科学核心领域上的窝囊废, 最多搞搞工程和应用;但最终还是启蒙了,开始能看懂一些原来觉得是天书似的的东西了。我相信上面的书对我来说肯定还有很多“天书”成份, 但是我同样相信这些只是入门的浅薄学问,总是可以逐渐掌握。可能有人问了, 等你入门了, 啥时候才能有造诣啊?

 

我的一个体会是, 一旦跨过一道坎, 那简直就是天空任鸟飞, 海阔凭鱼跃; 等到真的修行看个人的时候,就不会有什么太大障碍了:一切唯实践尔。至于造诣,它虽然和天份不同, 但仍然是一个人自己得天独厚的东西;往往在我们完全没有接触过将会有造诣的领域之前,这个领域的造诣就具有了,所以根本不必担心:

 

关键是你是否挖掘了它。

posted @ 2008-07-25 07:18 怪怪 阅读(1030) | 评论 (7)编辑

喧嚣

过去两到三个月,一些总结是有的, 但很难说有很大进步,这是不得不意识到的。

 

从状态上来说:


1. 基本放弃了自我管理。

 

2. 目标对我来说似乎也没有威慑力了,毫无紧迫感。

 

3. 不能说毫无意义, 但确实一点也不充实。

 

从技术上来说:

 

1. 除了少数想法算一些整理, 没有悟到更多东西。

 

2. 一些地方反而过于热衷于言语, 而放弃了本质。

 

比如关于面向对象和其它范式的语言; 最早我就明白Anders说的“对象说到底不也是语法糖吗?”、“delegate就是函数式的全部了”, 但是实际上在这方面的思考并没有新的进展, 也包括对泛型、模板、元编程的体会上,还差那么一点点。

 

而对于“语法糖”这个概念, 不要光停留在表面理解, 类似于面向对象的非本质性, 对我个人来说,已经无需再讨论。相反,delegate并没有把C#变成强大的函数式语言,恐怕在于类型系统的配合度还不够,所以delegate在C#中就很容易表现的像个语法糖。作为具体的议题,后者是一个还存在模糊的地方,而我缺乏深思。

 

关键在于, 哪些东西不是语法糖; 这个地方我没有好好的把握住。 抓住这一点, 在设计和实现时就不会被迷花了眼, 在语言的学习和设想上, 也能更加的击中要害。 再重复一遍,哪些东西不是语法糖?界限在哪里?

 

实际的产品开发,也要重新进入轨道。最近缺乏实践的带动, 而在此之前, 对Web框架的理解,对各种编程范式的理解, 从经验上来说,都是被实践带动的。所以重新回到根本,即便对于高一层次的研究, 也是必要的了。

posted @ 2008-07-23 06:17 怪怪 阅读(949) | 评论 (6)编辑

资料收集

基础资料:

 

用来增加背景知识的资料:

 Why Gnutella Can't Scale. No, Really. 

(待更新)

 

可能需要了解的资料:

 

非结构化:


“Mobile Agent based Method”,这个想法初步感觉有点爽,和我的想法有相似性,找点文章来看。

 

Cache Method”的当前样例中, 有啥有新意的细节可以挖掘没有?

 

结构化:

(待更新)

 

实用资料:

 (待更新,这部分恐怕比较难找,可能还是得看代码。)

 

初步的想法, 实际上P2P网络的问题, 可以集中于两点:

 

1. 检索。

 

2. 有效。

 

关于1, 结构化的方法, 一般都是将内容与某一节点做一个映射, 信息提供者向这个节点汇报, 而信息查询者从这个节点获取。 同时, 这个节点的存在和同一,是通过“我们处于同一世界(物理上、时间刻度上)”这一事实来保证的。 除了实现细节的各种调整与优化之外,是不是真的没有改进的余地了?或者说,除了上述事实, 还有什么其它可利用的条件呢?

 

关于2, 分布式计算看似高端,其实反而可以含糊,因为只要不涉及远端计算机提供信息, 尚可以本地计算, 最终对一个可分解的计算来说, 仅仅是计算时间的问题; 信息传输要求稍微高一点,因为只要损失超过一定程度, 整个信息就是无用的; 而连续性播放则是比较难,但目前可以通过特殊处理解决。当这几者混合应用时, 问题可能会变得更加复杂一些: 多个部分的不同安排,可能导致可靠性在时间上的变化。

posted @ 2008-07-21 23:36 怪怪 阅读(750) | 评论 (1)编辑

交朋友的学问

交朋友这个事情是这样的, 咱们自己确实得努力, 否则有点水平的就不会倾向于和咱们建立关系。 不是别人骄傲, 而是如果交一大堆朋友, 用于交流的时间又有限, 到时候反而不知如何处理,得罪哪一个也行不是。

过去我玩Q3, 如果我在服务器里打的表现不错, 很多就要加我; 开始我是不会拒绝的, 但是QQ上人多到一定地步, 我开始没法弄; 最后即使我加了别人, 也不代表我会和他说话, 因为我必须隐身而且装的跟真的不在似的, 否则就别干别的了。但是我也有类似于全国前三那样的朋友, 为什么呢? 虽然我打不过他, 但是我有一些特色, 再练习中能够帮助他们提高。 这个开始我也不懂, 后来其中一人写文章和聊天时提到,我是他提高的三个阶段的最后一块踏脚石, 比如我的身法非常好,我才逐渐明白。

交朋友还有一些其他学问, 比如有一些人, 他即使不认识你, 你也可以把他当朋友。 比如对于我来说,这些人就是像Martin Fowler这一批。 当你把他们当作对话的对象, 你自然会提升的很快。 基本上, 在自己感兴趣的领域, 挑这么几个朋友, 所有你感兴趣的话题, 你都可以和他交流一阵子,Email吗? 不是, 就是很简单的他写过什么文章, 说过什么我怎么想; 我有什么看法,在同样的问题上, 他又怎么看。 在水平还比较初级的时候, 这种交流可以持续很长时间而且够用;真正的朋友能起的作用不也就是这些吗?

但是不要把那些真正高山仰止的人物当朋友, 因为说实在的, 没到一个级别, 根本无法做出这种交流。如果硬要上, 这样完全单方面的信息流, 会整个的毁了我们, 最后让我们彻底成为他的手下败将: 没有自己的想法, 只知道重复。 当然, 也许Fowler是我的朋友, 但还不是你的。 也许Anders已经是你的朋友了, 但还不是我的。 这完全取决于一个人和“目标朋友”的相对差距; 对这种人, 我们要承认他们是你我绝对意义上的老师, 但永远不要忘记一句话, 吾爱吾师, 但吾更爱真理。 总有一天, 老师变成了朋友, 虽然这不代表我们到了他那个级别, 但也有所小成了。

配合上面的“虚交”, 得到一些提高以后, 获得一些真正有联系的朋友, 也就是很快的事情。 因为人家会发现, 对他感兴趣的领域, 哪怕你还不是太够格, 但是也有一些自己的理解。 这样这些真朋友, 会愿意传授给我们他们的东西, 以期我们进步的更快一些, 也能回报给他们一些信息; 甚至我们暂时还不能给出回报也是有益的: 当他给你开讲的时候, 他也就获得了一次整理自己思路的机会。 但是, 绝对没人会愿意给一个完全不入门的人讲上好几个小时, 除非他打算去学校当个老师。

记住,最好的朋友是实力比我们高出一截, 但不至于太离谱的; 这包括真朋友和YY出来的朋友。前者一般是在一个数量级以内的,否则有联系方式也没用;后者的水平可以和你差距一个半数量级, 但不能更多了。在这之外, 交水平比自己低的朋友也是有益的, 标准基本上就是把上面的反过来; 但这一般是下意识就能做出的判断, 就不多说了。

posted @ 2008-07-18 14:03 怪怪 阅读(968) | 评论 (11)编辑

不需要强类型, 需要强测试?

     摘要: 这是Joel的观点, 据说, Bob大叔也是这个观点。 他们认为编译器的检查, 实际上就是编译期的测试。 而且他俩, 据说都达到了“测试成瘾”的境界。这就是说,他们抛弃过去对检查、尤其是静态检查的信仰。

Joel本人也曾一天到晚的思考, 是不是有一个最佳的方法,可以尽量少的付出代价, 尽量多的得到不同做法的优点; 不过他、Fowler、Robert Martin, 似乎已经都放弃了, 他们放弃的对吗?  阅读全文

posted @ 2008-07-18 06:19 怪怪 阅读(2238) | 评论 (21)编辑

一些待解的疑问

想了想, 还真不知道拿什么题目起头。 这样, 从以前的文章开始好了。

为什么OO是有本质缺陷的?


这篇文章中的疑问首先有这么一点: 静态语言中,我们如何能在改变一个系统内部接口的时候(注意, 不是对外发布的, 所以没有不能更改的问题), 只更改一处就解决问题? 比如最简单的, 一个类, 有Name属性, 是string的, 它对应某一个数据文件里的类似于表中一列的信息。 改变数据文件的结构,新添加了一个叫做Description的记录信息, 一个内部实体也增加了这个属性,我如何做到不修改从数据文件中读取, 和写入数据文件的代码呢?

毕竟, 这两个属性对这个数据文件的读写, 是没有什么差别的。举一个对比的例子, 在C++中, 我可以这样:

namespace fields
{
    
struct name;
    
struct age;
    
struct code;
}


typedef map
<fusion::pair<fields::name, std::string>, fusion::pair<fields::age, int>, fusion::pair<fields::code, char> > person;

使用时,我们这样使用:

person a_person;
at_key
<name>(a_person) = s;
at_key
<age>(a_person) = i;
at_key
<code>(a_person) = ch;

事实上, 这是使用fusion,稍微更改一下形式, 就可以变成这样: a_person.p<name>, a_person.p<age>。如果碰见变化, 修改一下typedef即可。 而我操作person的代码,只要其本身的逻辑没有变化,就可以做到一字不改; 因为我可以通过获取map中所包含的类型定义携带的信息, 直接写一个统一化的过程, 进行所有操作。 而如果使用OO, 第一个可以想象的就是, 每一个倒腾数据的逻辑, 无论是从哪儿到哪儿, 我都得加上对该属性的操作。

这个最大的好处是,只要在本质上是相同的过程, 我们只用写一遍。 另一个好处是, 我们同时具有静态语言的全部优势: 比如没有定义和包含description的时候, 无论你是at_key<description>,还是a_person.p<description>,根本就不会通过, 这样在非常大量的这种工作, 比起Dictionary和动态语言, 我们就可以避免大量的失误。

我想, 这个问题不能简单的用“很少有人用”来回答,因为它是结果。 首先它是方便的,而且方法名、属性名这种给人使用的死标记没有的缺陷它也没有。  那么我认为,没人用更多的仅仅是因为, C++和另外那些支持这种非OO范式的静态语言,其它地方太烂,是首先否定了语言上的选择, 所以也就没人在实体上使用这种设计和实现的方式。

当然使用Dictionary就痛快多了, 不过强类型带来的保障没了,这是不是缺陷呢?还可以使用反射完成相同的功能, 然后付出性能, 在我看来,这个性能就是缺陷的证明; 比如: 数据源是数据库, 那么有的ORM就用反射完成类似的工作, 但ORM的存在,反而证明了需求的存在。而且在ORM覆盖范围以外的数据复制和转移呢? 性能问题, 我们可以通过Emit来解决, 但Emit不是适合于所有使用情景; 而且, 我们就必须编写和调试大量的Emit代码, 额外的设施的使用和多付出的工作量, 也是缺陷的证明之一。

毕竟, 这些信息本来就是运行前已知的, 而且他们是有规律的, 也就是可以通过某种形式在运行前处理的, 同时可以通过合理表达自动化的。某人嘴里的“孟老头”对这个事情有他自己的理解, 现在就看某人的啦: 这是不是OO的缺陷?

posted @ 2008-07-17 12:16 怪怪 阅读(172) | 评论 (18)编辑

我来当个小人吧, To 关心博客园精华集的人、包包和搅风搅雨的人

     摘要: 现在我们所有人, 包括dudu、编委会成员、 出版社提供参考意见的同仁、 广大园子里的朋友, 首先要确定的一件事就是, 这些书应该是什么形式的? 也许甚至不同的分册不同的形式, 一切从实际出发。

除此之外,再无其它和人相关的冲突和矛盾。 再有人就这次具体事件, 针对某一个人或者牵扯进来的其它主体, 那就是找抽了。  阅读全文

posted @ 2008-07-17 03:34 怪怪 阅读(3139) | 评论 (139)编辑

两个过去的心得, 外加一个回帖整理

     摘要: 写程序、做设计是一个边学边干的活计,有一个著名的调侃, 就是如果程序员盖的房子, 你敢住吗?

广泛的掌握面向对象的手法, 但不要因为自己学了什么就给自己下套子, 那和屁股决定脑袋差不多。 学的这些东西是备用的, 大环境让我们必然能够用得上。 与此同时, 根据需求出发, 当自己有强烈的感觉, 某个学习过的东西, 能够解决当下的问题时, 再去试着应用。有的剑, 出鞘越少越好。

散文一篇, 不喜勿进。  阅读全文

posted @ 2008-07-15 05:56 怪怪 阅读(2360) | 评论 (22)编辑

WebResource备忘

已经不知道多少次掉进这个坑了....,一段时间不用就忘, 每次都得耽误半个小时。 这一方面说明, 这个功能的文档配合的不够好; 另一方面,真应了那句话,好记星不如烂笔头。

这就是: 资源文件, 如果放到目录里, 编译以后会被加上目录名....,这其实是必然的: 否则不同目录的同名文件如何处理?写到这,又推翻记性或者笔头的用处了。 因为这个事情太简单, 我反而没有琢磨这么基本的一个道理, 导致不能够在“哟?怎么回事”以后马上判断出是什么情况。不过这事也难说,也许我已经按这个思路想过, 不过还是没记住。 所以还是应该有做笔记的习惯。

顺便说点其它的。 Tag和Category这两个东西, 按理说本质差不多, 但这是一个朝三暮四的故事。 关键是你鼓励用户怎么做。

很多人认为Tag是随意的、即兴的,所以是私人的。 其实正好相反。 Tag其形式鼓励用户随便填写几个相关的短词,结果正是因为这样, 反而造成了不同的人写下的词可能是共同的, 于是这就变成了一个社区的、公开的、交流的、 把人和人、内容和内容相关到一起的公众的东西。仔细观察互联网用户,就会发现, 那些更加懂得如何*在互联网上*交流的同志, 会更多的用Tag,而且用的很准; 而比较嫩或者比较老的网民, 就会瞎写或者不写; 但即使瞎写, 也能增进和其它内容制造源的联系。

而Category鼓励用户仔细的去设置分类, 所以反而会突出人的个性。 比如同样对旅游这一件事,对A意味着很多内容, 对B也意味着很多内容, 哪怕这些内容大部分是重叠的, 仍然会因为不同的部分, 产生不同的Category表示方式, 结果这就成了两个分类。 而整个社区如果设置了分类,也仅仅是从网站出发,属于网站的个性为网站本身服务。假设一个网站有三种分类方式: 个人Category、全站Category、Tag, 这看起来完美, 但是会让用户最后哪个都不填, 因为太麻烦了。

当然, 真正实现Category和Tag的时候, 可以让它们产生极大的不同, 但即便是设计者, 实际上也是以“如何给用户一个导向”为导向的。 如果Tag本身能够组织, 形成图, 其实是一个非常有意义的事情, 不仅仅是相关性, 而是各种可能的关系都可以形成组织。 Category本身也可以极其强大, 而不仅仅是树状的模式。

实际上,一般的设计者区分两者的手段, 就是根据预期的导向,让其中之一在某些方面较弱, 而另一个在其它的方面较弱。 如果两个都强大到极端, 那么可以肯定功能是相似的。 但真正想清楚这些问题, 就会发现没有必要通过故意的功能性差异化去在系统内部作出区分。

只是在这个“两个都达到最强”的状态(或者可能是干脆基于一套内部模型的状态),反而要加倍注意用户导向的问题,这个时候可以通过界面、提示、交互方式等表面的东西来做出区分。 否则用户将会觉得迷惑和繁琐, 以至于放弃这些功能, 这对社区的组织者和内容发布者,都是一个损失。

还有点其它的本来想写, 不过还是别浪费时间了。 STOP。

posted @ 2008-07-12 09:45 怪怪 阅读(337) | 评论 (0)编辑