天道酬勤

本文介绍了项目持续集成工具Jenkins的安装部署过程，以及与版本控制系统Git的配合使用，最后通过详细的例子介绍了应该如何建构一个持续集成的项目管理。其中，解决了很多安装部署中遇到的问题。

"使用ctkPluginFramework插件系统构建项目实战"，这篇文章是写博客以来最纠结的一篇文章。倒不是因为技术都多么困难，而是想去描述一个项目架构采用ctkPluginFramework来构建总是未尽其意，描述的太少未免词不达意，描述的太多又显得太啰嗦。有些看过之前写的【大话QT之四】ctkPlugin插件系统实现项目插件式开发这篇文章的朋友也想了解一下到底如果从零开始架构一个项目。在写这

ctkPluginFrameWork是

QT制作多语言包，实现多语言切换。

本篇文章是对【大话QT之十二】基于CTK Plugin Framework的插件版本动态升级文章的补充，在上篇文章中我们阐述的重点是新版本的插件已经下载到plugins目录后应该如何更新本地正在运行的程序，是整个插件升级实现的后半部分。本篇文章就来讲述软件自动部署（当然，也包括插件升级）的前半部分。        我们必须有这样一点认识，即：我们的程序是运行在用户机器上的，插件更新不是我们手动

应用需求：        某些场景下我们可能面临这样的问题，在运行着的应用程序不能终止的情况下，升级某个功能（或添，或减，或修改）。在不采用CTK Plugin Framework插件系统架构的情况下这将是很困难的，我们需要停止运行程序，然后在相关代码中作出修改，然后再重新编译，再重新启动我们的程序。而如果是基于CTK Plugin Framework插件系统架构构建的系统，则很容易的实现插件

需求分析：        这里先要说明的是，这一篇不是QT系列的文章，而是关于Web的，之所以要写这篇，是因为以前做Web相关开发的时候，经常涉及到与linux底层命令打交道，比如说创建一个目录，删除一个目录，或者是执行一个自定义的脚本。关于PHP如何调用、执行Linux的底层命令，以前也研究过，基本上实现了自己需要的功能，但是有些地方一直没有弄明白。今天又偶然碰到了，趁着这个机会向大家描述一

应用需求：        网盘开发工作逐步进入各部分的整合阶段，当用户在客户端修改或新增加一个文件时，该文件要同步上传到服务器端对应的用户目录下，因此针对数据传输（即：上传、下载）这一块现在既定了三种传输方式，即：Ftp传输、HTTP传输以及基于UDT的传输。且这三种数据传输方式是可配的，可以通过不同的接口调用。相比这三种方式，基于UDT的大量文件传输是比较值得研究与创新的地方，它在底层是基于

应用需求：        由于网盘服务端既需要承载用户文件目录的监控又要负责文件的上传和下载，当某一时刻用户访问量较大或用户操作较为频繁是，单台文件监控服务器和文件传输服务器往往无法满足需求，极端情况下很可能造成服务器内存和CPU使用率爆表的情况，而且当Client与文件监控服务器间网络状况不好的情况下，很有可能造成用户操作序列的丢失，即用户在客户端的操作序列没有及时反映到服务端，造成用户本地

业务需求：         基于网盘客户端的实现，原有网盘的设置面板无论从界面显示还是从业务需求都不能满足我们的正常需求。当前的要求是，模拟QQ系统设置的面板实现当前我们网盘中的基本配置功能。在完成这篇文章时已将基本功能实现完成，虽未整合进网盘客户端中，但基本技术预演已经实现。QQ系统设置面板分析：      QQ系统设置面板效果图：                        

应用需求：        在网盘开发过程中有这样一个需求，即对文件版本进行控制，即记录文件版本的更替信息，这里说的更替信息仅仅是记录不同时刻的文件变化，即文件的增、删、改、重命名等操作。在每个待监控的目录下都会保存一份文件，记录文件变化的增量信息，每次低版本到高版本升级的时候就可以通过消元合并操作快速地进行。关于文件版本控制的具体实现方案会在开发完善后列出，这里仅仅指出它的保存方式，即将文件操

应用需求：        提供皮肤切换选项，在不重启应用程序的情况下实现皮肤的动态切换。理论基础：        1) 图片资源是如何被利用的            这里先简要说明一下实现原理，皮肤的动态切换其关键在于图片资源的加载方式。QT中每个应用程序启动后都会维护属于自己的资源子库，所有的图片以及UI资源都实现编译到rcc文件中，而rcc文件是整合了所有资源的二进制文件，这种

一、需求分析：        随着渲染业务的不断进行，数据传输渐渐成为影响业务时间最大的因素。究其原因就是因为数据传输耗费较长的时间。于是，依托于渲染业务的网盘开发逐渐成为迫切需要解决的需求。该网盘的实现和当前市场上网盘实现有一些的不同，主要在客户端与服务器端的操作需要双向进行，即：用户在客户端的操作需要及时同步到服务器端；在服务器端作业渲染生成的文件要及时同步到客户端。即：用户不在需要单独的

插件式开发体会：        自开始写【大话QT】系列就开始接触渲染客户端的开发，说是开发不如更多的说是维护以及重构，在接手这块的东西之前自己还有点犹豫，因为之前我一直认为客户端嘛，没什么技术含量，总是想做比较有挑战性的，为了这周总还专门找我谈了谈，算是“安抚”民心吧。正式谈话过后，我才决定接手渲染客户端的开发。        渲染客户端的所有构成均是采用开源框架拼凑起来的整体，细分它的

应用需求：        用户在选择渲染作业时面临两种情况：一是选择用户远程存储上的文件；二是选择本地文件系统中的文件进行渲染。由于渲染任务是在远程主机上进行的，实际进行渲染时源文件也是在ftp目录中获取的，因此当用户选择本地文件系统中的文件时，文件必须上传到ftp上的指定目录中，远程主机才能正确获取到文件的路径，下载后进行文件渲染，然后将渲染结果保存在ftp的指定路径下。因此，需求就是当用户

QT中采用QuaZip压缩多个文件为zip文件，且能够通过其它工具正常解压。

QT之前没有接触过，之所以做这个也是被临时拉去GoldenFarm组去做渲染的客户端；还别说，虽说是第一次，做出来的这个东西倒是挺让我满意的。先说一下具体需求，然后再上图吧：        渲染时在选择场景文件时，用户既可以选择网盘（即：服务器上用户的存储目录）中的文件，又可以选择本地文件系统中的文件，而我实现的功能就是后者，也就是要将本地文件系统映射为树结构目录，这里采用动态加载的方式，何谓