山维空间

分类： 技术

各种开发心得，包括语言、软件工程、开发工具等

  • Handlebars 4

    Handlebars 4

    图文……好像有关。

    Handlebars自从升到2.0之后，就放开了，版本号蹭蹭涨，如今已经升到4.0版。

    这个版本最显著的变化在于层级结构，以往的版本中，所有的Block Helper都可以形成一个层级。对于{{#each}}、{{#with}}这种还好说，层级关系比较明确，很好理解；但是{{#if}}，也有可能形成一个层级，这就很奇怪了。尤其像我前文所述，它只是可能形成一个层级，就更诡异了。

    所以这个修改其实是件好事儿。

    接下来，代码时间。

    Before

        {{#each list}}
      {{#if is_true}}
        <p>这里需要向上两层才能找到值。{{../../value}}注意，这里是两层。</p>
      {{/if}}
    {{/each}}

        var data = {
        list: [
          // items..
        ],
        value: 'value'
      }
      , template = Handlebars.compile(hbs);
    template(data);

    After

        {{#each list}}
      {{#if is_true}}
        <p>这里需要向上两层才能找到值。{{../value}}那，这里只有一层了</p>
      {{/if}}
    {{/each}}

    JavaScript是一样的。

    总结

    为了写这篇文章又去看了一遍Handlebars的文档，发现新增了不少特性，尤其开始支持子表达式，看来有必要再好好看一遍。

  • 近期要学习实践的新技术

    近期要学习实践的新技术

    众所周知，程序员是一个必须随时更新知识技能的职业。这其中，前端程序员尤甚。虽然我自称全栈，多半也要依赖前端技术作为小无相功驱使内力，方能打出少林寺七十二绝技写出其它平台的产品。所以，主动学习，更新知识技能是我必须坚持的。

    同时，在前端这个充满变革的领域，我不能把各种新奇的东西都放到实际生产中去。所以，不定期的集中学习就不可避免。

    那么，近期要学习实践的新技术有哪些呢？

    1. Bootstrap 4
    2. gulp
    3. Angular 2 直接从2开始吧，计划做个Todo
    4. React + React Native 要不做鸡血君？
    5. Polymer
    6. Material Design Lite
    7. Phonegap 5 自然是迁移游戏泡泡
    8. Eletron 结合别的技术做个写博客的工具。
    9. socket.io
    10. browserify

    希望能在年底前搞定。

  • 未命名文章 1978

    React Native开始支持Android了，看来近期有必要去学学看了。做个什么好呢？

  • Mac OS上各种开发环境的配置（未完成）

    Mac OS上各种开发环境的配置（未完成）

    很多开发人员喜欢 Mac OS，因为它基于FreeBSD，有原生的命令行工具，配置各种开发环境都很方便。我个人偏爱Windows，我觉得各种可视化用起来更爽。

    这篇文章介绍如何在Mac OS 10.10 Yosemite上配置各种开发环境，范围以前端所需为主。

    Xcode

    无论你是否准备开发iOS或者Mac OS上的应用，Xcode最新版都是必须的。因为里面包含了系统必须的命令行工具和编译工具，没有它们支持，我们就无法安装后面那些东西。

    好在Xcode是免费的，虽然体积巨大（而且早年不支持断点续传，我第一遍Xcode装了半个月），但只要你有恒心有毅力，智商正常，就都能装上。

    方法：

    1. 打开App Store
    2. 搜索Xcode
    3. 安装
    4. 安装完成后，在命令行里运行xcode-select -p，如果显示/Applications/Xcode.app/Contents/Developer则表明Xcode 命令行工具已经安装成功，否则的话，执行xcode-select --install安装

    homebrew

    工欲善其事，必先利其器。在*nix环境下装东西，一个好的包管理工具是必须的。我使用的是Homebrew，它的安装非常简单：

    ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

    因为Mac OS默认包含并启动了Ruby环境，所以此时系统就开始执行homebrew的安装。关于brew的用法，可以看它的官网，或者运行brew help阅读帮助。

    nodejs

    有了homebrew，一切都好办了。

    brew install nodejs
node -v

    不过我更喜欢标准版，在nodejs的官网下载dmg安装包，直接安装即可。

    ruby

    Mac OS默认包含ruby，不过我喜欢最新版，所以还是拜托给homebrew好了。

    brew install ruby

    homebrew会把包安装在/usr/local/Cellar目录下，然后通过软链接链接到/usr/local。有些系统默认包含的组件已经注册在/usr/local或者/usr/bin，创建链接可能会失败。不用担心，homebrew提供了详细的帮助信息，仔细阅读，按照提示一步一步做，就OK了。

    Python & httpie

    python我用的很少，耳闻3和2差别巨大，也就不敢追新。所以我用系统自带的Python，只是安装了 httpie 这个工具来调试远程数据。安装一样是通过homebrew：

    brew install httpie
http httpie.org

    apache httpd

    Apache httpd是Mac OS的默认组件，直接运行sudo apachectl start即可开启apache服务器，然后访问 http://localhost/ 就能看到默认页面了。

    系统默认的文档地址为 /Library/WebServer/Documents，把静态的页面放进去，就能正常浏览，用来测试还是蛮方便的。不过我觉得不算太实用。因为一来埋得很深，通过Finder无法直接到达；二来作为公司配的开发机，一般来说我不建议在公共目录里做东西。

    不过配置起来也不复杂。打开 /etc/apache2/extra/httpd-vhost.conf，里面应该有两个没有真正起作用的范例配置。基本上按照那里即可。

    先放出去，回头再补充好了……

  • 漏装php55w-mbstring导致中文邮件乱码

    漏装php55w-mbstring导致中文邮件乱码

    朋友的WordPress发中文邮件总是乱码，喊我帮忙看看。很奇怪，后台、文章里的中文都能正常显示，看起来一切正常；我在我电脑上搭了一套，同样的代码，发邮件也没问题。

    后来打开phpmailer的debug模式，发现什么都对，就是中文内容都是问号。

    继续往上找到发邮件的函数，运气不错插件留了filter，遂修改模板，add_filter强制转换内容。

    转换前先检查，不是UTF-8再转：

        if (!mb_detect_encoding($content)) {
      $content = iconv('ASCII', 'UTF-8', $content);
    }
    return $content;

    结果代码传上去报错，说没有mb_detect_encoding，然后想起来yum安装php时确实默认不包含很多扩展，于是手动安装yum install php55w-mbstring。然后重启apache，发邮件测试，正常了。

    我又想是不是缺少多字节文本模块（Multibyte String）导致原先无法发送中文呢？去掉filter，仍然正常，确实如此。

    总结

    yum安装新版php需要增加源，而新版的源默认不包含很多常用的库，使用的时候最好都装上。WordPress的翻译机制面对多字节文本时，编码不对不会报错，也需要小心。

  • HTML5跨域开发

    HTML5跨域开发

    HTML5中提供了跨域加载数据的方法，让我们得以从JSONP或者Flash中介等各种绕行方案中解脱出来，更加顺畅地与服务器交流。另一方面，因为PHP是最好的语言……所以在它与Node.js之间，我选择前者作为后端语言开发内容服务。

    这篇文章记录使用jQuery+PHP开发跨域应用时的小心得。

    身份验证

    做身份验证，最简单的办法就是使用PHP的SESSION保存用户信息，于是就要用到Cookie。默认情况下，跨域Ajax请求发起时候不包含Cookie，需要我们主动将XHR的withCredentials属性设为true才行。

    jQuery会把XHR封装成jqXHR，并且不暴露真正的XHR（说实话这点有点难以理解，尤其是在做上传进度条的时候）。然后它提供一个给真正XHR赋值的接口xhrField，所以写成代码就是这样事儿的：

    $.ajax(url, {
  xhrField: {
    withCredentials: true
  }
}

    各种HTTP头

    如果不需要验证用户身份，直接在HTTP头中输出Access-Control-Allow-Origin: *即可。

    我的产品需要验证，那么首先，HTTP头中必须有Access-Control-Allow-Credentials: true；此时对域的限制也严格许多，不再允许像前面那样使用*放开给任何来源，必须指明哪个具体域可以接受。

    关于Access-Control-Allow-Origin的值，规范中的说明是“域名列表或null”，然则接下来的“注意”有点诡异：“实际生产中，‘列表或null’要求更严格。你可以认为它实际只允许单一域名或null，而非空格分隔的域名列表。”——既然如此你干脆写个“域名或null”不就完了……

    总之对于我们而言，返回的HTTP头中还要包含Access-Control-Allow-Origin: http://域名，指定允许作为来源的协议、域名、端口，并且只能有一个（组）。因为通常来说我们开发环境和生产环境不一样，所以这里的域名最好不要写在服务器配置里；使用PHP，通过$_SERVER['HTTP_ORIGIN']取出访问来源，与白名单比对，通过后再输出相应的头，更加合适。

    调试

    我选择JSON作为前后端交流的格式。为了方便浏览器解析（也是HTML5的要求），我还返回了Content-type: application/json头。

    使用PHP少不了使用Xdebug。出现错误时，Xdebug会返回完整的栈，有利排查。但是为了方便阅读，Xdebug还会给返回信息套上<table>结构，这时Chrome的Network工具就会把它解析成奇怪的格式，所以Content-type一定要最后和数据一起返回。

    与之相反的是前文说到的Access-Control-Allow-Origin和Access-Control-Allow-Credentials，这二位必须放在最前面。不然如果出现500错，响应头不包含这两个跨域标记，Chrome就会理所当然地不显示返回内容，也就无法看到错误描述，根本无法排查。

    参考资料

    1. Using CORS
    2. Cross-Origin Resource Sharing
    3. HTTP access control (CORS)
    4. jQuery.ajax()
  • 企业级开发的碎碎念

    企业级开发的碎碎念

    企业级开发的难点在于从普适性和特殊业务需求中寻找契合点。一方面我们希望框架精致简单又结实耐用；另一方面我们还希望满足各种业务逻辑，并提供良好的用户体验。前者可以降低开发成本，更快改进业务后台；后者则决定了产品本身有无价值。

    碰到细碎的需求点，把哪些实现放到框架内，把哪些实现放到业务内，决定着一个框架的体积、易用性、扩展性。目前来看，虎虾和柠檬草虽然看起来希望很大，但目前尚未及格，仍然需要努力。希望春节可以折腾到及格，节后公测。

    （更多…）

  • composer导致没有log的错误

    composer导致没有log的错误

    我一般使用git pull从Github更新代码。某次提交新版本后，服务器开始报500错误，但是看log什么都没有。反复回想好像上次拉完代码没有composer dump-autoload，而且这个版本确实增加了几个类。于是赶紧生成autoload，故障解除。

  • Yosemite坑真多

    本着顶配解千愁的指导原则，入职2年半之后，借着南迁广州的机会，我向公司申请购置一批新机器。同配置笔记本性能远远落后于台式机，所以我自然而然的选择了顶配iMac 27作为主力开发机。升级CPU和内存的版本没有现货，等机器送到，大约是10月13日。

    关注IT产品尤其是苹果产品的同学可能记得，16日苹果开发布会，推出视网膜屏的iMac，连CPU带显卡甚至屏幕都有大幅升级……顶配的日子只持续了3天……哭昏在厕所……

    这还不是最惨的。更早的时候，苹果发布了Mac OS 10.10优胜美地（Yosemite），直接安装在新机器里，我这台自然也是。新系统有诸多纸面所载的改变，我就不多说了，跟本文关系不大；我只说跟开发相关的这部分。

    403错误

    升级后的Mac OS集成Apache 2.4.9，里面默认启用了authz模块，于是增加虚拟主机的时候，<DIERECTORY>配置里面必须写成

    Require all granted

    不然就会报403错误。我以前处理403都是暴力改权限，这次恨不得把/的权限都改了都没用，后来终于google到解决方案。

    不能使用Homebrew安装的php，以及不能用Homebrew升级php

    我有新版本癖，每周三次更新——使用开源产品的好处就是绝对不怕找不到更新。当我上周例行更新，发现PHP 5.5.19安装失败，报Cannot find OpenSSL's <evp>，因为项目紧急所以我只好先不管它。后面配置apache的时候，发现随Homebrew安装的新版libphp5.so不能用，apachectl -t 检查通不过，只好使用系统自带的5.5.14版。

    今天又google了下，终于找到解决方案。原因没搞太明白，总之是升级了之后 /usr/include 有点问题，需要重新链接一下。正确的解决方案是

    1. 安装XCode最新版
    2. 安装XCode命令行工具（CLT）最新版
    3. 试一下，不行的话重新链接一下 /usr/include 
      sudo ln -s /Applications/Xcode6-Beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include /usr/include
    4. 然后 `brew upgrade` 就可以了

    这样搞了之后新的5.5.19的libphp5.so也可以使用了。

    丢失PNG支持

    如果只是版本低一点，其实是可以忍的。结果Mac OS团队不知道怎么想的，竟然把PHP中的PNG支持去掉了，导致我在本地开发的时候验证码出不来。如前文所述，这次升级本来就有诸多问题，验证码出不来我的第一想法肯定不是看PNG支持。而且，我们一直在用的验证码生成程序中，将生成函数写成 ImagePNG，竟然能运行，也是让我很奇怪……

    换用Homebrew安装的5.5.19 libphp5.so之后，问题解决。

    暂时遇到这么多问题，日后补充。

  • 谈学习：读源码

    小弟交日报，说看backbone和underscore的源码看不懂，我回了邮件给他，摘录于此，表达我对“读源码”这种行为的看法。

    我不赞成新人以“读源码”的方式进行学习，因为相比于看文档、看范例、实操开发，“读源码”的效率实在太低了。

    这是有原因的：

    1. 对于大部分新人来说，多半“单看每个字都认识，全放到一起就不知道啥意思了”……速度上不去，只能看懂“how”，无从知晓“why”。最后虽然知道原作者用的A方法、B方法、C方法，但到实战的时候，还是不知道怎么做。
    2. 流行的库和框架，大都经历过数年的升级演变，甚至几千次提交，和早年刚出现时相比面目全非，逻辑也不再是浅显易见的。“读源码”不包含演进的过程，上来就是别人提炼过、推导过的精髓，更加难以理解。
    3. “读源码”难以获取成就感，因为成果难以衡量，里程碑难以界定，学到多少东西更是只有本人知道。把这个当某天的内容报告给领导，等于明确表示自己工作量不饱和，很可能招致领导的不满。

    源码完全不该读么？自然不是。那么什么时候读呢？当技术精进到一定程度，或者业务诡异到一定程度，我们自然会遇到前人没有遇到过的问题；或者发现文档中语焉不详的地方。这个时候只能通过阅读源码找答案，而且这个时候读源码也是很合理高效的。因为：

    1. 很可能读源码是唯一途径。
    2. 带着问题去读，目标集中，效率会很高。已经知道了“Why”了，只关心“How”。
    3. 解决目标问题的过程中，可能学到很多之前不知道的东西。