php 面向对象相关

function x()	
	$x = debug_backtrace();
	//remove stack of this function
	array_shift($x);
	$i = 0;
	$xstr = '';
	foreach ($trace as $x) {
		//TODO need check exists args
		$args = $x['args'];
		if (!$args) {
			$argstr = '';
		} else {
			$argstr = '';
			$first = true;
			foreach ($args as $arg) {
				if (!$first) {
					$argstr .= ',';					
				}
				$first = false;
				if (is_object($arg)) {
					$argstr .= 'Object[' . get_class($arg) . ']';
				}
				elseif (is_array($arg)) {
					$argstr .= 'Array';
				} else {
					$argstr .= $arg;
				}
			}
		}
		$xstr .= "[#$i] {$x['file']}({$x['line']}) {$x['function']} ($argstr)" . PHP_EOL;
		$i++;
	}
	
	return $xstr;
}

参见:

http://jarofgreen.co.uk/2011/02/more-php-error-handling-tips/

Continue reading php 打印error trace

Smarty 警告报错问题

11 Jan 2013 in php on smarty

这次使用Smarty出现了错误，E_WARNING 级别 filemtime()

之前用得好好的，这次的例外是自己处理了php错误,而且原则是连Notice都不能有。

查一下资料发现需要调用Smarty::muteExpectedErrors() http://www.smarty.net/docs/en/api.mute.expected.errors.tpl

这只在对错误处理比较严格的情况下才会出现。

Continue reading Smarty 警告报错问题

Openfire Bosh 配合strophe.js使用

04 Jan 2013 in java on openfire, strophe.js, xmpp

这次试了一下Openfire的Bosh协议以及strophe.js，记录一下。

有两个问题要注意：

