Author: Volcano

  • markdown文件的编辑以及实时预览

    之前看到有一款叫Mou的软件可以编辑markdown格式的文本内容并且实时预览,可是我比较喜欢用vim编辑器,所以就想着能不能用别的软件配合着来实现实时预览。 今天看到一个chrome的扩展叫markdown preview,它可以自动把md或markdown后缀的文本转换为html格式在chrome中查看,只是还欠缺一个自动刷新的功能。然后我看到它的源码已经放在github上,于是抓回来做了一些修改,加上了自动刷新的功能。 演示 尝试了一下在vim中编辑文件,然后在chrome中浏览,效果还不错,见下图: 更改后的扩展 我把修改后的markdown preview插件放在github上 , 已经尝试向原作者发起pull requests,要试用的话需要按下面几步操作: 把插件的代码clone回来 git clone git://github.com/volca/markdown-preview.git 开启chrome扩展的开发者模式,具体位置在窗口 -> 扩展程序里 载入正在开发的扩展程序 将允许访问文件网址勾选上 然后你就可以尝试用chrome浏览器打开markdown文件预览html,采用趁手的编辑器去修改它。 BTW chrome下的插件写起来比想像的要简单,写javascript就是了 现在这篇blog即是我用markdown格式写成的,用到了wordpress的markdown on save扩展。 Update 测试把文件放在dropbox的Public下,修改之后的效果能够立刻在共享链接里看到效果,很完美

  • 用git部署php站点

    在小站点上,直接用git来部署php代码相当方便,你的远程站点以及本地版本库都有一个版本控制,追踪问题或者回滚是很轻松的事情。下面介绍用git部署时的设置步骤 在远程服务器的设置 假定你需要部署的代码在/var/www/yoursite cd /var/www/yoursite git init . git config receive.denyCurrentBranch ignore git config –bool receive.denyNonFastForwards false cd .git/hooks wget https://gist.githubusercontent.com/volca/9482044/raw/344a590af350b997db3819fa21426dfe8bc140f4/post-update chmod +x post-update 在本地git库中新增配置 [remote “prod”] url = your-ssh-username@your-host:/var/www/yoursite/ 这样就算设置完成了。 如果你想把本地的代码推送到远程服务器,下面简单的步骤就可以做到 git pull git push prod 注意事项 如果远程服务器上git的配置目录.git暴露在外部可访问的位置,请在web服务器上设置这个目录不可见。

  • 如何安装Node.js

    下面分别介绍在Mac, Ubuntu,Centos以及Windows下安装Node.js. Mac 在Mac下,如果你喜欢用homebrew,那么只用一行就可以装好: brew install node 否则,只能考虑手工安装了,步骤如下: 安装Xcode 安装git 运行下面的命令行编译node.js git clone git://github.com/joyent/node.git cd node ./configure make sudo make install Ubuntu 安装依赖包 sudo apt-get install g++ curl libssl-dev apache2-utils sudo apt-get install git-core 运行下面的命令行: git clone git://github.com/joyent/node.git cd node ./configure make sudo make install Windows 用cygwin来安装node,步骤如下: 安装cygwin 在cygwin的目录下,运行setup.exe安装下面列表中的包 devel → openssl devel → g++-gcc […]

  • php的filter扩展小技巧

    做为一个合格的web开发人员,一定会牢记一个原则——永远不能相信用户输入的数据,行走江湖,安全第一是很重要的。用户通过表单或url传过来的数据,一定要仔细检查过了,才往后台数据库里存进去。在一个成熟的开发团队里,贯彻这个原则不成问题;但是如果在一个新人老手混搭的小team里,很容易就忽视了这个问题,那么各种安全漏洞比如跨站攻击,sql注入等等真是防不胜防。 实际上,用php 5自带的filter扩展能够较好的解决这个问题。我在从前的blog里记录了filter扩展的常规用法——直接利用filter来校验数据,这样有不少额外的代码量,所以我得介绍一个比较偷懒的办法——自动对所有输入变量进行过滤,这只需要对php.ini增加一行配置,然后重启apache或fastcgi让php配置生效。 filter.default=”special_chars” 开启了这项配置后,会自动使用filter_input方法对$_GET, $_POST, $_COOKIE, $_REQUEST以及$_SERVER变量进行过滤转义。配置中special_chars是常量FILTER_SANITIZE_SPECIAL_CHARS的缩写,它能自动转义大部分危险字符例如: '"<>。而php手册对它的解释是: HTML-escape ‘”& and characters with ASCII value less than 32, optionally strip or encode other special characters. 在这个情况下,新人们写出这样的代码我也不会太担心: $foo = $_GET[‘foo’]; echo $foo; 在部分场合,我们可能还是需要未转义的变量,比如某个ajax接受的参数是一段json串,用这段代码即可获得原始数据: $foo = filter_input (INPUT_GET, ‘foo’, FILTER_UNSAFE_RAW); fitler扩展与yahoo使用的yiv如出一辙,印象里似乎就是yahoo对yiv做了些修改贡献给php社区,但是暂时没找到出处。

  • 关于“facebook的memcached实战”小记

    上周挤到QCon的会场里,听了两场 —— Facebook的Memcached实战,以及Twitter 的可伸缩性数据架构。当时对facebook超大规模使用memcached印象很深刻,只可惜到现在也没见到这个的ppt。平时用php比较多,因此听闻同样使着php的facebook讲memcached,有些小小的感触,记录下来。 更高效的序列化函数 php有两个memcache扩展,默认都是使用php自带的序列化函数serialize来存储数组或对象。但是serialize最为人诟病的就是速度慢,序列化之后占用空间大。由于facebook已经在memcached里保存了200T字节的数据,因此序列化函数即便作出的百分之一的优化对它来说都是个不小的收益。他们发粪涂墙在thrift的binary协议基础上搞出了一个fb_serialize,据称这个序列化方法能快上3倍,快倒算了,还能节省30%空间, 200T字节的数据能节省出30%,简直就是传说中的银弹啊,这让php官方的开发人员们情何以堪? facebook目前已经开源了thrift,其中自带了一个thrift协议的php扩展,但是这些代码里没有找到传说中的fb_serialize,我倒是从最近他们放出来hiphop-php里找到了这部分代码,哪位大侠去扒拉扒拉弄出来做成php扩展造福广大群众? 作为备选方案,我推荐igbinary,这也是一个binary的序列化方法。在上次的测试结果中,它甚至能节约50%的存储空间,速度也是稳超php原生的序列化方法,搞不好facebook换了这个序列化方法能省下更多的内存来? 节约每个item的存储空间有什么好处?我个人认为一个是省钱,另外一个就是能够带来速度上的提升。我们平常碰到稍大一点的item都得用gzip压的妥妥贴贴的才送到memcached里,网络传输的开销小了,这是实实在在的性能提升。何乐而不为? mcproxy mcproxy = memcached + proxy。facebook的机房遍布各洲,利用mcproxy来进行跨机房的同步或分发,全球制霸,指着太阳就能等到那天了。一般的互联网企业还真用不上这玩意,规模还没上去的时候,这些乱七八糟的只会拖后腿。facebook还没开源mcproxy,但是我找到两个替代品: memagent is a simple but useful proxy program for memcached servers. moxi = memcached + integrated proxy 从项目描述来看,moxi最接近facebook介绍的mcproxy,成熟度也比较高。 数据的一致性 Marc Kwiatkowski在会场上用大篇幅的ppt和大量的动画来阐述这个问题,他们用了很多额外的手段来解决在跨机房情况下因为延时问题造成的脏数据。这一段看着挺晕,但是我们联想到facebook用到的多级cache技术: 本地全局变量 + apc + memcache,不难理解这样做颇有些道理,这相当于用memcache实现了一个版本控制系统。 我还是很晕这段ppt。

  • 关于改善xhprof使用情况的设想

    自从去年将xhprof用在生产环境以来,对生产环境的程序调试,性能优化都带来很多便利。但是在使用过程中,还是有一些细节需要改善。 问题 xhprof的profile日志直接以文件形式保存在生产服务器上,需要定时清理,或者收集起来移动到查看日志的工具机上。 由于xhprof生成的profile是一个大数组,所以保存到文件时使用了标准的php serialize,日志文件偏大,一个不留神就容易占用很多服务器磁盘空间。 查看日志列表时,一个个点开查看比较费劲。 针对这几个问题,我有一些小小的设想。 日志存放 部署一个中央日志服务器,采用facebook的scribe来收集日志。生产环境的服务器产生的xhprof日志,都写入到scribe的客户端,由客户端自动同步到中央日志服务器的scribe上,不占用本地的存储空间。在代码上的改动也比较小,只要基于iXHProfRuns接口实现一个XhprofRuns类,调整save_run方法的存储方式即可。 更换序列化方法 xhprof默认是将profile信息用php原生的序列化方法处理后进行保存,而我在前两天比较过igbinary vs serialize vs json_encode的性能和占用字节数,这个测试里igbinary在各方面都有一定优势,尤其是占用存储空间会大幅度减小,所以我只要更换序列化方法为igbinary_serialize即可获得改善。 优化列表展示 我已经厌倦挨个查看profile日志的大图,费时费力还没有针对性。所以我现在的做法是,在profile日志的列表中将前1000个日志的总体执行时间直接输出到列表中,并且将执行时间过长的日志用红色粗体标识。做了这个小小的改动之后,当我想要去视察一下运行情况时,就把日志列表中那些红通通的链接点开看看就行了,真正的省时省力。 如何从xhprof日志文件中获取执行时间?简单的代码如下 /** * 由xhprof日志获得执行时间 * * @param string $log xhprof日志的文件路径 * @return int 执行时间 */ function getSpentTime($log) { $profile = unserialize(file_get_contents($log)); return $profile[‘main()’][‘wt’] / 1000; }

  • 在生产环境中使用php性能测试工具xhprof

    xhprof是facebook开源出来的一个php性能测试工具,也可以称之为profile工具,这个词不知道怎么翻译才比较达意。跟之前一直使用的xdebug相比,有很多类似之处。以前对xdebug有一些记录还可以供参考,但是它的缺点是对性能影响太大,即便是开启了profiler_enable_trigger参数,用在生产环境中也是惨不忍睹,cpu立刻就飙到high。 而xhprof就显得很轻量,是否记录profile可以由程序控制,因此,用在生产环境中也就成为一种可能。在它的文档上可以看到这样一种用法: 以万分之一的几率启用xhprof,平时悄悄的不打枪。 if (mt_rand(1, 10000) == 1) { xhprof_enable(XHPROF_FLAGS_MEMORY); $xhprof_on = true; } 在程序结尾处调用方法保存profile if ($xhprof_on) { // stop profiler $xhprof_data = xhprof_disable(); // save $xhprof_data somewhere (say a central DB) … } 也可以用register_shutdown_function方法指定在程序结束时保存xhprof信息,这样就免去了结尾处判断,给个改写的不完整例子: if (mt_rand(1, 10000) == 1) { xhprof_enable(XHPROF_FLAGS_MEMORY); register_shutdown_function(create_funcion(”, “$xhprof_data = xhprof_disable(); save $xhprof_data;”)); } 至于日志,我暂时用的是最土的文件形式保存,定期清除即可。 BTW:xhprof生成的图形方式profile真是酷毙了,哪段代码成为瓶颈,一目了然。

  • Memcache的备忘

    把memcache使用时的一些细节记录下来. 用memcache保存session的例子,非常简单 <?php $session_save_path = “tcp://$host:$port?persistent=1&weight=2&timeout=2&retry_interval=10, ,tcp://$host:$port “; ini_set(‘session.save_handler’, ‘memcache’); ini_set(‘session.save_path’, $session_save_path); ?> memcache每一个item上限是1M,注意不要超出上限 memcache本身并不支持namespace,但是可以通过一些手段模拟出namespace的效果来,见Memcache 中模拟 namespace 刚接触memcache的时候,可能会写出这样的代码来 $zhang = $memcache->get(‘key1’); $li = $memcache->get(‘key2’); $wang = $memcache->get(‘key3’); 这种写法实际运行效果是 get(key1) – 客户端发出请求 – 服务器端查询 – 客户端获取 get(key2) – 客户端 – 服务器端 – 客户端 get(key3) – 客户端 – 服务器端 – 客户端 … 如此一来,会有三次客户端和服务器端交互的过程。但是如果用批量查询的方法,就只有一次交互的过程。比如: $all = $memcache->get(array(‘key1’, ‘key2’, […]

  • 查看xdebug profile文件的几个程序

    在优化php代码执行效率过程中,有个好办法是利用xdebug生成profile文件,然后查看整个程序的瓶颈在哪里。现在xdebug profile的查看程序有好几个,在这里罗列一下. Wincachegrind Wincachegrind是windows下的profile查看程序,使用起来感觉还不错,profile文件太大的话偶尔会崩溃。 今天在高春辉的博客上看到这些: 最近又开始拿 Xdebug 和 wincachegrind 对项目的 PHP 代码进行分析和优化,但是发现和自己输出的执行时间总是相差十倍,差的不是零头,而是十倍。 上网搜索了一下,原来在 Xdebug 2.0.0RC4 版本开始,对 profiler 日志中的时间单位进行了修改。 (“Use µ seconds instead of a tenths of µ seconds to avoid confusion in profile information. ”) 而 wincachegrind 又不再升级维护了,所以凡是用 2.0.0RC4 以及之后版本的 Xdebug 输出的 profiler 日志用 wincachegrind 来分析的话,都会有十倍的时间差距。 他已经提供了hack后的版本,可以解决时间差距的问题,有兴趣的同学可以试试。 CachegrindVisualizer CachegrindVisualizer是一个xdebug的profile文件查看客户端,采用Adobe的AIR制作。 更详细的介绍可以看以前写的关于CachegrindVisualizer的介绍。 Kcachegrind Kcachegrind是linux下的一个图形化profile查看工具,功能很强劲。 Callgrind uses runtime […]

  • wordpress plugin – search engine related posts

    Table of content Description Usage Download History Link Description English version When someone is referred from a search engine like Google, the plugin show your blog content matched the terms they search for. 中文说明 当用户从google搜索到你的博客上,这个wordpress 插件会根据用户搜索的关键词显示你的博客上更多的相关内容。目前也只对google生效,下一个版本将对baidu生效。 这个插件完全使用javascript加上google的api完成,不需要占用服务器端的资源,环保且安全。 Usage English version: unzip it Put <div style=”display:none” id=”search_content”></div> at the place in your template where you want […]