文档管理

什么是技术视野 网上看到不少关于如何提升技术视野的讨论，但却没有人给出定义，到底什么是技术视野？ 所谓技术视野，就是看问题时所能切换的不同角（维）度。 下面就以API管理工具（以下简称“管理工具”）为例，来探讨背后隐藏的技术视野。 API管理工具 零视角 曾经在一个小型创业公司用到过最简单的管理工具，就是一个开源的文档管理工具，界面功能类似wiki（维基百科）。 这样的工具确实能满足核心需求——API在线文档化，并支持用户管理。 可是深想一层，对于管理工具的使用者——工程师，操作足够友好，功能足够完善吗？ 使用这类管理工具很多时候都会出现文档与代码不一致的情况，也就是说工程师都不愿意去维护这个文档。 因为编写修改文档是个耗费时间的事情，短期来看， 维护了既无利益，不维护也无危害~ 所以有时候接口的变更通过口头协商而非文档协商。 小结：零视角其实谈不上视野，是大多数工程师的最容易形成的思维方式，特点就是只关注功能/问题本身。 单一视角 当时为了解决上面的问题，同时为了练手所学的Node.js，我写了第一版的管理工具，并参加了线下沙龙分享。 现在看来其实当初的写的项目还是比较粗糙的，除了展示界面相较于wiki更加美观之外，主要加入了 Mock 功能。 更好的开源项目也有不少，比如阿里的 RAP 和国外的 APIDOC 。 之所以把它们归为一类讨论，那是因为它们都体现了开发者的单一视角。

简介 MongoDB是一款为广泛的现代应用程序设计的高性能、可扩展、分布式数据库系统。MongoDB可用于不同规模大小的组织，为那些对系统低延迟、高吞吐量以及可持续性有很高要求的应用提供稳定关键的服务。 尽管MongoDB与传统的关系型数据库的有些特性不一样，但是对于之前部署和操作其他数据库系统的人员来说，MongoDB的很多概念，比如操作、策略、存储过程还是很相似的。公司的DBA和运营团队可以在保持现有系统的前提下，直接把MongoDB集成到生产环境中，并且不需要定制操作流程和工具 本文档为部署和管理MongoDB提供了最佳实践的指导。看本文档的前提需要你熟悉MongoDB的基本架构并理解企业软件部署的相关知识。 关于文档中的涉及到有些话题的更多详情，可以访问MongoDB的在线文档：mongodb.com。本文档也提供了相应的链接。 角色和职责 与其他数据库系统一样，部署在MongoDB的应用需要精心规划以及公司IT团队每个角色的协力合作才能保证稳定的部署。传统数据库中相关的角色以及角色的定位同样适用于MongoDB：数据库管理员、系统管理员、应用开发人员、网络管理员、需求分析人员以及数据架构师。 一般小公司中一个人员可能会担当多个角色，而大公司中，每个角色都是由一个人或者一个团队专门负责的。比如，在大的投资银行中，DBA的职责和系统管理员的职责差别就很大。 DBA

activePDF DocConverter WBE是一款功能强大的PDF转换控件，提供了强健的COM和.NET API，可以很轻松地添加文件转换功能到你的应用程序中，支持转换通用的文件格式为PDF或这是转换PDF文件为常用的文件格式。 具体功能： 转换Microsoft Office文档格式为PDF和PDF/A： 转换Microsoft Word®, Excel® 和PowerPoint文档为PDF，转换Word headings、元数据、超链文档管理接等元素为等同的PDF元素 转换PDF为多种文件格式： 支持转换PDF为Microsoft Word® 文档, Microsoft Excel® spreadsheet, HTML文档, text文件, 图像文件(one per page), PDF/A 完全的输出PDF并且设置PDF元数据： 控件提供了新的属性和方法用于设置文档元数据，如标题和作者，应用40-128位加密到输出的PDF文件 PDF/A校验： 控件使你能够创文档管理建和校验PDF/A文档，当验证文档时，一个XML日志文件产生，描述结果。帮你确认你的文档完全兼容PDF/A标准 文档管理文档管理 原文来自 http://www.fanganwang.com/product/2958 来源： oschina 链接： https://my.oschina.net/u