1：直接使用javascript调用bosh往往存在同源原则的问题，例如localhost:80端口下的页面脚本要访问Bosh服务localhost:7070,那么这个ajax访问就会失败,因为违背了同源法则。(这使得我又回去看了一下cookie的问题https://blog.kazge.com/web/2012/08/26/e5-86-8d-e8-b0-88p3p-e4-b8-8e-e7-ac-ac-e4-b8-89-e6-96-b9cookie/,cookie保存却又不区分端口)因此，我们要么使用跨域插件fkXHR要么在服务器上配置代理来使bosh服务与发起请求页面“同源”。

例如apache里面在 httpd.conf 中加入下面几行：

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so

ProxyRequests Off
ProxyPass /xmpp-http http://127.0.0.1:7070
ProxyPassReverse /xmpp-http http://127.0.0.1:7070
<proxy http://127.0.0.1:7070>
    AddDefaultCharset off
    AllowOverride None
    Order Deny,Allow
    Allow from all
</proxy>

上面的配置将apache监听端口下/xmpp-http 反向代理到了http://127.0.0.1:7070

2: 这其实和上面的第一个问题相关，如果遇到400 Bad Request的问题，你要检查你的代理配置和你请求的url, 很可能是掉了最后的反斜杠/,这个是反向代理常犯的错误。以上面的配置为例，则bosh的url应该为localhost/xmpp-http/http-bind/

[为方便国外鸟:]

if you encounter the error response from the xmpp BOSH server, you should check your url with your proxy configuration, it is you miss the last backslash of the BOSH service’s url in your javascript in most case. for example, if you make the proxy like “ProxyPassReverse /xmpp-http http://127.0.0.1:7070” then your BOSH url should be localhost/xmpp-http/http-bind/, note the last backslash.

使用示例官方下载包example文件夹中有。

这个strophe有个奇怪的行为,其Strophe.Connection.connect方法当传入的不带域名时，会尝试匿名登录。而如果传入bareJid(像[email protected])，如果密码错了或是用户名不存在，则一直没返回。

参见:

http://mineral.iteye.com/blog/448260

http://www.ibm.com/developerworks/cn/xml/tutorials/x-realtimeXMPPtut/section6.html

Continue reading Openfire Bosh 配合strophe.js使用

Google Speech Api使用

04 Jan 2013 in java / voip on google, speech recognize, 语言识别

语音识别里，Google 现在是个Big Gun了，但是它没有公开它的API,也没有发售，许多程序使用这个api也是hack性质的，使用这种服务可能出现的问题就如Google Weather最近的更改一样。我从没想到竟然有人想拿它作为产品级别的应用服务，不过我已经比较淡定了，就像我没想到有人天天喊做震惊世界的软件，却成天想用抠门的态度来获得一本万利的回报，又想牛儿长得好又想牛儿不吃草！

嘛,嘛,嘛~ 扯远了,打住,。

从各方搜集到的情报来看，此服务性能还不错，虽然支持wav格式，但似乎官方推荐flac格式，所以我们还得转换一下，在java这方面就不得不提到两个开源项目:

https://github.com/The-Shadow/java-speech-api 这个里面包含了使用Google Speech Api的代码，可以参照，它是用了另外的一个项目

http://sourceforge.net/projects/javaflacencoder/

来转换wav到flac.

知道这两个事情，余下的就好办了，

请求头示例

Content-Type:audio/x-flac;rate=8000

请求地址

https://www.google.com/speech-api/v1/recognize?xjerr=1&client=chromium&lang=en-US

向其post你的flac流，得到的将会是解析结果,类似:

{"status":0,"id":"46f00c9fe47a4dfe3c97ae4076df726u-1","hypotheses":[{"utterance":"gong xi fa cai","confidence":0.9049254}]}

测试效果比较满意，国内访问相应速度堪忧，经常连不上，使用代理那速度就非常不错了。

代码我就不贴了。

这篇文章讲得比较详细: http://blog.csdn.net/dlangu0393/article/details/7214728

引用:

多种音频格式的测试
    收到朋友的邮件说使用flac实在是很不方便，问我有没有更好的解决方法，于是我尝试将其他编码格式应用于Google Speech API。以下为结果：
    1、WAV格式
    请求Header：Content-Type: audio/L16; rate=16000
    返回结果：识别成功
    2、MP3格式
    请求Header：Content-Type: audio/mpeg; rate=16000
    返回结果：无法识别的编码
    请求Header：Content-Type: audio/mpeg3; rate=16000
    返回结果：无法识别的编码
    请求Header：Content-Type: audio/x-mpeg; rate=16000
    返回结果：无法识别的编码
    请求Header：Content-Type: audio/x-mpeg-3; rate=16000
    返回结果：无法识别的编码
    请求Header：Content-Type: audio/mp3; rate=16000
    返回结果：无法识别的编码
    3、PCM格式
    请求Header：Content-Type: audio/x-ogg-pcm; rate=16000
    返回结果：无法识别的编码
    请求Header：Content-Type: audio/pcm; rate=16000
    返回结果：无法识别的编码
    4、SPEEX格式
    请求Header：Content-Type: audio/x-speex-with-header-byte; rate=16000
    返回结果：识别成功
    请求Header：Content-Type: audio/speex; rate=16000
    返回结果：识别成功

参见:

http://stackoverflow.com/questions/12721436/google-speech-api

http://mikepultz.com/2011/03/accessing-google-speech-api-chrome-11/

http://blog.csdn.net/dlangu0393/article/details/7214728

Continue reading Google Speech Api使用

Android Basic验证造成的问题

01 Jan 2013 in mobile on android

今天是元旦，节日快乐。

我这两天就为这个问题，晚上终于解决了。

问题是这样的，我写个Android程序访问http服务，服务端使用Http Basic验证。开始使用的是httpclient，先用jvm测试，访问成功。然后用android UnitTest就不行了，返回错误是

400

Bad Request

Your browser sent a request that this server could not understand.

apache的错误是

client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23)

这我就纳闷了，刚开始还以为是https配置错误（服务端使用的是ssl）。

结果切换为http还是一样的错误。

于是乎我就找到了

