XCode6.0的iOS免证书真机测试方法(MAC及黑苹果均有效)
http://blog.yourtion.com/run-react-native-on-device.html
React Native真机调试
http://blog.yourtion.com/run-react-native-on-device.html
遇到的问题通过这2个页面解决了 太棒了!!已经可以在我的4s上跑起来了哈哈哈哈
去芜存菁
XCode6.0的iOS免证书真机测试方法(MAC及黑苹果均有效)
http://blog.yourtion.com/run-react-native-on-device.html
React Native真机调试
http://blog.yourtion.com/run-react-native-on-device.html
遇到的问题通过这2个页面解决了 太棒了!!已经可以在我的4s上跑起来了哈哈哈哈
php.ini 中缺省的最长执行时间是 30 秒,这是由 php.ini 中的 max_execution_time 变量指定,倘若你有一个需要颇多时间才能完成的工作,例如要发送很多电子邮件给大量收件者,或者要进行繁重的数据分析工作,服务器会在 30 秒后强行中止正在执行的程序,如何解决这个问题呢。
另一个办法是在 PHP 程序中加入 ini_set('max_execution_time', '0'),数值 0 表示没有执行时间的限制,你的程序需要跑多久便跑多久。若果你的程序仍在测试阶段,推荐你把时限设置一个实数,以免程序的错误把服务器当掉。
<?php //max_execution_time=100; ini_set("max_execution_time", 1); //用此function才能真正在运行时设置 for($i=1; $i< 100000; $i++) { echo "No. {$i}\n"; echo '<br />'; flush(); } ?>
在这里简单记录下~
unbuffered_row() 方法
老版本不支持3.0以上才有
row() 方法一样返回单独一行结果,但是它不会预读取所有的结果数据到内存中。 如果你的查询结果不止一行,它将返回当前一行,并通过内部实现的指针来移动到下一行。
$query = $this->db->query("YOUR QUERY"); while ($row = $query->unbuffered_row()) { echo $row->title; echo $row->name; echo $row->body; }
A 找 B 直接沟通,这就等于没有什么代理;
然而中间夹一个传话的 C,C 就是代理了,A 通过 C 把信息传递给 B,然后 C 再把 B 的反馈转达给 A。
在这个过程中,A 知道沟通的直接目标是 B,只不过由于各种原因无法直接和 B 面对面,需要中间人 C,这就是所谓“正向代理”,其实我们很少说正向代理,在英文原文里,这个叫 Forward Proxy,一般就直接叫代理,你翻译成“转交代理”或“传达代理”都比“正向代理”强,然而没必要,因为代理这个词的本意就是如此。
另外一种情况则是:A 并不知道 B 的存在,它只知道找 C 就可以得到想要的回复,对于 A 来说有没有 B 或者有多少个 B、D、E、F……都不重要,只要有 C 就够了。而 C 则根据情况去获取反馈然后响应给 A。
这种就叫反向代理了。理解其中的区别不要从“正反”两个反义方向词上做文章,英文里的 Forward 和 Reverse 并不是一对反义词,Forward 和 Backward 才是,然而 Reverse 和 Backward 并不是一个意思……所以说技术书籍资料还就是得看原文的啊。
------
刚才有小伙伴问了我一个问题,因为他还是对此有困惑,我给他举个例子他明白了。我不知道我上面的答案是否能让大家明白,所以我把这个例子也写出来:
我想访问 www.google.com,然而大家都知道它被墙了,我没法直接访问它。于是我连接了一个 VPN 服务并设定其为本地 HTTP 访问的代理(比如说在 Mac 下勾选“通过 VPN 连接发送所有流量),然后我再访问 www.google.com,此时我的请求被该 VPN 服务代理了,它帮我访问了 www.google.com 然后把结果返回给我。
这个例子是代理的一种应用场景,但并非代表代理只能用于这个
最重要的特征是我知道 www.google.com 的存在,而且我访问的网址也的确是 www.google.com,只不过我的访问请求经由了 VPN 代理来转交,同样响应也是如此
在本例中,代理是透明的,用户有可能不知道它的存在(通常是知道的,只不过代理的设置可能不是他自己来做)
我有一个 Nginx 服务部署在 www.mysite.com 的 80 端口,用户访问它就可以看见我做的网站;在我的网站中有一些 Ajax 请求去获取 JSON 数据,然而提供这些数据的 API Service 部署在服务器上的 8000 端口,该端口由于防火墙的阻挠使得用户无法直接访问到。
于是我重新配置了 Nginx,让它把所有经由 :80/api/ 的访问请求都代理给 localhost:8000,然后把响应返回给原始的请求方(即:Origin Host),这就是反向代理。现在我的用户可以正常访问 www.mysite.com 啦。
同上,这是反向代理的一种应用场景,但并非代表它只能这样用
最重要的特征是我的用户压根不知道 localhost:8000 这个服务的存在,并且即使知道也访问不到——开 VPN 也访问不到,这是俩码事!
对于用户来讲,唯一的“对话”方只有 www.mysite.com(80 端口),他们不知道也不必知道后面发生了什么