Skip navigation.

<m::Sharp />

I use a mac.

Posts tagged with "Programming"

体验时代的基本法则

摘自MR.Y's Blog

Andreas Pfeiffer写的" WHY FEATURES DON'T MATTER ANYMORE: THE NEW LAWS OF DIGITAL TECHNOLOGY",从用户体验角度强调了功能并不在重要,重要的在于用户对产品或服务的体验,并列出十大法则,"10 fundamental rules for the age of user experience technology",

在这个时代里10个基本法则是:
1、更多的功能并不好
More features isn't better, it's worse;

2、增加功能不会让事情更容易
You can't make things easier by adding to them;

3、让用户迷惑是毁掉业务的终级手段
Confusion is the ultimate deal-breaker;

4、风格很关键
Style matters;

5、只有在一项功能可以提升用户体验时才加上它
Only features that provide a good user experience will be used;

6、任何需要学习的功能都只会吸引一小部分用户
Any feature that requires learning will only be adopted by a small fraction of users;

7、无用的功能不止是无用,它会破坏易用性
Unused features are not only useless, they can slow you down and diminish ease of use;

8、用户不会关心技术,他们只想知道产品能做什么
Users do not want to think about technology: what really counts is what it does for them;

9、忘掉关键功能,关注最重要的用户体验
Forget about the killer feature. Welcome to the age of the killer user-experience;

10、简洁很难,因此少就是多
Less is difficult, that's why less is more。

脚本编程人员的绝佳伴侣:TextMate

,

尽管发过了Keynote的牢骚,平心而论苹果上的软件相对PC来说还是很有吸引力的。比如下面这款软件吧:

TextMate

官方链接为:http://macromates.com/

这个软件是个文本编辑器,功能不算非常强大,但是都非常”贴心“!先上张截图。:wink:


可以从图中看到,除了普通的文本编辑器功能(语法分析,高亮显示当前行,行数,是否word-wrap,文字是否smooth等等)之外,这个编辑器还能根据语法对代码进行折叠。而且可以选择全部折叠/打开或某一级的折叠和打开。

可想而知一个1000多行的代码如果经过折叠以后会是多么清晰。效率自然没的说!:cool:

如果这编辑器就这些能耐我今天也不至于这么给大家推荐。

还有啥呢?

个人认为最贴心的功能就是"Project Mode”了。它可以允许你用当前正在编写的项目(实际上就是保存软件大量脚本的文件夹)导入该程序,以“项目”的形式进行管理。而这方面最大的优势就是,你在编辑某个文件时,可以在左侧清晰地看到整个项目的目录树,而且可以直接从那里打开文件,有效避免了在Finder和编辑器之间的频繁切换。更强的是,可以直接输入文件名,程序会自动提示你可以选择的文件,那是...相当的快啊。
废话少说,给截图先。


项目模式的截图


在项目中快速搜索文件并打开

唯一美中不足的是此编辑器仅⋯⋯支持等宽字体。这说明,我也验证了,不能支持中文。如果写了中文(双字节文字)⋯⋯就跟麻花儿似的了。

这唯一的不足实在是扫兴。我已经和作者联系,并将此问题提交给他了。应该不是什么很困难的事情吧!!!!

关于此软件的评测将不断更新...

文本数据库?

从开始学习php就开始了文本数据库的研究。

直到现在仍然关注着;-)

个人认为轻量级的数据应用,还是文本数据库有着不可替代的优势!

这里贴个网上搜来的“设计思想”



其实我个人是挺反对这个方案中的一个数据库在一个文件中实现这个想法的。

固然,把数据库分到若干个文件中去必然会降低效率。因为牵扯到文件系统了嘛

但如果使用一个[缓存+索引]的算法,似乎可以很大程度地弥补这种性能上的不足

而在稳定性和扩展方面也会有比较不错的优势。

Web 2.0 编程思想

,

[转载]

1、在你开始之前,先定一个简单的目标。无论你是一个Web 2.0应用的创建者还是用户,请清晰的构思你的目标。就像“我需要保存一个书签”或者“我准备帮助人们创建可编辑的、共享的页面”这样的目标,让你保持最 基础的需求。很多Web 2.0应用的最初吸引之处就是它的简单,避免并隐藏了那些多余的复杂性。站在创建者的立场,可以想象Google的几乎没有内容的主页,还有del.icio.us的简单的线条。从最终用户的角度来看,与之齐名的就是Diggdot.us所提供的初始化页面。你能够并且希望加入更多功能,但是先做好最开始的。在一个时候只做一个特性,完成一个目标。这听起来很太过于单纯化了,但它将使你更加专注,而且你也会明白我的意思。
2、链接是最基础的思想。这就是我们称之为Web的一个理由。链接是把Web中各种实体连接起来的最基本的元素。你的信息、你的关系、你的导航,甚至是能够被写成URL的任何内容。这里有一个链接应该遵循的规则(其实你也不必严格的遵守):

