@loryyang 我昨天已经通过浏览器自身的Bug提交功能提交了Bug。但是我深刻怀疑成功了没。

另外介于Google越来越傲慢，可能他们现在应该已经采用样本统计和筛选的方式来进行Bug修复了，因此我觉得因为我这份单个样本修复的可能性很小。

所以我已经整个平台切换到Firefox了。未来说不定Chrome团队自己会发现问题然后修复的，或者在某次不经意间修复了问题。

@zoudm 不，Chrome之前被我逐渐调校到无视墙的存在了，突然换了一个浏览器，自动代理切换太烂太难用，添加规则太憋。然后同时也就重温了很多网站持续被墙的感觉。

@kokdemo 前端……我能说……其实就是这么憋的……么？

还是放轻松好好把字填上去吧。

@kokdemo 写一个页面来产生json。

另外你们公司只有你一个程序员？或者你进入了一个外包建站公司？

建站公司的话，“程序员”和“打杂的”区别不大。

这态度想赢很难啊。

分明就是一种被揭短了恶意报复的心理。

个人觉得王自如自己做点视频赚点钱没什么不可以的，不可以的地方在于后面收钱黑人。

但是老罗拿这个做完能挡箭牌，不承认自己产品的问题才是有问题。老罗真的是黑的一手好自己，真是配他那个擅自己嘴的经典场景。

@loading 不要太在意那些细节…… :|

@aeshfawre 你的情况和我是不是一致的？如果是的话或许我们应该提交一下Bug报告。

@xuc 也怀疑是个别随机性的问题。但是找不到任何解决方案，包括去关DirectWrite。

而除了这个之外没有任何异常。

话说今天用了Firefox才知道GFW屏蔽之严重啊，很多经常用的服务其实是被封的。包括Imgur这些，还有很多服务变得非常不稳定，哪怕不是GFT家的。

来了张图给大家感受下卡状：
http://ww4.sinaimg.cn/mw1024/005tffwZgw1ejrlvl3of9g30lt04o4i2.gif
其中chrome://newtab的切换速度是正常的，但是chrome://newtab切换到任何一个正在打开的页面都是卡的（正常情况300ms左右吧，没有录制的着么卡）。总之就觉得憋屈不顺畅啊。

@myang 是的。

我还是暂时Firefox先用着。本来也打算逐渐将部分软件依赖迁出Google体系的，就当一次机遇好了。

@imskull 不，我还没下64的，就是32位自动更新的。然后就感受到无与伦比的……卡憋。

@reeco 但是它会自动更新啊。我今天就是手贱点了自动更新。

@moname 说真的……还没试……

刚刚切换到了Firefox……

其实……试用了下Firefox还是卡……但是至少切换标签不卡，正常使用也不卡。

Chrome真的不知道怎么了。

@Showfom 还是看频率吧，有长有短不一定的。

http://i.imgur.com/OZTZANS.png

这还真得看老板人品。

> ……补），我说1K，他即言我敲诈。……

之后又

> 一年过，前几天打电话我，说网站不可访问，且日前客户咨询繁忙，火烧眉头之急

做好人应该是面对其他好人的时候。对一个狡诈的人善良，是对自己善心最大的伤害，因为一旦蒙受损失，你未来很可能对任何人都会有提防以防自己受损，真正的好人因此得不到你的帮助。

选了我，骗了我，还要继续行骗？

既然老板人品这么差，没必要好心，作为纯粹的商业行为进行处理。你可以跟老板签订协议，一年有限次数技术支持，无限次数电话咨询（限定来话时间段），提供适当解决方案，自己不要进行操作，6000~10000元/年（根据网站盈利的百分比计算）。无合同，不维护。

@n 真的呢。。。stdownload.jsp下回来了……

@kenshin

我觉得你这涉及到框架实现的问题。我一直认为使用全栈框架的风险很大，就不说迁移了，万一框架内的bundle有Bug（比如因为使用不当造成），那么隐患相当大。

我在个开发框架的时候（哪怕是给自己开发），通常都是选择最保守的路线（方针是“我是最笨的，别人有权利作选择”），不做大而全或者提供具体的功能（比如ORM这些（好吧，我的框架虽然是有，但是被独立放到了单元的部分，非框架组件）），仅仅面向项目管理，比如提供稍微强大的组件加载和管理功能。其他功能一律作为可以替换掉的组件。

如果开发者需要具体功能，可以使用Composer来管理自己的组件依赖等等。所以我框架做出来，严格来说仅仅只是一个按照一定规则进行组件加载的加载器，然后剩余的东西基于这个加载器规范进行管理。将框架本身的能造成的风险降到最低。

以上。



当然，我不会拿我自己这个框架作为负载产品的底层结构推广给公司用，理由倒不是不安全，而是这个框架的设计本身就不是为了敏捷开发。甚至于会降低开发速度（你必定需要写一些自己的组件，因为框架不提供），不适合互联网公司的开发。

而我开发这个框架是因为：

1、我不想总是跟在Laravel等一堆框架们后面等它更新，或者在它更新之后尝试让旧项目兼容新的框架。而我自己的框架做到现在最让我头疼的一次兼容性更新也仅是更换模板引擎（是的，要改模板），而我其实也能让它不需要更新就能兼容（重新打包下旧模板引擎然后设定下就可以了，但我想使用新模板引擎啊）；

2、很多MVC的项目的基本文件结构都是M一个大文件夹，C一个大文件夹（比如Controller\User\Account\Register\API这样的结构），V一个大文件夹。嗯，没错，我一开始也是这样用。但是当我项目里有100来个PHP文件飘在里面一层一层翻文件夹的时候真的感觉一点都不惬意。于是根据我的需求，我把一个大项目拆成了若干个小项目（我叫做Package）。这样文件结构就变成了类似 User.Account.Register\Application\Controller\API，虽然是换汤不换药，但是文件结构瞬间好了很多有没有，至少能让精力可以锁定到这个Package里，现在200多个PHP文件了，但是管理起来依然轻松。想如果用其他框架的话，想要这么做，得付出更大的努力才可以（但可能别的框架不需要翻文件夹？）。

3、不想妥协的接受某些设定。就拿配置全局访问设置的例子，配置有些在数据库里，有些在本地配置文件里，有些设置不需要加载，有些配置应该在使用的时候自动加载并更新缓存。一些框架很麻烦，多多少少得造点轮子。于是我造了个大轮子，我让自己的框架支持了分区自动加载，通过命名空间来自动预加载某些文件以便初始化。总归来说就是不妥协。

轮子不造，怎么知道好不好？我的观点是不论对不对，先造个出来玩。何况轮子造好之后很有意思+能学到很多不是么？

@kenshin

> 或者换个角度说，如果我开发了一个类似Cairngorm的框架，那么我哪里有时间做项目，这样本末倒置了

这是说到点子上了。

我自己开发的网站因为别的框架不好用（完全无法满足自己的需要），于是用PHP写了一个完整的非全栈框架。后来你猜怎么了，维护这框架占用了我大部分的业余时间。好在后面框架成形了，可以用来搭建一些项目，不然时间就真浪费了。

@kenshin

> 自己写框架（越写越觉得自己的渺小）

你怎么会有这样的感觉？是因为需要解决的问题太多了？

好吧，我在自己的项目里用了@paulguo家的 http://juicer.name/。

不是前端，但是觉得足够好用了。