目前的国内的微博客很多,不少微博客都提供Open API,然而,很多 微博提供的API和Twitter的API有一些或多或少的差别,调用格式上并不完全相同。
我建议所有提供API的微博客系统,都将各 自的API统一为Twitter的API调用格式,例如目前较有影响的开源微博系统StatusNet(Laconica)的API格式就完全兼容 Twitter,这种统一API对于开发者和用户都有很大的好处。对于开发者,针对某一个微博的应用可以快速移植到另一个微博,节省开发时间。对于用户, 用户可以自定义客户端应用程序,只要换一下API地址,就能使用同一个应用程序,来访问各个不同的微博。例如目前很多人通过StatusNet的客户端来 访问Twitter一样,使用起来很方便。
Twitter的API具体是什么格式的呢?根据Twitter API文档和新浪微博开放平台的文档,这里提供了一个Twitter API的中文翻译文档,供开发者们参考。
» 阅读全文
没有了mysql我们还有什么?
其实没有了mysql还有很多数据库可用,有小型 的sqlite,有和mysql性能差不多的postgresql等
但mysql是用了最方便的。phpmyadmin使得许多不懂数据库的人也会操作了。。。
以下是原文 :
来自于:http://www.cnbeta.com/articles/95165.htm
美国开源数据库厂商MySQL前CEO马顿·古斯塔夫·米科斯(Marten Gustaf Mickos)周四致信欧盟,要求欧盟尽快批准美国商用软件开发商甲骨文收购服务器和软件开发商Sun的交易.
2008年1月,MySQL被Sun收购,并成为后者数据库业务部门.甲骨文今年4月宣布,将以74亿美元收购Sun.此前Sun股东和美国司法部已批准该交易,但欧盟仍在对此展开反垄断调查.按照原定计划,欧盟将于明年1月19日宣布是否批准甲骨文-Sun交易.
米科斯周四在写给欧盟反垄断专员尼莉·克罗斯(Neelie Kroes)的信件中表示,欧盟对甲骨文收购Sun及其开源数据库软件是否将危害市场一事展开调查,这本身无疑是正确的决定,但甲骨文-Sun交易本身其实不会妨碍正常市场竞争.
米科斯在信中写道:“如果该交易存在不确定因素,将给Sun各项业务正常发展带来负面影响,同时使市场竞争程度有所降低.正因为如此,如果甲骨文-Sun交易被迫推迟,则其后果将同欧盟的良好愿望背道而驰.”
米科斯还在信中阐述了欧盟应尽早批准甲骨文-Sun交易的两大理由:1)与Sun当初收购MySQL后会继续保留后者业务一样,甲骨文完成同Sun交易 后,同样也会继续保留和进一步发展MySQL业务.2)退一步说,即使甲骨文今后对MySQL存在偏见(实际上不太可能),由于MySQL本身市场影响力 很大,因此甲骨文一家公司并不具备完全“扼杀”MySQL的能力.
业界人士表示,目前还不清楚米科斯提交这封信件后,是否会对欧盟的相应决定带来影响.但无论如何,作为MySQL的前CEO,米科斯对MySQL的具体业务可谓了如指掌.
此前米科斯已加盟美国风险投资机构Benchmark Capital.他近日在接受外界采访时表示,由于已经不再负责MySQL管理工作,因此甲骨文-Sun交易被批准后,自己并不会从交易中获得任何利益; 他之所以要致信欧盟,是想让Sun及MySQL部门员工受益.2008年Sun提出收购MySQL时,米科斯曾加以拒绝,但后来转变态度而答应Sun收购 请求.
甲骨文CEO拉里·埃里森(Larry Ellison)此前称,MySQL会在不同业务领域同甲骨文现有数据库产品争抢市场.他还表示,甲骨文今后不会把MySQL分拆为独立公司.
看到这篇文章,就随手转贴了一下,因为我自己也在使用这样的功能,而且,现在的网站几乎都有google的广告。所以从yahoo的14条军规来说,这并不违反这个规则:使用CDN,尽量不要有超过4个域名的链接。所以你想呀,有一些google广告和yahoo的统计再加上1至2个其他的链接,肯定是没有超过4个域名了。CDN,有现成的,使用了,也算是完成了14条军规中的一些了。不是吗?所以。。。。。。
原文:http://shawphy.com/2009/01/why-google-cdn.html
自从之前jQuery 1.3版起,就已经没有提供pack版了,而我也十分赞成使用Google CDN进行代码托管。
这样做有以下几个好处:
1,更小下载量。
都知道jQuery 1.3 pack后有38k之多,如果当然可以删除版权注释以获得更小的代码,遗憾的是这不仅无耻且只节约1个k都不到。而同样利用Google APIs 提供的GZip过的Min版,只有18k,对用户来说下载量更小。
2,减轻服务器压力。
虽然现代浏览器都有了缓存,但以前我看到过资料说某大型网站发现他们70%的访客缓存都是空的(哪位同学能帮忙找到资料请下面留言,不胜感激~)。所以,让Google为我们提供服务,而不用自己操心自己的流量~少个库可以少个连接数,何乐而不为。
3,多个网站共享缓存。
如果用户访问的多家网站都使用Google提供的jQuery,那么对于用户来说,只需要缓存一次后即可只读取缓存中的数据!而不是每个网站都要重新下载一份。对此进一步加快用户访问速度。
4,更快执行速度。
jQuery 1.3.1发布的发布信息中, 为jQuery不提供pack版给出了官方的解释。除了不易debug,在Adobe AIR和Caja-capable等环境下无法使用之外,更重要的是因为执行速度问题。随着jQuery逐渐变“胖”,用pack压缩后在浏览器端“解压 缩”所需要的资源越来越大。想象一个超大的字符串多次replace后再eval的情景……这不比直接读取一个不需要解压缩的min版来得快。John给 出了一些数据,有兴趣的同学可以看看。
反对的声音:
“不安全”、“没安全感”、“放别人的机器太危险了”、“他们服务器倒了呢?”、“以前刚开始的时候就down过”
我认为(晕……怎么我觉得我在写四六级作文……)Google服务器down的几率与我们自己服务器down的几率不会有显著性差异(抱歉,我又空 口无凭说话了……不过如果哪位同学能给出数据来拒绝我的零假设,认可备选假设的,欢迎提供,再次不胜感激~)。所以就放他们那边吧,挺安全的。
另外我还听到关于不能让整个世界为着Google转,Google阴谋论,Google威胁论的声音。实际上Google确实正朝这个方向发展,让 整个互联网围着他转。可以看他提供的一些服务,什么云计算,什么App Engine之类的,都企图让人们的应用都建立在Google至上,当Google成为了空气的时候,他已经无处不在了。这点来说,值得担忧。
QEEPHP终于发布了,没有看到廖羽雷吃笔记本,也是一种遗憾。
要知道QeePHP可是让人等了整整一年,当年论坛上就有人说:宁可相信世上有鬼也不相信老廖的嘴。可见让人有多失望
不过,在昨天凌晨的时候,QeePHP还是提供了下载,不过下载完了之后还没有时间仔细观摩。
初步看了一下,目录结构与ZF相类似,自动加载类库也使用了spl_auto_load,因为使用了这个函数,造成的后果是,文件名全部是小写了。呵呵(不知道原因的可以去查看这个函数)
其他还没有仔细看。
可以先看官方:http://qeephp.com