1. Web上的任何东西都是可以被URI或者是URL所连接的。
2. 把所有的链接都保存为他的原始出处,这样可以让你与任何人、在任何地方、任何时候都能分享它。
3. 第二条中任何时候的前提是链接必须是持久的,它不会在没有任何缘由的情况下被改变或者是消失。
4. 链接应该是人类可读的、稳定的、并且能够自我诠释的。
3、数据应该属于创建它的人。是的,你听我的。任何用户创建的、 贡献的或分享的都是他们自己的,除非他们很明显的放弃这个权力来让你自由处置。他们贡献到Web上的任何信息都应该是可编辑的、能被删除的、并且能够取消 共享,无论在任何时候,只要用户愿意。这也包含了那些间接的数据,像他们所关心的记录、日志、浏览历史、网站访问信息,或者是任何可以被跟踪的信息。所有 的网站必须清晰简单的陈诉那些信息是用户创建的,并且提供他们停止创建的方法,甚至是清除的方法。

4、数据优先,体验与功能其次。无论它是文本、图片、音频还是视 频,Web最终还是把这些解析为数据。换句话说,你无法脱离数据去呈现内容。所有这些数据都通过那些易于发现的URL来定位(参见第2条)。通过另一种形 式来看待这些,Web最终是名词优先,动词其次,虽然最近正在向动词偏移。来看看名词的例子:日历的条目、家庭照片、股票价格。还有一些动词的例子:定一 个约会、共享一张图片、买一份股票。

5、做好积极分享一切的准备。尽可能的分享一切,你所拥有的所有 数据,你所提供的所有服务。鼓励不遵循原有意图的使用,提倡贡献,不要那些需要分享的内容坚持设置为私有的。在分享与发现之后,提供易于使用的浏览方式是 显而易见的需求。为什么呢:话说回来,你会从别人的共享之中受益匪浅。注意:这里没有许可让你去侵犯版权保护的法律,你不能够去分享你刻录的DVD或者是 拥有商业版权音乐,因为你已经同意不会去分享这些东西。但是你可以发现并分享那些完全开放的媒体内容。一个小小的建议,你可以学习一下Creative Commons license(共创协议).

6、Web是一个平台;要让它成长。当然,我们还有很多其他的平 台(Windows、Linux、Mac),但是那些已经不是重点了。换句话说,Web是无法脱离的平台,不会中断的平台,你可以通过各种方式去扩展的平 台。你在Web上提供的数据与服务将会成为Web一部分,最终你会在Web平台的某一处扮演你的角色。扮演好你的角色并照顾好后来者。

7、理解与信奉“阶梯性”。现在的Web越来越大,几乎蔓延到了 全世界的所有国家,并且已经拥有了10亿用户。我的观点是Web的各个组成部分存在着细微的区别和不同,就像不同地方的用户那样。例如Web的设计部分: 易用性永远优先于速度、可靠性、重用性与可集成性。你也应该提供同样的体验给你的用户。它已经被一次又一次的被人们在文档中强调,忠诚的用户很快会成为专 业的用户,他们期待更快的速度还有更多。退一步支持他们。同样,也有很多很多的用户会进入这个阶梯的底端,如你所期待的那样。他们可能不会说你的语言,不 熟悉你的文化,甚至不知道是如何到这里的。所以你需要向他们表达清楚。

8、任何东西都是可编辑的。或者是它应该被编织的更好。要确定的 是,只有很少的东西是不能被编辑的,剩下的都可以,这是一个可写的Web。这并不意味着原始内容的丢失,而通常被理解为用户能够很容易的对内容加以评论, 或者评注内容是在那里发现的。如果你对此应用的好,他们能够比你所想象的做的更多(把内容串起来并且给予原始内容来创建自己的,等等)。

9、Web上的身份是神圣的。不幸的是,这并不意味着你能够得到 更多的隐私(这完全是上个世纪的想法)。但对身份的验证是必要的,你应该感谢那些只需一个邮件地址就能确定你身份的服务。这意味只要你对你的用户承诺了, 你就必须保证他们的隐私安全。必要的时候,在这个世界的某处你还得为你的用户挺身而出,向当地的权威挑战。如果你没有打算那样做,你就得把实际情况告诉你 的用户。另一方面,如果身份是必须的,不要试图伪装它,不然在某一天我们将会在Web上放弃我们的最后一点点隐私的权利。

