@jiych "还建议住的离公司近些"

这句真的不敢苟同。。。。以前在广告公司上班，离步行公司5分钟距离，曾在晚上2点被老板电话叫起来的路过。

要我说啊，这个。。。嗯，还是距离产生美。

我觉得v2ex也不靠谱。个人见解是v2ex主要的问题还是太出名人太多了，哪怕现在看来很高端，但，恐怕难免慢慢就跟早先落伍者之类的一样，落俗套。

可能是我这人很小众，注册的社区很多都是很少很少人注册的，整个社区活动用户也就几十个。一些社区能让你感觉像家一样，舍不得走，哪怕十天半个月不去，也肯定会惦记着。

@missdeer 楼主，我是建议你去建议别人回你帖子的时候要声明现在的职位。不信仔细看下帖子。

建议楼主附言建议各位发帖前先声明自己的职位，以便清楚的了解各方面的立场。

=代码

@darasion 谢谢提醒，这个我也想过的。有的时候造个轮子也是没办法的事情。

我做第一版本框架的时候留下了很多缺憾，如果不能在这个框架中补全，写新东西也就没意义了。

必须新的PDO管理器是其中之一，可以在放弃（比如JOIN之类，但是可以通过多查询替换）一些SQL语句的前提下实现多服务器分布操作。程序通过调用来选择数据库，未来可以实现部分透明的分布式储存。可以自动通过表名和读/写选择对应数据库进行连接，以便实现数据库方面的负载均衡。

以往这需要更复杂的后台程序实现（比如写个PHP扩展之类解析MySQL语法然后再调用），现在虽然效率比较低，但是框架自己就能做了，服务器上不需要添加任何支持，配合多Web服务器，负载就能提升不少。

但是现在市面上的那些ORM，很多都封装好了PDO和SQL操作方法，未来如果要切换数据库，还得换一个ORM或者去改写它，这样就很麻烦。而且很多都是有版权这样的，比如很多是用的GNU GPL，而我的协议是LGPL，用户可以不开源使用这个框架构建的项目。

于是乎最终还是决定自己搞定。当然，我觉得写这些还是很有意思的（即便虽然意义不大），这才是最主要的动力。



关于防止破坏项目结构。这个我一开始也考虑过。首先，我用的方法名都是比较通用的，很容易记忆。

另外为了“防止”别人为了加功能而修改。。。。。。。我将框架做成了None-Stack的。事实上它自身连路由都没有实现（因为很多人想要自由的使用URL，然后跟我吐槽半天CI和YII之类的）。

这也就意味着，“若需要，请自便。”。

框架本身（对我来说）是一个提供代码整合和基本接口调用的平台。本身不应该干涉程序员所写程序的风格。为了达到这一目标……也就不要“自作多情”的提供一些不太必要的功能。

于是，我框架的主要子核心也只有：调试、对象管理、请求、响应 这4个模块。PDO管理器都给我放在了可选核心里（即可以禁用）。

（定义：子核心：每次页面访问都必须加载的单元模块，无论是否调用。）

所以我想，仅仅这几个文件都手痒要去改，那真的得拿小尺子打手了。

当然，如果你真的要改。。。。。。。。。。。所有自带的子核心都是符合简单工厂模式的。也就是说，你可以用自己写的子核心替换框架的子核心。初始化之后项目代码可以无缝切换到你自己写的子核心上。当然，自定义子核心的代码必须接口兼容。

如果你对现有核心不满意，你还可以新建子核心，框架会在初始化之后找到这个核心，然后“同等对待”的初始化它。然后你就可以在自己的项目里自由的使用这个核心了。

好吧，我猜测这样就能解决各种不满了……

@66beta 貌似这不是我的问题嗯。

@vigoss @darasion 哎，悲剧。错就错在写PDO管理器之前没想ORM的事情。写好发现很多ORM都有PDO的功能了，而且还都是给数据库信息直接给连好，跟我的接口一点都不兼容，不管怎么写胶水。所以只能自己再写个ORM搞定这些。

@picasso250 看来MSSQL和MySQL的语法就是太不一样了。看来只能先自己写个MySQL的驱动操作类，以后的事情以后再说了。

谢谢各位。

