和 @暗黑天马夏澈丹 合作完成的TCG火纹FE0的在线卡查的第一版上线了 虽然界面有些磕碜 但还是欢迎大家来测试 =w=
TCG《火焰之纹章0》中文在线卡查上线啦！
收录了目前为止所有预组、补充包、PR卡的中文信息，官方Q&A，以及游戏规则。
支持电脑端与手机等移动端浏览哦！
《火焰之纹章0》卡查地址：http://fecipher.card.moe
开发：SmdCn 翻译：萨莉雅 (微博：http://weibo.cn/tcgfe)
原作： Nintendo / INTELLIGENT SYSTEMS
虽然说一直都没有停止过做让自己玩起来都觉得很有意思的游戏的尝试，从最初H5的解密游戏「Metispace」，到基于AIR的跑酷游戏「Rabit Hole」，再有Android原生的「Circle Cutter」，以及到后来参与了朋友的iOS解密游戏「Part of Me」。当然，也还有无聊的时候一些奇奇怪怪的尝试，不过基本都停留在自娱自乐的阶段，最多投投比赛，从没想过把一个游戏呈现到广大用户面前会是怎么样的，适逢微信H5的热潮，就和朋友一块尝试做了一个基于HTML5的微信游戏——「挖红薯大赛」。
这是一个帮线下实体店设计的一个相当简单的游戏，玩家需要做的仅仅只是滑动屏幕，移动人物去挖红薯，并且使得自己挖到的分数尽可能的大，和其他微信游戏一样，你还可以在朋友圈和其他朋友分享你挖到的分数。
不过难以置信的是，就这么一个简单到不能再简单的游戏，还没有开始推广，并且宣传游戏奖励的情况下，仅仅因为测试人员在朋友圈的分享，就取得超乎意料的活跃度，还有相当数量玩家连续好几天重度一样的玩。甚至游戏在地方形成话题，并且有根本不认识的人为其撰写我都没研究出来的游戏攻略，一直都在媒体上在看人讨论微信朋友圈的力量，这回真是真的切切实实的感受到微信社交圈子的可怕。
虽然说只是一个营销用的小游戏，虽然说也和以前一样有着「其实还可以做得更有趣」这样的遗憾，不过每一次的尝试都还是觉得挺开心的。如果亲也很无聊，那也来微信扫一扫下面的二维码解解闷吧（咦
在使用PhoneGap制作App的时候，iOS作为承载App页面的容器的Webview，在手指向下或者向上滑动屏幕时，除了页面本身的滚动外，还经常会看到整体页面底部和屏幕底部被拖动出黑屏
为了防止这一滑动，可以通过修改修改项目中的MainViewController.m，重新设置WebView来实现
- (void)webViewDidFinishLoad:(UIWebView*)theWebView
{
// Black base color for background matches the native apps
theWebView.backgroundColor = [UIColorblackColor];
[(UIScrollView *)[[theWebView subviews] objectAtIndex:0] setBounces:NO];
return [superwebViewDidFinishLoad:theWebView];
}
试用Azure过程，建立了几个VM，然后因为要在不同区域设置存储，却发现存储到达上限了，于是需要把系统默认的存储删除，但是把该存储相关的虚拟机都删除之后，进入该存储，依旧无法删除存储下面的VHD，提示
There is currently a lease on the blob and no lease ID was specified in the request.
重新回到Virtual machine，检查确认确实没有关联的VM，但是为什么还是无法删除呢。
于是翻看Virtual Machine下面的Image和Disk标签，发现在Disk标签下面依旧有这个VHD的记录，虽然没有被挂在到任何的VM，可能是之前删除操作执行过程中没有勾选合适的删除造成的。
于是在Disk标签下删除该关联磁盘，然后重新回到存储下面就能够正常删除VHD和存储了
跨域一直以来都是个非常神奇，又非常普遍的问题。出于安全等因素的考虑，通常情况下，浏览器通常会仅限制资源的访问，XHR(Ajax)的跨域请求是不被允许的。
但跨域的需求却一直都在，为了跨域，勤劳勇敢的程序猿们想出了许许多多的方法，例如，jsonP、代理文件等等。但这些做法增加了许多不必要的维护成本，而且应用场景也有许多限制，例如jsonP并非XHR，所以jsonP只能使用GET传递参数。
在移动应用风生水起的如今，托HTML5的福，Mobile Web，甚至Hybird App也逐渐火起来，在本地文件系统的Web页面，也有需要获取外部数据的需求，而这些需求也必然是跨域的。同时，HTML5也来带了叫“Cross-Origin Resource Sharing”的新特性，来赋予开发者权力决定资源是否允许被跨域访问。
Access-Control-Allow-Origin
CORS通过服务器增加一个特殊的Header[Access-Control-Allow-Origin]来告知客户端跨域的限制，如果浏览器支持CORS的话，如果判断Origin通过的话，就会允许XHR进行请求，而不需要再使用jsonP或者代理文件。
使用这个Header返回被允许请求跨域请求的来源域，例如网站duelist.cn设置了下面的Header
Access-Control-Allow-Origin: http://smdcn.net
这样设置之后，通过http://smdcn.net下的页面对于duelist.cn进行ajax请求就会被允许，而其他网站对duelist.cn依旧会被阻拦，通过这种方式网站拥有者可以自己对此进行限制。
当然，如果不想限制来源，可以通过
Access-Control-Allow-Origin: *
来允许任何站点对该资源进行跨域请求
关于CORS的浏览器支持情况（caniuse cors)：
* 主流的移动浏览器：√
如果想要需要对于IE8和9支持CORS：可以使用jquery.iecors
设置CORS
对于客户端来说，一般来说不需要进行额外的设置，只要保证浏览器支持CORS即可
对于服务端，需要给支持CORS的资源增加Access-Control-Allow-Origin的Header。
可以通过HTTP服务器进行统一的Header设置，如果执行的是程序脚本，也可以在程序脚本中加入。
例如，PHP的话，使用
Header(“Access-Control-Allow-Origin:*”);
更多关于CORS的使用参考：http://enable-cors.org/
关于Android浏览器的注意事项
在某些版本的Android浏览器中，因为缓存的原因，第一次进行CORS是正常的，但是第二次进行的时候则会失效，对于这个问题，可以通过在Header中增加Cache-Control: no-cache 阻止缓存的方式来解决这个问题
关于跨域请求读取Cookie的需求
CORS的跨域请求默认情况下不发送本地cookie，同时也不接受来自服务器的cookie。
在跨域请求中读写Cookie并不被推荐，但是如果非要使用Cookie的话，需要在服务端返回是增加Header：
Access-Control-Allow-Credentials:true
同时ajax请求时，对XMLHttpRequest对象设置withCredentials = true;
var xhr = new XMLHttpRequest();
xhr.open();
xhr.withCredentials = true;
因为毕设需要，这段时间就一直在做基于HTML5 video定制的播放器，因为开发和测试过程也一直都是配合Nexus7的Chrome进行测试，所以本以为Android上应该会是最为顺利没有问题的，但是在经过PhoneGap封装测试时，发现在iOS上完全正常，但是在Android上反而没办法播放了。
问题出现在用Android的Webview在播放应用assets中视频的时候，但我尝试把视频地址改为互联网地址的时候就正常了。
经过反复测试，发现使用HTML5访问应用资源目录的时候会存在Android权限限制的问题，不过访问sdcard是能够正常使用的，也就是地址是：file://sdcard/ 下的就可以正常使用了。（对于远程文件下载到本地后播放直接下载到sdcard自己的目录即可；如果原先视频文件已经在assets目录的，则可以在启动WebView前复制到sdcard）
上述测试的环境为 Nexus 7 (with Android 4.4.2) / Android 4.4 SDK
PS：
网络上还有说HTML5播放视频需要在AndroidManifest.xml开启硬件加速
<application android:hardwareAccelerated="true"
我用PhoneGap的时候默认生成的就已经是开启的了，就没作另外的测试。
最近尝试用CSS3等一些新特性做一些页面，并在做了一些兼容处理之后，支持了IE7，但是碰到邪门的问题就是哪怕机器上的IE装的是非常新的10、11这样的版本，在使用WebBrowser查看页面时依旧会出现各种渲染和JS错误，甚至会出现崩溃的问题。比较残念的就是因为很早以前制作的桌面程序中正好使用WebBrowser 调用了这些新页面 √(─皿─)√
查阅MSDN时看到
Web browser control by default runs in compatibility mode unless you set the feature browser emulation registry key.
WebBrowser 控件默认运行在兼容性模式，除非修改注册表键值
于是我的心中真是无数的草泥马在奔腾啊
解决的方案是，在注册表
32位系统的：HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
64位系统的：HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
新建一个DWORD键，
键名是你调用WebBrowser的exe的文件名
键值：
Value Description 11001 (0x2AF9 Internet Explorer 11. Webpages are displayed in IE11 edge mode, regardless of the !DOCTYPE directive. 11000 (0x2AF8) IE11. Webpages containing standards-based !DOCTYPE directives are displayed in IE11 edge mode. Default value for IE11. 10001 (0x2711) Internet Explorer 10. Webpages are displayed in IE10 Standards mode, regardless of the !DOCTYPE directive. 10000 (0x02710) Internet Explorer 10. Webpages containing standards-based !DOCTYPE directives are displayed in IE10 Standards mode. Default value for Internet Explorer 10. 9999 (0x270F) Windows Internet Explorer 9. Webpages are displayed in IE9 Standards mode, regardless of the !DOCTYPE directive. 9000 (0x2328) Internet Explorer 9. Webpages containing standards-based !DOCTYPE directives are displayed in IE9 mode. Default value for Internet Explorer 9.Important In Internet Explorer 10, Webpages containing standards-based !DOCTYPE directives are displayed in IE10 Standards mode. 8888 (0x22B8) Webpages are displayed in IE8 Standards mode, regardless of the !DOCTYPE directive. 8000 (0x1F40) Webpages containing standards-based !DOCTYPE directives are displayed in IE8 mode. Default value for Internet Explorer 8Important In Internet Explorer 10, Webpages containing standards-based !DOCTYPE directives are displayed in IE10 Standards mode. 7000 (0x1B58) Webpages containing standards-based !DOCTYPE directives are displayed in IE7 Standards mode. Default value for applications hosting the WebBrowser Control.
之前提到说通过Vagrant部署开发环境，使用目录共享模式，在本地磁盘进行开发，而通过虚拟机环境运行开发的页面。
是的，一切看起来都是那么的顺利，首先基于VirtualBox安装了Vagrant，接下来，按照以往部署环境的习惯，在VM中安装了nginx作为开发运行环境，并且将本地的共享目录作为nginx的web目录，然后打开页面，看上去似乎都很正常，但接下来，你发现了一个神奇的事情，你修改替换了一个css，一张图片，然后刷新浏览器，发现什么都没有变，然后你有非常猛烈、使劲的F5，依旧还是没有改变，是的，你看看编辑器，似乎替换是正常的，在看看VM上的文件，也都是对的，是的，尝试重启nginx，依旧没有任何变化，你开始怀疑php5-fpm甚至于毫不相干的memcached和mysql，但都无济于事。也不知道是什么让这些文件被“缓存”了呢。
当你尝试修改一个js，并且用同样的方法更新之后，会遇到类似的问题，是的，就算重启VM上任何服务，甚至重启VM，依旧没有用，当然，比起其他资源文件，浏览器的反应会强烈一些，因为浏览器会提示未知错误，而你通过浏览器查看你修改的JS文件，会看到文件尾巴有下面奇怪的随机字符：
�����������������
这到底是什么东西呢？编码错误？缓存异常？又或是其他什么？
是的，你尝试花费很多时间，试验各种各样的方法去解决这个问题，其实对于nginx来说，你只需要修改配置文件(nginx.conf)中的一行重启就能简单的解决这个问题：
sendfile off;
找到 nginx.conf ，把里面的 “sendfile on” 修改为 “sendfile off”。
当然，如果你使用Apache也可能遇到类似的问题，那么同样也有类似的配置需要修改：
EnableSendfile off
关于这个问题的参照：
https://github.com/mitchellh/vagrant/issues/351#issuecomment-1339640
http://stackoverflow.com/questions/9479117/vagrant-virtualbox-apache2-strange-cache-behaviour
做Web开发少不了要在本地搭建好开发环境，虽然说目前各种脚本都有对应的Windows版，甚至是一键安装包，但很多时候和Windows环境的相性并不是那么好，各麻烦的问题是实际部署的环境通常是Linux，常常还要面临着开发和部署环境不一致，上线前还要大量的调试。更要命的是，如果有很多机器需要装的话，那就真是一个灾难了。
Windows下玩Linux少不了虚拟机，但装系统依旧是相当费事。在现在什么都在自动化的今天，Vagrant就是这么一个神器，基于Ruby开发，使用开源 VirtualBox 作为虚拟化支持，可以轻松的跨平台部署。
今天试着把几台机器的环境都换成Vagrant，很爽很顺畅，于是就试着整理了一下使用小结：
最近在帮人做一个应用，需要在“各大”开放平台站内应用中上线，本来以为吧，之前做过各个开放平台的帐号oauth同步登录之类的，和简单的接口发布什么，也都做得很顺，算是对开放平台还算比较熟悉，做起站内应用（非游戏）才发生，各种坑。而且这次做的应用有个更为坑爹的要求是不能用PHP，得要用C#，当然，作为站内应用，还必须配合JS SDK。于是万里长征快到头，便想好好总结(tucao)一下。
虽说总结的东西其实都是有时效性的，但还是拿来分享一下~
涉及到的开放平台有下面几个，虽然不全，但算是目前比较主要的几个：
腾讯系：腾讯微博、QQ空间、朋友网
新浪微博
人人网 继续阅读主流(大概)开放平台站内应用开发总(tu)结(cao)