SolidMCP开篇
来龙去脉：
何为SolidMCP？
Solid+Maode+Chengzi+Piaopiao.
为何SolidMCP？
博客名，邮箱名；
还是代码农夫Piaoger的试验田；
试验田内，会有我重造或仿造的轮子，也会有可以收获的成果。
对于SolidMCP这块试验田，有一些初步的想法：
>Revisiting SolidMCP
做一个Revisiting，轮子不管是自造的还是仿造的，都应该有些文字来解释它的工艺。
感觉无论是C2C（Copy to China, or Shanzhai）还是Revent，都能接触和学习更多的东西，绝对善哉。
至于Revisiting的方式，Blog、docbook、TiddyWiki、Comment in Doxygen Style甚至更多的Unit Test Cases的形式,皆可。
> 重构
经过长期积累，SolidMCP已经是一块不小的试验田，但田大了，阡陌交通，一定是需要一些重构的。
不少东西，都还只是一个Dummy implemetantion或者说Placeholder，需要填充。
有些东西属于急就的产物，需要“被和谐”；几乎所有的工程都只有Win32-Debug Configuratoin。
Modularity、Pluggability、Extensibility、Implementation Hidden甚至Code Style都需要Revisiting。
> 增强TDD或者ATDD的思维方式
此前的SolidMCP，尽管用TUT写了一些Test Cases，但究其目的，并非Unit Test，更谈不上TDD。
说白了，是利用TUT便于注册Test Case的功能，做了些Coding First and Having some simple tests的事情罢了。
即便只是剽窃了Unit Test的名头，终究无需为每次的小小测试和学习的Tips写一些名字类似“qesdf”或者“adfs”之类的的工程了，并且能把这些小东西很规整的保存下来，大有裨益。
成果就是：
在我的SolidMCP Solution中，每个模块内都有一个iTest和iTry文件夹，iTest用于类级别的Test Cases，而iTry则是该模块相关的一些Try Cases。
-------------------------------
-------------------------------
在Network模块中，我仿造CURLPP用C++封装了一把LibcURL，然后在此基础上写了一个OAuth客户端的东西。
iTest/OAuth/Test_OAuth.cpp包含了SolidMCP OAuth的一些基本的Test Cases，基本能访问了公司的OAuth服务还有http://term.ie/oauth/example。
iTry/LIBOAuth/Try_OAuth则是把liboauth弄进来，并把它本来的一些例子弄成一些TUT支持的Test Cases，搞成Try Case了。
JSON也是如此。我甚至有一个专门的iSurfing/Booster用来玩boost内的一些玩意儿。
> Domain-specific
Framework最终总是要为Application服务的，所以随着Framework的不断丰满，Domain-specific Applications也需要多起来。
最终SolidMCP应该是一个集Networking、CAGD、Graphics一体加上N多Utilities的Application大杂烩，至少要有一个朝这个方向发展的Application。
也许永远等不到那一天，那时候一定是心累了，疲了。
> Build system
从一开始，SolidMCP就考虑了Cross Platform。尽管它现在还只是Windows Spcific，但并不排除某天高兴了，也去玩玩iApps。
支持Cross Platform自然需要有Cross Platform的Build System，否则维护代码将成为恶魔。
现在我可能考虑的Build System有三个，各有所长：
CMake: http://www.cmake.org/
SConscript: http://www.scons.org
Premake ：http://premake.sourceforge.net/
说实话，我现在比较偏向于基本Python的SConscript，定制能力超强，但不能产生VS或XCode的Project/Solution，对我习惯了VS的人来说，很有些不适应。
CMake呢，虽能生成VS或XCode的Project/Solution，搞一堆ALL_BUILD和ZERO_CHECK之类的，也太难看了些。
倒是premake，在这方面倒是很照顾广大人民群众，搞一个lua脚本，就可以帮你搞定，包你清爽。
其实这三个东西用得都不少，据我所知，SConscript有Google Chrumium， CMake有Blender/KDE， Premake有ODE。
而且，KDE在迈向CMake的过程中，还宠幸过Scons，但最终放弃。>>
> Source Control
至于Source Contorl，自己搞的Perforce Serve早已名存实亡。重装电脑，把之前的P4 Server整没了，所以现在基本上还是Backup with Copy的作坊式方式。为了保险起见，隔段时间还得在家里的大硬盘上Backup一把。之后应该会考虑一下基于Python的hg(Mercurial)的分布式SCM工具，它的IDE叫龟公TortoiseHg。
此外，对于代码的托管，有5种选择Google Code、 sourceforge、Monotone、bitbucket和GitHub。现在我比较倾向于bitbucket，毕竟它是基于HG，在被JIRA/ConfluenceWiki它爹收购之后，前景更明朗一些。至于Google Code，实在是怕被封，还有GitHub，其实老早就申请了帐号，但考虑到以后会在建立加一个基于HG的资源管理环境，那暂时还是考虑HG吧。
不过这些都是后话了。当然了，也许可以把Blog一些代码附件放在上面。
不过从另外一方面来讲，这些东西的离线应用是不错的，比如：
Monotone is implemented in modern-dialect C++ on top of the Boost library, the Botan cryptography library, and the SQLite database library.
> Scripting support
Binding：
一直梦想着SolidMCP有自己的Python绑定，这样的话，核心代码用C++写，其他就用Python代劳了。
另外一种比较好的Scripting语言是Lua，在游戏引擎中用的很多，号称Apple App Store几个卖的比较好的都用Lua来做Logic。
另外还有可能在一部分场合会用到JNI，便于创建Scala（JVM） & C++的Hybrid Mode。
现在看来还是个梦，不过之后的重构或新写的东西要朝着Easy of Binding方向前进。
Development Environment：
现在的Development Environment还是BAT为主，另外有一些Python；
之后应该以Python为主，为基于Python做一些小的工具。
> Align with New Stardard
SolidMCP的一大部分都是C++的，随着C++ Next Standard的发布，需要做一些相应调整。
后记：
刚才在FeedDemon收Feeds的时候，发现Codenow.com发了一篇《如果从头开发新的3d Engine》，有些感触。
不过，遨游在技术的海洋，总是没错的。