@Perry 那么就TAB不能用好了。反正一混用就悲剧，特别是拷贝代码的时候，这个文件是TAB，那个文件是SPACE。

http://www.emacswiki.org/pics/static/TabsSpacesBoth.png

@ccbikai 还真是：for PHP, App Engine offers deep integration with Wordpress.

太好了，终于不用再“忍受”Python的缩进了，必须承认用到现在还没习惯能Tab和空格混用的缩进方式。自己Mod一下GAEAgent，就是因为这个调试了好几次。希望什么时候Python空格缩进不能用，只能用TAB。

@nick32m 嗯？这是在说我么？是的，我是抱怨中文翻译不好来着，但是又不是我一个在抱怨，好多志愿者都在抱怨，说翻译协调不管事： https://www.transifex.com/projects/p/bitbucketorg/language/zh_CN/discussions/

我是启用Bitbucket的中文来着，但是只是为了看看我翻译的那些有没有部署到Bitbucket上嗯，虽然只是很小啊很小的一部分。

楼主，建议不要参合别人的习惯。

最好的方式就是，自己提升自己的技术水平，等你的水平高了，达到别人羡慕的水平或者得到老板的嘉奖，别人自然会有意无意参考你的言行而行动。届时如果其他人也用了用Google，发现搜索效果比Baidu好，那么会很自然的从心底里切换过去。

相反，如果用显性劝阻的方式，别人可能会因为不情愿而抵触。这样可能反而同时降低了Google和LZ自己在别人心中的位置。

楼主带一小瓶便携式氧气包，然后在身上纹好中国大使馆、美国大使馆、CNN、BBC等的电话号码。嗯。

@swulling 请问你这是认为我的观点错误了想要纠正还是作为一个GitHub用户要捍卫GitHub？建议你理解我的意思然后再回复，不要无谓的就让帖子进Troll了。否则我只能先把希特勒牌亮出来结束这个讨论以便节省我们共同的时间。

我并未指出“免费给public repo就错了”，所以你也完全无必要用“免费给public repo就不错了”来反驳。

我的意思只是多了一种选择更好而已。毕竟有些代码还未到成熟的时候，不应当公布，否则会造成各种问题。

所以介于这种情况，选择公/私有自由可自由选择的仓库则是最适当迁移成本最小的。而且可以保证项目从一开始就可回溯，有完善的Track和Issues，并早已可以进行更迭。且当产品适合公开之后，只需要轻点设置，一个完整可用且不间断无碎片化的仓库就呈现在所有人眼前了。

当然我并不比较公开和私有仓库谁更好，因为选择很多，而且其实自己维护一个Git仓库也很简单（好吧，我自己喜欢Mercurial，只看过Git的部署文档，所以其实并不真的知道这一点），所以没必要强求某个网站必须提供私有的仓库来用。

我觉得这更多是个人选择的问题，根据自己的习惯选择最适合自己的。比如我VCs中可能会有不完善的概念代码，这些代码刚刚好能够运行，但是我想做的更好，于是我会将他们同步到VCs的测试分支/仓库中，然后换个地方接着改，所以我肯定会将这个设定成私有。显然如果有和我习惯一样的人，就不太适合GitHub，所以我一直在用BitBucket。

当然，其实很多人将GitHub这样的仓库当作分发工具用来着。这个时候公有没有私有仓库其实也无所谓了，因为你肯定也有一个私有的VC来真正做版本管理，以便内部配合哪怕是为了下班继续写代码更方便。

下面的文章其实很有启发性：
http://www.williamlong.info/archives/3435.html

@swulling 可能表述不够好，就是不开源就不给你用反倒不够好，Google Code其实也是。有些代码还不稳定不太适合开源的。好在有一些免费的私有仓库。

很久以前写了个网站，要求用户使用邮件激活，就是邮件给个链接让用户点。

运行了很久一直很正常，然后，有人用QQ邮箱注册。。。。您猜怎么着，账户自动激活了。

@RelativeLayout 还真“有”，https://bitbucket.org/explore。

但上面这个链接其实会跳传到仓库搜索里去，实际也没有任何仓库显示，除非真的搜索关键字。这可能解释了为什么Bitbucket不那么出名。