-
"I Love" audio player
2006-08-23
下载的mp3越来越多之后,总想怎样才能将喜欢的与不太喜欢的区分出来呢。渐渐的有一个想法,就是在播放的时候统计自己的喜好。基本思路其实跟以前想过的“什么时候电视机可以变得聪明一些”差不多。
下面就设想一下这个音乐播放器应该是怎样的:如果觉得一首歌不好听/不想听,就跳过它放下一首。如果觉得特别喜欢,可以投一票。根据用户的动作,可以统计出对歌曲的喜爱程度。歌曲全都是随机播放,越是喜欢的歌曲播放出来的机会会越大,但是其它歌曲也会偶然播放出来,不会永远埋没起来。原本喜欢的听多了后也许会有点腻,没关系,不想听就跳过好了,播放器会不断“学习”你的喜好。只要曲库里有足够多的歌曲,总能保证听到的大部分都是喜欢的歌曲。
假设要开发这样一个软件,就叫它“I love”吧,将它的功能用user story描述出来,应该有这些(还可能增加好多):
title description priority 播放MP3 能够播放mp3格式的音频文件 最高 播放WMV 能够播放wmv格式的音频文件 最低 Copy profile 将现有的profile copy成一个新的profile 低 Switch profile 在软件中可以存在很多个profile,但只能有一个profile生效。所有对喜爱值的操作都是对当前profile进行的。用户选择一个profile,将这个profile设置成为当前active的profile。切换profile时不停止当前歌曲的播放。 中 I like it 当歌曲正在播放时,用户按下“I love"按钮,将这首歌的喜爱度增加一个数值,如果同一首歌,用户再次按下,忽略这个操作 中 Don't like it, next 当歌曲正在播放时,用户按下“I don't like it"按钮,停止播放这首歌,并且将这首歌的喜爱度减少一个数值。然后[随机播放下一首歌] 高 歌曲播放结束 如果歌曲播放到结尾,并且在这个过程中用户没有按下过”I like it“按钮,将这首歌的喜爱度增加一个数值。然后[随机播放下一首歌] 高 随机播放一首歌(shuffle) profile是保存了所有歌曲信息的一组数据,每首歌曲都有一个喜爱度的值。从profile中按照喜爱度加权来随机的挑选一首歌来播放,歌曲的喜爱度越高,被选中的概率越大。 最高 暂停/继续 当用户按下”暂停/播放“按钮,暂停当前歌曲的播放;再按一次,从上次暂停的地方继续播放。 中 Rename profile 中 程序启动 选择最后一次使用的profile,如果配置为”启动立即播放“,[随机播放一首歌] 低 显示歌曲信息 显示当前播放歌曲的信息,包括歌名、专辑、艺人等 中 off-line media library 将off-line媒体库(例如光盘)的曲目也加入profile中,同步的时候按照喜爱度加权的原则随机copy一部分曲目到硬盘中,换掉旧的一些。 最低 只要把播放mp3、shuffle、don't like it、播放结束这四个user story实现了,基本就能用了;再将优先级为“中”也实现了,设想的目标就基本都能达到。
整个播放器的界面将会非常简洁:三个按钮:喜欢/不喜欢/暂停或继续,不喜欢(下一首)的按钮应该是最大的;音量控制;正在播放的歌曲显示。切换profile放在菜单里面。这些按钮都必须能够用键盘快捷键控制。
不过,我只是想想而已,真的去写这样一个软件的可能性微乎其微。媒体播放、用户界面这些都是我不熟悉的东西。不知道是不是已经有类似功能的软件?如果有就太好了。
这样的播放器其实更适合用硬件实现,上面这些user story可以完完全全在随身听上实现。不过,软件还有可能自己写,要自己做硬件的门槛就高多了。现在市面的mp3品种多得眼花缭乱,大部分功能都是一个样,有创意的厂商非常少。写下自己的想法后,上网查了一下,发现apple ipod shuffle和sony的walkman A系列有类似的功能,但从介绍来看都没有完全满足我的要求,不知道用起来怎样。在我看来,以下两点是最重要的:
第一是歌曲的喜爱度必须是在播放过程中日积月累的更新,而不是通过什么操作界面来评级。对于用户,只有最简单直接的操作:喜欢,按一下(可别要进什么菜单);不喜欢,跳下一首。我认为甚至不应该提供任何机会给用户直接更改喜爱度。
第二是需要有profile切换,在不同环境、不同心情下喜欢的音乐是不一样的,有了profile功能就可以独立累计喜爱度。Profile也可以用来区分不同的使用者。
也许过不了多久就会有这样的产品出现了,到时是不是要考虑买一个呢? :)
-
愤青与垮掉的一代
2006-08-20
在MSN上见到一个久没联络的中学同学,聊天中她说到我以前是愤青。我非常奇怪,怎么我变成愤青了?她说因为我听摇滚,所以觉得我是愤青。我只好跟她解释,“愤青”这个词在当前的语境中是特指偏激的民族主义分子。如今“愤青”一词含义已经不同于“愤怒青年”了,英文里用的也是专有名词fenqing,只用于chinese。愤青们是否听摇滚我不清楚,但我猜大部分都是不听的。
现在又时兴将80后称为中国的“垮掉的一代”。如果硬要这样套的话,也只好增加一个流行的前缀:有中国特色的。
近日在读《在路上》,很久没有读过这样的书了,好像回到了大学的年代。摘录豆瓣上的一段书评:
垮掉的那一代人已经老去,但不知道他们的精神是否依然?跟他们的迷惘相比,我们这一代人越来越像一群被圈养的行尸走肉,没有朝气,也没有感动人的生命之光。
在我的想像中,那个“伟大的时代”跟那些逝去的人一样,已经远远地离开,再也不会回来了。 -
Homebuilt bicycle trailer
2006-07-31
-
一刹那到底是多久?
2006-07-21
我们在表达非常非常短的时间的时候,经常会用“刹那”这个词,例如:刹那间的感动。如果有人偏偏要跟你较劲,问你“刹那之间”,那到底是多长时间啊?你肯定会骂他太无聊、钻牛角尖。
那就来钻钻牛角尖吧:
“刹那”来自梵文 ksana,
- 120 刹那 = 1坦刹那(tatksana)
- 60 坦刹那 = 1 腊缚(lava)
- 30 腊缚 = 1 牟呼栗多 (murhutar)
- 5 牟呼栗多 = 1 时 (大时,kala)
- 6 时 = 1 昼夜 (即1日)。
据此,可以推算出:1 刹那 = 1/75 秒 = 13.33 毫秒
看来刹那间的感动确实没有感动多久啊。
呵呵,不是我这么无聊去研究这些东西,是在维基百科无意中看到的。现在维基百科已经成为我除了google以外的另外一个重要的学习工具了,遇到不了解的概念,先去维基百科看看(包括中文、英文),再在google搜索。还有就是每天去看看维基首页的新闻动态、特色条目,可真了解不少东西。
-
Embedded script 初接触
2006-07-15
近年来各种编程语言如雨后春笋一般涌现出来,令人眼花缭乱。有些是已经有相当历史的近来得到了广泛关注,有些则是新创的但风头不弱于前辈。它们的名字虽然我很多都听说过,大概知道是什么样的语言,但也是仅此而已了。
这些新兴语言大都是动态语言,运行于虚拟机之中。而我一直都是使用C++/Java这些静态语言,这些新语言让我觉得很新鲜。在具有动态特性的语言中,我唯一熟悉的也就是PHP了,但是php给我的印象是方便灵活,但是显得零乱,缺乏OO特性,难以承担大规模应用。也因此我对这些语言就带有一点偏见,觉得“不够严谨”、有点“小儿科”。
由于所开发系统的业务逻辑的复杂和多变,让我们吃尽了苦头,寻找解决方案的一个思路是将业务逻辑控制分离出来,降低这部分修改的难度。如果要再进一步,就是要采用script来描述业务逻辑了,那么是设计这样一种script,还是有什么现有的架构可以重用?
将视野放开,可以看到动态语言在这方面得到了越来越广泛的应用,有好多新兴语言就是用来做embedded script的。在嵌入的脚本和宿主语言之间,数据可以传递,函数可以相互调用。因为我做的应用使用C++开发,因此我这几天看了Lua和Squirrel这两种用于C/C++的嵌入语言的资料,这两种语言目前主要都是在游戏开发领域使用,Lua比较出名因为魔兽争霸使用了它,Squirrel是从Lua派生出来的。先不考虑怎样应用于具体业务,单从语言本身来说,这些简单的语言给我印象不错,一些语言特征能够给编码带来很多方便,如function作为first-class value,table数据结构(关联数组),而我特别关心的是它们对coroutine(协程)的支持。
使用通用的script还是自己开发引擎,自定义script格式,这就看怎么权衡了。动态语言的语言机制强大而灵活,其描述能力是自定义的script难以到达的;但是通用、灵活往往也意味着复杂,自定义script专注于要实现的业务功能,往往比较简单,学习难度要低;自己定义script虽然要开发解释器,但是针对性很强,与业务紧密相关,使用通用script还是要考虑怎样来描述业务操作,宿主程序如何提供接口来结合起来,其实要做的事情并不少。
不过我现在对它们的了解还只是很表面,仅仅走马观花而已,观点一定是片面的,还需要进一步的学习。就目前来说,我对使用嵌入语言存在着这些疑问:
- 缺乏OO特性,如果是宿主程序是采用OOD的话,不容易结合起来,我现在已经很难想象一个大型系统如何能够不采用面向对象来实现了。(不过这个还是因语言而异,据介绍某些语言是具有很完善的OO特性的)。Lua支持基于原型的面向对象编程模型(prototype-based OO Modal),我对这种对象模型是持怀疑态度的,它并不完善,好多OO设计方法都无法实现出来。不过我必须承认我并没有深入研究过,也许还需要多些了解。[见附注]
- 与宿主语言的binding太复杂。不使用class应该还是挺简单的,但使用了class之后就比较麻烦了。使用嵌入脚本,就是希望让开发更简单快捷,如果因此又引入另外一种复杂性,那么优势就被抵消了。
- 怎样将通用的script用于针对性的业务?是不是宿主程序需要以例如API的形式提供一套接口?我现在还没有看到这部分,如果找到一些开源应用的代码来看看应该可以解答这个疑问。
- 性能始终是一个需要关心的问题
---
PS. 刚才网上花了不少时间读了关于面向对象的讨论和文章,看来我对于面向对象的了解还是相当片面的,只是局限在C++/Java语言对于OO的实现,而C++/Java是属于class-based OOP,单纯的用class-based的思维去套用prototype-based OOP得到的结论当然不合理。另外一个错误就是我将prototype-based和object-based混为一谈了,其实完全两码事,object-based model则一般不认为是OO。花点时间去了解一下prototype-based OOP和动态编成语言应该是值得的,起码可以开拓思路。