文档管理的一些心得（原文地址： http://www.douban.com/note/225998761/ ） 在项目工作中，往往会产生大量的文档，有收集的数据，也有展示所用的报表，还有记录事项和结论等各式各样的文档。当这些文档数量很庞大，且同一个文档，或因内容更新，或因来自于不同的发送者等缘故而产生了大量不同的版本。我们在面对一大堆未分类文档一筹莫展，需要某个急需文档始终无法找到时，深感项目工作中对文档进行科学细致管理的重要性和迫切性。 根据项目管理原理，以及平时工作中总结的经验，对文档管理的方法进行了整理，提出了几点方案： 一、根据项目管理中将项目分为多个子项目，分别进行执行的原则，将项目按照内容或者进度的不同分成若干子项目，每个子项目设置一个存放文档的文件夹，用以归档该子项目所属的文档文件。将项目中产生的文档必须按照项目下的子项目分别建文档进行归置，项目下面的文档只能用来放置项目级的文档，如工作进度报告，联系人清单，已经成型或暂时有效的方案、规范等非临时性的文件；将具体工作中的文档按照所属不同的子项目文件夹进行归档存放。 二、在每一个子项目文件夹中应当设置“接收文档”文件夹，保存从外部获得的文档。所有从外部获取的文件，必须按照固定的格式重新编著文件名：标注编号、原文档名称、接收时间、发送人、版本号、状态号(非必须)。例如：001.[数据汇总表]_20120528_Mary

重要的不是你拥有什么，而是你如何去看 起因 假如需要写一个Web项目的详细设计，说明前后端各接口的作用以及实现策略，那么很有可能是这么一个结构： 注意图中有背景色的部分是前端人员所关心的，而类似“相关类”和“具体实现策略”等内容则是服务器端开发人员的职责范围，当然其中也有“传递参数”、“补充及注意事项”等栏目是双方都需要给予一定的关注的。 那么，当这样一份文档拿到前端人员的手中，面对着其上成百上千行的“具体实现策略”，茫茫字海之中无法寻找到自己需要的接口的URL地址，会是一种什么样的悲剧呢？ 为了解决这个问题，可能有下面几种解决方案： 不管死活所有人看一份文档，请自己高亮你需要看到的内容。很显然这么做对于广大的开发人员都是一种痛苦的折磨。 将文档一分为二，分为前端人员版本和服务器端开发人员版本。但是两个文档又存在通用的部分，使用复制/粘贴必然为将来的版本维护带来麻烦。 每个部分有明确的标题，使用文档地图，阅读者通过文档地图来定位到需要的部分。这是一个比较通用的解决方案，但只能有若干级的结构，对于文字中某些注释等无法进行支持。 本次的主题：多视角文档模型，就是为了解决上文提到的问题而诞生的。 概念 再次回顾上文提到的问题，事实上需要的一个解决方案应当有以下的特征： 文档自始至终只有一份且不能拆分。 不同角色人员看到的内容不同。 因此，多视角文档模型就是一种

Aspose.Cells for .NET （点击下载） 是Excel电子表格编程API，可加快电子表格管理和处理任务，同时支持构建具有生成，修改，转换，呈现和打印电子表格功能的跨平台应用程序。 在挑选产品的过程中，能否实现自己所需的功能是第一影响因素。在Excel管理工具Aspose.Cells for .NET中，可以实现非常多的功能需求，那么，究竟有没有你所需要的功能呢？ Aspose.Cells for .NET的功能大致可分为： 文件格式管理和转换 、 渲染和打印 、 表格操作功能和格式设置 、 PageSetup功能 。 ▲文件格式和转换 Microsoft Excel工作簿（XLS）： 最快，最完整的XLS格式实现 SpreadsheetML（XLSX，XML）： Aspose.Cells支持OOXML，Flat OPC以及Excel 2003 XML。此外，该组件支持所有主要的Excel 2007、2010和2013文件格式，例如XLSX，XLTX，XLSM，XLTM等。 逗号分隔值（CSV）： 全面支持CSV格式以与各种应用程序进行交互。 TSV： 以TSV文件格式加载和保存文档。 HTML： 可保存为HTML格式。 OpenDocument（ODS）： Aspose.Cells可以以OpenDocument Spreadsheet（.ods）格式加载和保存文档。