【写了一半,一个手势向左,回到了上一页,写的内容全没了,我晶】
Submitted by gouki on 2013, July 3, 10:34 AM
【写了一半,一个手势向左,回到了上一页,写的内容全没了,我晶】
Submitted by gouki on 2013, July 1, 10:12 AM
jqueryUI库中提供了一些封装好的,性能也算是比较好的一些工具,比如排序:sortable
在做分类的时候,这个功能就有点好了,直接拿它来排序,但是大家都觉得sortable怎么提交呢?提交的时候怎么把ID和数据传过去呢?要知道这。。TMD只是一个li,连form都没有,怎么办?
其实也算是比较方便的
主要就那个sortable('toArray'),看了一下手册,默认是使用了id,所以偷懒的话,你就把你的信息扔在id里就OK了。虽然就html规范来说,id不能是数字,但是你可以自己组装,然后post过去的时候,再解析嘛。
就是这样简单
Submitted by gouki on 2013, July 1, 10:05 AM
说起来,提供API供客户端调用,已经都做了两年多了,这两年多里,辛酸泪一把,API上线后,随着客户端版本的不停升级,功能越做越多,API越来越复杂,这时候,你TMD还得兼容旧系统,一点点的累积,过了半年,一看,还有N多人在用旧系统,想死的心都有了。开新接口?旧接口就不管了?这也不是一个办法。。。
所以,看到这篇文章的时候,我转一下,顺便自己也学一下,别人说的不一定就是对的,偏听则暗,兼听则明嘛 。(作者提供的API和我提供的不算一致,但也差不了很多,原来。。。。都是两年多,被这两年折腾的吧?)
原文来自:http://www.biaodianfu.com/how-to-design-a-good-api.html
到目前为止,已经负责API接近两年了,这两年中发现现有的API存在的问题越来越多,但很多API一旦发布后就不再能修改了,即时升级和维护是必须的。一旦API发生变化,就可能对相关的调用者带来巨大的代价,用户需要排查所有调用的代码,需要调整所有与之相关的部分,这些工作对他们来说都是额外的。如果辛辛苦苦完成这些以后,还发现了相关的bug,那对用户的打击就更大。如果API经常发生变化,用户就会失去对提供方失去信心,从而也会影响目前的业务。
但是我们为什么还要修改API呢?为了API看起来更加漂亮?为了提供更多功能?为了提供更好的性能?还是仅仅觉得到了改变了时候了?对于用户来说,他们更愿意使用一个稳定但是看起来不那么时髦的API,这并不意味着我们不再改进API了。当糟糕的API带来的维护成本越来越大时,我想就是我们去重构它的时候。
如果可以回头重新再做一遍,那么我心目中的优秀的API应该是怎么样的?
判断一个API是否优秀,并不是简单地根据第一个版本给出判断的,而是要看随着时间的推移,该API是否还能存在,是否仍旧保持得不错。槽糕的API接口各种各样,但是好的API接口对于用户来说必须满足以下几个点:
而对于开发人员来说,要求又是不一样的:
如何做到以上几点,以下是一些总结:
1、 面向用例设计
如果一个API被广泛使用了,那么就不可能了解所有使用该API的用户。如果设计者希望能够设计出被广泛使用的API,那么必须站在用户的角度来理解如何设计API库,以及如何才能设计出这样的API库。
2、 采用良好的设计思路
在设计过程中,如果能按照下面的方式来进行设计,会让这个API生命更长久
除此之外,下面还列出了一些具体的设计方法:
3、 避免极端的意见
在设计API的时候,一定要避免任何极端的意见,尤其是以下几点:
4、 有效的API评审
API设计完成以后,需要经过周密的设计评审,评审的重点如下:
5、 提高API的可测试性
API需要是可测试的,测试不应依赖实现,测试充分的API,尤其是经过了严格的“兼容性整合测试”的API,更能保证在升级的过程中不出现兼容性问题。兼容性整合测试,是指一组测试用例集合,这组测试用例会站在使用者的立场上使用API。在API升级以后,再检测这组测试用例是否能完全符合预期的通过测试,尽可能的发现兼容性问题。
6、 保证API的向后兼容
对于每一个API的设计者来说,都渴望做到“向后兼容”,因为不管是现在的API用户,还是潜在的API用户,都只信任那些可兼容的API。但向后兼容有多个层次上的意义,而且不同层次的向后兼容,也意味着不同的重要性和复杂度。
7、 保持逐步改善
过去我们总希望能将现有的“不合理”的设计完全推翻,然后按照现在“美好”的思路,重新设计这个API,但是在一段时间以后,又会碰到一样的状况,需要再推翻一次。 如果我们没有有效的逐步改善的办法,依靠推翻现有设计,重新设计API只能让我们回到起点,然后重现之前的过程。 要有一套行之有效的持续改善的办法来在API兼容的同时,改善API使之更好。
8、 把握API的生命周期
每一个API都是有生命周期的,我们需要让API的生命周期更长,并且在API的生命周期结束时能让其平滑的消亡。
开发API的过程其实就是一个沟通交流的过程。沟通的双方就是API用户和API设计者。
9、 一些具体的实施方案
在一个API不可避免要消亡或者改变的时候,我们应该接受并且面对这个事实,下面列举了几种保证兼容性的前提下,对API进行调整的办法:
一些好的API示例:
Submitted by gouki on 2013, June 30, 11:41 PM
本期thinkinlamp应该算是第三期了吧?每一期都有热点,这一期也不例外
只是这一期都集中在百度和微博的爆点上了,都在讲自己怎么优化怎么优化,怎么提高性能,他们也都用图例说明了自己的架构原来是多么的复杂,这些离我们都太远了,其实大家也都明白,PHP能做的事情很多,不仅仅局限于前台,但受限于语言的特性,对于多线程之类的不适合用它来做。也正因此,他们几个都在尝试用其他方式 来避开这个问题,让刀用在刀刃上。
其中有一点就是扩展的问题,百度的人在认为扩展能不用就不用。而鸟哥则认为合理的利用扩展可以有效的提高 性能
然后就是另外三个让我有兴趣的话题了:hm的全文检索/老高的开发规范/梁枫的PHP在web之外
hm的全文检索我是用过了,性能上还是不错,只是当时我的需求是任意字符都必须要能够出搜索结果,但是基于分词的话,就没有办法这么准确。所以,有时候就很纠结。。
老高的几个规范其实在开发中也已经遇到,但有时候真的是为了赶时间就忽略 了这些,不过,在review的时候,偶尔会对这些问题进行修复,但不是每次都保证一定能发现问题,如果到后期遇到了,恐怕就真的很难再改了
梁枫的在WEB之外,是真的让我耳目一新, 无论是直接读ttyACMD之类的文件来使得用PHP与其他设备交互,在linux中,所有的一些都是文件,所以什么都能操作,这点就比windows方便很多。梁枫演示的,用PHP在屏幕画图,视频播放器等功能,真的让我感觉PHP有很多功能没有开发出来。不要忽略了PHP在其他方面的作用。事实上,我就经常用PHP来做运维工具,毕竟用PHP写脚本,对我来说,比shell/bash之类的快很多,而且功能也更强劲
------
顺便,中午的时候,居然有演出,四位朋友的友情演出,才让我突然想起,原来今天是家驹的忌日。从第一次听他的歌到现在居然都快20年了,家驹走好
------
今天的分享中让我记忆犹新的就是几个:1、规范一定要能落地;2、尽量用技术来支撑规范;3、开发的时候就最好把安全都先考虑好;4、PHP能做很多事,就看你敢不敢想
性能有时候虽然重要,但我还是觉得,如果能够加速迭待,那才是更好的。准备开始尝试下一个项目中使用yaf了。理由真的有几点,一是纯C框架,效率有上升,2是有PHP的复刻版,即使真的装不了扩展,也能用这个复刻版
YAR,YAC都还可以考虑,先忍着点。。。。yar因为RPC的不是每个项目里都能够用得上,YAC的话,如果不是因为他无锁,都不太想用,但是又太新了,也不是每台机器上都能使用,所以就先不作考虑了,不过可以尝试在自己的项目里小小的应用一下。。。
鸟哥的扩展太多了。。。小心的用,哈
Submitted by gouki on 2013, June 30, 12:16 AM
在修改数据库结构的时候,突然间报这个错:Data truncated for column 'xxxxx' at row 1,xxxxx是数据库的字段名。
检查了一下,原来刚才在修改字段的时候,加了一个允许 null,然后默认的值都变成null,可是后来我又修改表结构为not null default '';所以,报会这个错
到数据库里:update xxxx set xxx = '';,再修改表结构,一切Over。