http://stackoverflow.com/questions/12418458/client-sent-http-1-1-request-without-hostname-see-rfc2616-section-14-23-from/12434731#12434731

这位老兄和我一样的情况，最后他说是android 上http请求host头没设置造成的。

（就是他害我思路错误啊！）

我也试了一下，加了个Host头，而且要放在Authentication头之前。

这样client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23)

这个错倒是没有了，但是发现发送的内容服务器接收不到。

那就只好看看到底发的是什么东西了，这里要用到tcpdump:

具体见http://www.growprogress.com/vcommon/?p=1293

使用http://www.strazzere.com/android/tcpdump 这个链接下载android上可运行的较好。

当获得日志后还要配合wireshark来分析。

wireshark需要先启动npf http://ask.wireshark.org/questions/1281/npf-driver-problem-in-windows-7

sc qc npf查询npf是否运行
sc start npf启动npf

我也试过直接wireshark监控模拟器或android-x86的请求，但是看不到，还是需要通过tcpdump。

如果是ssl请求那就更麻烦了，参见http://blog.csdn.net/jasonhwang/article/details/2350723

因此我是切换到http来测试的。

从请求中没看到什么问题（这里又犯错误，问题就在这里，没有仔细比较，所以没看出来）

于是怀疑是不是httpclient有问题，巧的是就有文章说这个问题 http://jackyrong.iteye.com/blog/1228220

另外这个项目更新了android自带的httpclient

https://code.google.com/p/httpclientandroidlib/

于是乎我就切换到httpurlconnection,把我的工具类重写了一遍……

结果，还是一样的问题，OMG,简直要崩溃了，这时脑子也很疲劳了，

一段时间来对Android的牢骚几乎就要爆发了(这个牢骚免不了，日后定一吐为快……)。

就在这时，这篇文章救了我

http://stackoverflow.com/questions/5092561/http-post-request-with-authorization-on-android/5095189#5095189

原来是Android上Basic编码的问题，多了个换行符，

怪不得Host放在Basic64编码之前就不报client sent HTTP/1.1 request without hostname  这个错。

而且我想起来tcpdump日志看起来有点怪，原来是这个问题。

解决方案就是

 private String getB64Auth (String login, String pass) {
   String source=login+":"+pass;
   String ret="Basic "+Base64.encodeToString(source.getBytes(),Base64.URL_SAFE|Base64.NO_WRAP);
   return ret;
 }

测试通过，真是无语啊。

为什么我不是高富帅，

如果我是高富帅，

我就吃苹果去了，

左手ipad,

右手iphone,

膝上托着macbook pro……

Continue reading Android Basic验证造成的问题

【转】Dalvik VM（转载整理）

05 Dec 2012 in mobile on android

转一篇转得好的，转自 Dalvik VM（转载整理）

Dalvik虚拟机是Google的用于移动设备的Android平台的一个主要部分。虚拟机可运行Java平台应用程序，这些应用程序被转换成紧凑的Dalvik可执行格式（.dex），该格式适合内存和处理器速度受限的系统。

Dalvik虚拟机的作者是丹伯恩斯坦（Dan Bornstein）。

与大多数虚拟机和真正的Java虚拟机不同，前者是栈机（stack machine），而Dalvik VM是基于寄存器的架构（register-based architecture）。就像CISC与RISC的争论，这两种方式的相对优点是一个不断争论的话题，且有时技术界限会变得模糊不清。此外，两种方法的相对优势取决于所选择的解释/编译策略。

一个名为dx的工具，它用于转换Java的.class文件到.dex格式。多个类文件可包含到单个的.dex文件中。重复的、可用于多个类的字符串和其它常量在转换到.dex格式时输出到保留空间。Java字节码还可转换成可选择的、Delvik VM使用的指令集。一个未压缩的.dex文件在文件大小方面往往比从同样的.class文件压缩成的.jar文件更小。