10、了解流行的标准并且使用他们。从一个消费者或者是创作者的 立场来看,数据将会以不同的格式与任何一个人交换。同时这样的数据也会反过来促进标准的完善与采纳。这通常意味像RSS、 OPML、XHTML、Simple XML、JSON等简单标准的流行,而避免SOAP、XSD,还有RDF、ATOM也一样,使用它们会给我的内心带来痛苦。请你也为你所钟爱的标准投上一 票来支持它们。

11、遵循无意使用的规律。如果你把非常有趣的数据和服务用广泛 使用的格式开放和共享出去,你将会得到你所应得的,其他人也将会基于你的那一块Web平台来构建。或许还会从别人那里得到更多,所以为这个做一下准备比较 好。我已记不清有多少次我看到一个播客(podcasting)服务因为流行过渡而导致服务垮掉,就是因为他们被 Slashdot和del.icio.us给收录了。这一点要知道:网络上的大量化意味着如果一个内容非常有趣,即使是一个很小的角落也会得到惊人的访问 量。鼓励使用这种方式,它还是非常有价值的,前提是你要有所准备。

12、粒化你的数据与服务。我们应该在很早以前就明白这些,大规 模集成的数据仅仅适用于无需管理的下载与批量操作。分解你的数据,让他们独立成可描述的URL地址,对你的服务也一样。反过来说,你不要创建一些巨大的、 复杂的、像圣诞树那样的数据结构和服务。保持简单,要非常的简单。让这些分离的片断能够容易的被重组和发现。

13、提供用户能够单独受益的数据和服务。渐渐依赖于这种社会化参与是存在风险的,你需要让你的用户有一点点动机来贡献时间、热情和信息,除非他们能够直接受益。社会化分享比个体行为的利益大很多,除非你能够激发用户的个人动机,否这你将无法享受这份厚礼。

14、让用户组织并过滤信息。不一定是必须的,但却是非常重要 的。让用户以他们自己的方式来标注和组织数据,因为你自己是永远无法及时的处理他们的。用户会按照他们自己理解的最佳方式来处理并构建。要保证你的Web 服务能够按照用户所需所想的方式来工作。这也是标签(tagging)和通俗分类(folksonomies )的方式如此成功的主要因素。

15、提供丰富的用户体验。Web一直都在和本地的应用程序进行着激烈的竞争。为什么?因为本地程序还是感觉上好一些,速度也快一些。但是这不会长久的(确信在5年或者15年后,这种竞争就不存在了)。是的,我在谈论Rich Internet Applications, Ajax, 还有那些不可思议的交互应用。他们让Web成为了一个真正的“无平台”的平台,如果你知道我是怎么想的。

16、信奉并支持快速改进和反馈。这个通常意味着加快步伐,但也 意味着使用轻量级的工具、技术和不要做出那些适得其反的痛苦决定(例如使用一个被层层环绕的Ajax框架来代替可以通过混合来实现的,或者用C++来构建 所有的东西,其实使用Ruby会更好一些)。这同时也意味着需要一个非常快速的方式来处理错误报告,修复Bug,释放新版本。从一个用户的角度来看,报告 你所发现的任何问题,还有那些你经常抱怨的地方,甚至那些都不是一个Bug。

当然,Web 2.0是一个极其广泛和深奥的话题,没有一个人能够列举出它的所有重点和特征。如果你对此充满了兴趣,请花一点时间来补充我没有提到的地方。我想这就是Web 2.0的参与性吧!

防止CSS被CACHE

,

很多服务器供应商都有缓存设计~巨大的速度提升。但是带来的后果就是很多时候你上传的东西根本就不能被更新。无论你怎么费劲。

比如世纪互联就有类似的问题。

原有的解决方案在 Zeal's blog 有说明。

我的解决方案则稍微改动了一下,而优点则是:每次更新时所需要的修改工作更少,而对于静态,未更新过的xml及html文件读取效率则更高——不用每次都从源服务器读取数据。

对于xml和html等文件,链接后面加入该文件的修改时间

php中应如下实现:$link="http://youroldlink/xmlfile.xml?".filemtime("xmlfile.xml");

对于文件中引用的css文件,最好如下搞定:

... src='/themes/abcd.css?<?=filemtime("/themes/abcd.css")?>' ...

关于 Web 应用程序的 Framework...

,

这段时间一直在学习Web应用程序方面的知识,发现大量的framework均能很好地帮助开发者快速开发。

我对此方面还是一无所知,但是经过了一点点的了解,后来发现我自己很早以前的程序当中就使用了类似于framework的思想⋯⋯hoho。自我感觉思想蛮超前滴~

不过还是给大家推荐个新出现的framework:

Code Igniter
January 2010
M T W T F S S
December 2009February 2010
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31