为满足低内存要求而不断优化， Dalvik虚拟机有一些独特的、有别于其它标准虚拟机的特征：
(1) 虚拟机很小，使用的空间也小；
(2) Dalvik没有JIT编译器；(Android 2.2 开始支持JIT)
(3) 常量池已被修改为只使用32位的索引，以简化解释器；
(4) 它使用自己的字节码，而非Java字节码。（It is not a JVM as you might expect.）

另外一篇终结：

(1) Dalvik VM和JVM 的第一个区别是 Dalvik VM是基于寄存器的架构（reg based），而JVM是栈机（stack based）。reg based VM的好处是可以做到更好的提前优化（ahead-of-time optimization）。另外reg based的VM执行起来更快，但是代价是更大的代码长度。（预加载导致启动慢）
(2) 另外一个区别是Dalvik可以允许多个instance 运行，也就是说每一个Android 的App是独立跑在一个VM中.这样做的好处是一个App crash只会影响到自身的VM，不会影响到其他。 Dalvik的设计是每一个Dalvik的VM都是Linux下面的一个进程。那么这就需要高效的IPC。另外每一个VM是单独运行的好处还有可以动态active/deactive自己的VM而不会影响到其他VM
(3) 接下来就是关于版权之类争论。（可以参看下面文章）

既然reg based VM有那么多好处，为什么之前设计JAVA的人没有采用reg based而是采用stack based的呢？原来stack based的VM也有其优点，就是它不对host平台的reg数量做假设，有利于移植到不同的平台。而Dalvik则不关心这些，因为它本来就是为ARM这样的多reg平台设计的。另外Dalvik被移植到x86也说明，即使是x86这种reg很少的平台，reg based的VM也是没有问题的。

注：这两种VM应该还有其他的优缺点，但是对应用开发人员或非相关内核开发人员而言没必要有深入的研究。

Dalvik VM官方网站：http://www.dalvikvm.com/

Dalvik VM wiki网站：http://en.wikipedia.org/wiki/Dalvik_(software) (网址有问题，需要拷贝整个URL打开)

《Android的虚拟机Dalvik引来论战不断》 http://www.oschina.net/bbs/thread/2547

参见:

http://blog.csdn.net/libaohan/article/details/7225618

Continue reading 【转】Dalvik VM（转载整理）

流行在线支付平台比较

29 Nov 2012 in Web on payment, 支付

在线支付online payment，这里主要比较国外的 paypal, authorize.net, stripe.com.\\

paypal 和authorize.net都是可靠地的老牌子，也是最流行的，这篇文章比较了它们的使用场景，http://www.webdesignerexpress.com/which-is-better-paypal-shopping-cart-or-authorizenet-shopping-cart-article-58.html

大意是说：

paypal适合小支付，它没有固定收费，成本较低，但是使用paypal却要求非常严格，用户填错了个字符什么的就无法支付，且提示模糊，这都是由于paypal严格的安全要求造成的，用户可能常常找不着北，这一点有利有弊，用户喜欢它的安全性，但又造成使用不方便.

而authorize.net能让站点定制自己的表单，完全由后台api调用，没人说他不好的。但是它的收费可不便宜，固定费用$30每月，顶价可达到$75。这是个很大问题。所以交易量大的商户可使用。

最后文章推荐双管齐下，来个中国的中庸之道……

但是对于authorize.net的收费贵的缺点，这里有个替代，那就是stripe.com,它没有paypal那么复杂，也没有authorize.net那么贵，而且它的后台投资方其实就是paypal的投资方，看起来很好哈，只是目前使用后起之秀的它还不是很火爆，没有前两者那么有名。

还有一个更新的:

https://www.balancedpayments.com/help#22659936

面向商业，收费更便宜

https://www.balancedpayments.com/docs/overview?language=bash#payouts

怎么取舍，还是要看你的客户的意思了，毕竟风险还是他们来承担。

参见其他平台比较:

http://www.merchant-account-services.org/article/payment-gateways-reviewed

http://www.chukou1.com/University/UniversityDetails.aspx?id=414

Continue reading 流行在线支付平台比较

构造函数的问题：

Pagination