白及88
TA的个人档案
个人介绍
白及
擅长的技术
- 高分内容
- 最新动态
- 文章
- 问答
-
发表了文章 2016-05-16
项目经理 架构师的区别
项目经理和架构师的岗位职责 项目经理和架构师这两个职位虽然在工作内容和职责上不同，但是在国内的企业中这两个职位的职责经常会放在一个人身上，在中小型公司中更是如此，一个人既是项目经理又是系统结构的设计者。在比较正式的企业中，也会存在同一个在这两个职位间相互转化的情况，例如从架构师转为项目经理。自己对这两块比较感兴趣，希望能够在这两个职位间自如切换。因而在“猎聘网”找了对这两个职位的说明，摘录如下，作为自己学习和提高的目标。 项目经理 1. 负责项目进度管理、质量控制、人员管理、风险管理，领导项目团队准时、优质实现项目目标； 2. 负责协调用户业务需求，制定具体的项目功能细节，负责软件系统需求的调研和分析，即时反馈阶段性成果；与客户保持联系，并按照客户的合理需求改进； 3. 按照项目要求对业务进行整理和流程设计，按照软件功能要求进行详细设计； 4. 制定项目开发计划文档，量化并分配任务；跟踪项目进度，协调组员合作； 5. 监督项目进展各阶段的文档，如《项目章程》、《项目立项报告》、《需求确认》、《实施计划》、《验收报告》等项目文档的编写，确保文档完整规范； 6. 判断客户需求变更的合理性，同时与组员及客户沟通协调；确认变更时，产生需求变更文档，更改开发计划； 7. 向上级汇报项目的进展情况、需求变更等项目信息； 8. 总结已完成项目，产生项目总结文档； 9. 传递知识，提升团队能力。 架构师 1. 熟悉分布式、高性能架构和开发技术，如分布式应用开发、数据分布式管理和同步等； 2. 精通J2EE系统架构，深刻理解J2EE架构的优缺点，具有大型基于J2EE体系结构的项目规划、系统架构设计、开发经验，精通j2ee设计模式； 3. 深刻理解软件系统架构，精通面向对象分析设计方法，逻辑能力佳，具有丰富的OOA、OOD、OOP、UML及SOA经验，精通RationalRose、PowerDesigner等设计工具； 4. 技术视野广阔，具有良好的前瞻性，思路清晰、逻辑性强，对移动支付和互联网支付的相关技术具有优秀的领悟力和前瞻性，有较强的业务分析能力； 5. 良好的沟通能力、团队合作精神和服务意识；认真负责、具有高度责任感和敬业精神； 6. 对于性能瓶颈可以给出最优的切片,集群和分布式服务器搭建解决方案 7. 理解面向对象分析和设计的基本原则，熟悉常用的设计模式，熟悉ＵＭＬ； 8. 熟悉Java的多线程，线程与线程，进程与进程的通信机制； 9. 精通系统优化，对系统优化原理有深入的理解。对系统端到端性能优化有丰富的实践经验，熟悉各种远程本地Cache组件(尤其是Memcached,Redis)，对Cache服务器集群架构有丰富的经验； IT架构师是根据需求分析人员跟客户沟通后，拿回的客户需求，将面向客户的需求文档变成面向开发人员的开发文档，同时要从功能实现和编程实现的角度出发来做系统的总体规划。架构师的工作完成后，下一步就是开发团队沟通，然后每个开发人员各自依照开发文档负责一个或多个部分的开发工作。而项目经理则是整个项目从头到尾的管理者，监督者，他的任务是随时保持和客户、和团队成员的沟通。对团队成员的工作进行监督和审核，以确保整个项目按时、按质、按量完成。包括处理项目实现过程中的一些特殊情况。在需求分析阶段。简单点理解，以盖房子为例，架构师是建筑设计师，而项目经理就是工头或者说监工。一个管结构，一个管进度。
-
发表了文章 2016-05-15
数据库设计
一、需求分析 二、数据库设计 1．powerdesigner使用方法介绍 2．E-R图设计入门 3．CDM生成PDM 三、脚本生成 1．PDM生成脚本 2．脚本导入 3．建立数据库所需要注意的问题 四、录入数据 1．Navicat for MySQL——导入execl表； 2．PL/SQL——直接复制进去（投机取巧哇哈哈） 五、连接数据库（thinkphp版） 1．Mysql连接方式 2．Oracle连接方式 六、其他tips 第一部分——需求分析； 一些小组的同学在做数据库分析之前没有做细致的需求分析，直接开始做数据库设计，其实我认为这样子是事倍功半的，虽然此次使用不包括前端设计和后台代码，但事先做需求分析仍然可以给你带来以下好处： 1. 电商作为一个我们不太了解的领域，事先做需求分析可以帮助我们了解电子商务的运作过程，使得数据库设计更加合理。 2. 需求分析可以帮助我们理清思路，在分析过程中，我们逐渐了解到这个系统需要什么样的实体集，而每个实体集里又需要包含什么样属性，需求分析做得越细致，系统设计的效率就越高。 3. 需求分析可以将你所需要做的项目清楚地表达出来，方便你向其他大神寻求知道意见。 程序猿通常使用UML做设计，但我们小组经过讨论后觉得思维导图（XMind）也是一个不错的选择，且效率要比UML高，上手也容易，所以果断选择XMind； 下面提供XMind下载连接： http://pan.baidu.com/s/1hqkQzRY 右键一直子主题就可以建立一科树状图： 我们建立的图如下： 在做完需求分析之后，大体框架已经出来 这里只是 理清楚，功能，还没有E-R实体图出来。
-
发表了文章 2016-05-13
系统架构：
博主转载的几篇文章都不错。 我下来会好好组织实施。 系统架构： http://blog.csdn.net/dinglang_2009/article/details/6863697 http://blog.csdn.net/dinglang_2009/article/details/6863707 http://blog.csdn.net/dinglang_2009/article/details/6863697 http://blog.csdn.net/dinglang_2009/article/details/6863701
-
发表了文章 2016-05-13
怎样挖掘用户需求
需求分析在数据库生命周期中至关重要，通常也是涉及人员最多的步骤。数据库设计师在这个阶段必须走访最终用户，与他们进行访谈，从而确定用户想在系 统中存储什么数据以及想怎样使用这些数据。 我们将需求分析分为两个步骤：1.理解用户需求；2.提取业务规则。这次我们先讨论“理解用户需求”。 设计定制化产品——无论是一个数据库、一幅平面广告或一个玩具，都是一个“翻译”的过程。我们需要把浮现在客户脑海中的模糊想法、愿望挖掘出来，并“翻译”成满足他们需求的现实产品。 这个“翻译”过程的第一步就是理解用户的需求。设计最好的订单处理系统对于需要一个电路设计工具的客户来说毫无意义。对客户需求理解的不完全会造成错误或无用的设计与开发，这浪费了你、你的团队还有客户的时间与金钱。(牢记数据库是整个应用开发的根基) 制定一个计划 我们首先制定了一个计划，其中包含挖掘客户需求的一系列步骤。遵循这些步骤能更好地理解客户需求，但在一些项目中我们不需要遵循所有的步骤。举例来 说，如果客户是单个人且需求很明确时，我们就不需要进行“搞清谁是谁”与“头脑风暴”了。当客户的数据需要保密时，我们就不能“尝试客户的工作”了。在另 一些项目中，调整这些步骤的顺序会更为合适。例如我们可能在去拜访客户和观察他们工作之前先进行“头脑风暴”。 以下按照最普遍的顺序列出了各个步骤。大家根据不同项目的情况可进行灵活调整，目标只有一个就是更好地理解用户需求。 列出问题清单 拜访客户 搞清谁是谁 挖掘客户大脑 尝试客户的工作 学习现有操作 头脑风暴 展望未来 理解客户的质疑 弄清客户的真正需求 优先级 确认你的理解 撰写需求文档 下面我们将一一解释每一个步骤。 我们需要思考，向客户问些什么问题可以帮助我们了解项目的目标和范畴（scope）。以下几个方面的问题可以作为起始点。 功能： 以下问题主要涉及系统应完成的功能与目标。 系统应该做些什么? 为什么你想建这个系统? 系统看上去应该是怎样的? 需要些什么报表? 用户需要自己定义新报表吗? 系统的操作者会是谁? 数据需求： 这些问题是为了弄清项目的数据需求。了解需要些什么数据能帮助我们定义数据库表。 系统界面上需要展现哪些数据? 这些数据应该由谁来提供? 这些数据是如何关联的? 这些工作现在是如何处理的?数据来自哪里? 数据完整性： 这些问题能帮助我们在构建数据库时定义完整性约束。 哪些数据是必须填写的?(eg: 一条客户记录必须有电话信息吗?) 数据的有效域是什么?(eg: 电话号码是否有格式规定?地址数据应有多长?) 系统是否需要根据邮编来检验城市的有效性? 系统中是否必须在定义了客户之后才能下订单? 系统要求多高的可用性等级?(系统需要7×24的可用性吗?数据的备份频率要多高?) 安全性： 这些问题能帮助我们了解客户对权限控制与审计方面的需求。 是否每个用户都需要一个不同的密码? 是否需要控制不同的用户所能访问的数据?(eg: 销售代表有权限看到客户的信用卡账号，但订单录入专员却不能) 存储在数据库中的数据是否需要加密? 谁做了什么操作是否需要记录以便于审计?(eg: 记录销售代表提高客户级别的操作，在需要时可以追溯操作的原因) 系统中的客户分成几个级别?每个级别的客户有多少? 是否已有文档记录了用户的工作与权责? 环境： 这些问题能帮助我们了解当前项目将代替其他什么系统或流程，以及项目将与其他哪些系统进行交互。 1.当前项目是要代替或升级现有的某系统吗? •是否有描述现有系统的文档? •现有系统的哪些功能是需要的?哪些是不需要的? •现有系统处理些什么数据?这些数据是如何存储的?数据之间是如何关联的? •是否有关于现有系统数据的文档? 2.当前项目必须与其他哪些系统交互? •项目与其他系统之间如何交互? •新项目是否需要向现有系统提供数据?如何提供? •新项目是否需要接收现有系统的数据?如何接收? •是否有关于其他系统的文档? 3.客户的整个业务流程是怎样的?(了解在整个业务流程中当前项目的作用) 拜访客户 了解我们要设计和搭建的系统的最好方式是询问客户。拿着我们在上一步中准备的问题清单安排与客户进行会面。这不会像闲聊那么轻松，向客户了解需求是一个冗长且折磨人的过程。 有时我们的穷追猛问会使客户筋疲力竭感到不快。在这些时候我们必须更为耐心，可以分几次多次会议来了解需求，每次针对几个问题或流程。我们的目标是对我们要解决的问题有一个完全且彻底的理解。 即使我们的项目只是去解决整个业务中的一小部分问题，我们也要试图去了解客户的整体业务流程，这可能会给我们带来意想不到的收获。 搞清谁是谁 意识到不同的客户可能对项目有不同的愿景。我们需要分辨出谁是领导，谁是积极支持者，谁是旁观者，谁是唱反调者。 以下列出了一些常见的客户角色： 项目发起人——一般是管理层的某位领导，他是项目的最高推动者。他会为项目协调资源，解决项目遇到的一些障碍，但他不会参与到项目每天的事务中。 项目执行负责人——他对于客户的需求和整个业务最为了解。他是了解用户需求阶段最重要的人，他必须有足够的时间来帮助我们定义项目目标以及回答我们的问题。当别人对某业务环节迟疑不决时，我们需要向他请教。 客户代表——客户代表是回答我们问题的人，他们也可能成为系统的最终用户。他们可能是某一部分业务的专家，我们需要与多个客户代表进行访谈来了解业务全貌。 利益相关者——这是项目将影响到的人，其中某些人可能同时也是客户代表。这些人可能对项目也有兴趣，但未必对系统都有发言权。我们在进行系统设计时也需要考虑对这些人的影响(特别是附带损害)。 唱反调者——这是我们需要关注的一些人。如果唱反调者只是让其他人理性或现实地来看待项目，而并不是彻底反对这个项目的话，他将是我们非 常好的资源，他将帮助我们说服其他对项目抱有不切实幻想的客户。而如果唱反调者对整个项目抱有抵触时，我们就必须非常小心，有时需要项目执行负责人出面来 协调这些人。 挖掘客户大脑 一旦搞清楚谁是谁之后，我们就要与项目执行负责人讨论客户需要什么。客户希望的解决方案是怎样的，需要包含什么数据，怎样呈现，以及不同数据之间如何关联。 与尽可能多的利益相关者进行交流，我们需要考虑每个人的意见，但心中要牢记项目执行负责人最为理解客户的需求并具有最终决定权。 根据项目的规模，这一过程短则几个小时，长则需要几周才能完成。 尝试客户的工作 观察客户每日的工作能帮助我们更好的理解业务。如果我们能做一会儿客户的工作来了解其中包括的内容那就最好了。 即使我们不能实际尝试客户的工作，一般我们还是可以坐在他们身边近距离观察。告诉客户我们将稍稍降低他们的工作效率并问一些愚蠢且恼人的问题，之后 我们就可以开问了。在这个过程中要进行记录，学习尽可能多的东西。有些时候外行者的一些看法可能转化为客户怎么也不会想到的好主意。 学习现有操作 在尝试客户的工作之后，我们还可以看一下是否有其他途径能了解现有流程。通常公司有描述客户角色和职责的操作手册或文档。 寻找客户现在使用的数据存储方式，可能是关系型数据库系统或是电子表格或是纸质的单据等等。了解这些数据是怎样使用的，之间是如何关联的。一般物理数据库之间是通过包含冗余信息来相互关联的，如：客户ID。 头脑风暴 此刻我们已经对客户的业务和需求较为了解了。为了确认没有什么遗漏，我们需要安排头脑风暴。召集项目执行负责人和尽可能多的客户代表与利益相关者，向他们描述前期了解到的需求情况，之后让他们畅所欲言谈谈其中有什么问题或还缺什么。 在这个过程中我们不急于答应或排除任何客户的要求，我们先把客户说到的东西记录下来，并确定这些方面我们已经考虑到了。在正式开发前，我们会与项目执行负责人一起根据项目的规模与交付期限确定需求的优先级。 展望未来 在头脑风暴过程中思考一下将来的需求。问问客户他们的业务在将来是否会变化或他们希望系统将来能包含什么功能。 我们可以把他们的一些想法放入当前的项目中，即使不能也可以使我们知道将来可能会有些什么扩展，在设计数据库时我们能预先留有余地。 理解客户的质疑 一些热心且懂些技术的用户会跑来建议我们如何设计系统，应该创建怎样结构的数据表。我们可能觉得这些建议毫无意义甚至可笑。但在忽视这些建议之前我 们应谨慎思考用户提出这些建议或质疑的深层原因是什么。客户比我们更了解业务，他们的建议或质疑中可能蕴含着我们还未了解到的业务变化点或某些特殊业务情 况。 弄清客户的真正需求 有时客户并不了解自己的真正需求。他们能看到问题的表象，但未必清楚其根源。我们需要帮助客户寻找到问题的根源并针对问题的源头提出解决方案。 有时客户认为数据库或新系统能神奇般的提高销售，减少成本。事实上一个设计精良的数据库能减少输入差错，提高操作效率，提供数据报表，帮助客户管理数据等等。我们在与客户沟通的过程中需要告诉他们新系统能做些什么，不能做些什么，让客户建立起正确的预期。 优先级 经过先前的步骤，我们已列出一张长长的期望功能列表。其中的某些功能可能不切实际或超出了当前项目的范畴。为了使项目规模可控，我们要与客户一起定义功能的优先级。 一般我们可以把功能分为三个等级。第一优先级是在本期开发中必须包含的功能，没有完成这些功能意味着项目的失败。第二优先级是可以放到下一期开发的 功能，当第一优先级的功能完成后，我们可以把第二优先级的部分功能提到当期开发。第三优先级是那些相对不重要或超出项目范畴的功能，我们可以忽略这些功 能。 有些情况下优先级是可能转化的。当第一优先级的某功能非常难实现时，我们可以与客户进行沟通，确认该功能是否如此重要，是否能移到第二优先级中以避 免影响项目进度。当第二优先级中的某些功能很容易实现，我们可以把该功能调整到第一优先级列表中。但做这些调整之前必须与客户沟通，得到客户的认可。 验证你的理解 梳理我们对业务和需求的理解，并一一与客户进行确认。当客户说“但是”、“除了”、“有时”等词时，我们要特别当心，确认客户只是强调了我们已经知道的东西，而没有出现新的情况。在这个阶段客户可能会想到他们之前没有考虑到的例外情况。 例外情况是数据库设计的大害。在需求分析阶段把例外情况挖掘出来，我们才能在数据库设计时有所准备。例如，我们向客户确认退货流程说：“到这里收货 员会输入RMA号并点击完成按钮是吗?”客户可能会说：“嗯…这是大多数情况，但有时没有RMA号，收货员会填入None。”这就是一个客户之前没有告诉 我们的重要例外情况，我们必须立刻记录下来。再有一个例子，假设客户使用的纸质订单有配送地址与账单地址两个栏目。我们向客户确认时说：“订单需要有一个 配送地址和一个账单地址。”客户打断说：“有时我们需要两个配送地址，因为订单不同部分可能要送到不同的地方。”，并找出一张订单，第二个配送地址被标注 在订单的边沿处。这是一个重大例外，在纸上可以很容易的进行标注，但在数据库的一个表单元中增加一个地址是不可能的。只有知道这一例外，我们才能用设计的 方法解决这一需求。 撰写需求文档 需求文档描述了我们要构建的系统，该文档也被称为需求规格说明。需求文档要讲清楚我们将构建怎样的系统，该系统会完成什么工作，包含哪些功能点，并描述客户如何使用该系统来解决他们的问题。需求文档明确了项目将完成的功能，这也避免了系统交付时出现争执的情况。 需求文档中应定义可交付成果，即里程碑。里程碑是可直观展现并能验证的中间成果。客户通过里程碑能衡量项目的进度。在需求文档中还需定义最终交付成果，这也是确定项目是否完成的标准。 用例图是一种非常好的需求分析工具，可以作为需求文档的一部分。用例图的最主要功能就是用来表达系统的功能性需求或行为。用例图从业务角度上体现谁 来使用系统、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，也便于软件开发人员最终实现这些功能。在官方文档中用例图包含六个元素，分别 是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系 (Generalization)。但是有些UML的绘图工具多提供了一种直接关联关系(Directed Association)。 参与者：是指用户在系统中扮演的角色 用例：是指外部可见的系统功能，对系统提供的服务进行描述 关联关系：连接参与者和用例，表示该参与者代表的外部系统实体与该用例描述的系统需求有关 包含关系：是来自于用例的抽象，即从数个不同的Use Case中，分离出公共的部分，而成为可以复用的用例 扩展关系：表示某一个用例的对话流程中，可能会根据条件临时插入另外一个用例，而前者称为基础用例后者称为扩展用例 泛化关系：一个用例可以被特别列举为一个或多个用例，这被称为用例泛化 eg：用户管理的用例图如下所示，图中人形图标表示参与者，椭圆表示用例（图的出处请参见“总结与参考”） 主要内容回顾 1. 搞清哪个客户扮演哪个角色 2. 从客户的脑海中挖掘信息 3. 寻找关于用户角色、职责、现有流程和现有数据的文档 4. 观察客户的工作，学习他们的业务操作 5. 进行头脑风暴，把收集到的功能需求点按优先级分成第一、第二和第三级 6. 确认对客户需求的理解 7. 撰写需求文档，包含可验证的里程碑和用例 参考： http://blog.sina.com.cn/s/blog_77500e110100wy47.html
-
发表了文章 2016-05-13
CASE 工具有哪些
CASE 工具 CASE工具设置的软件应用程序。这使用为自动的SDLC活动。 CASE工具所使用的软件项目经理，分析师和工程师开发的软件系统. 有许多CASE工具做软件开发生命周期的各个阶段，如工具，设计工具，项目管理工具，数据库管理工具，文档工具分析. 为了得到所需的结果，CASE工具加速项目工作的发展并帮助推动软件开发的下一个阶段. CASE工具组件 于特定的SDLC阶段，CASE工具可以分为以下: 中央存储库 - CASE工具需要一个中央存储库，它可以作为通用的，集成的，一致的信息来源。中央存储库是存放在哪里的产品规格，需求文档，相关的报告和图表，对管理的其他有用的信息都存储在一个中心位置。中央储存库也可以作为数据字典. 大写工具 - 大写工具在SDLC的规划，分析和设计阶段使用. 小写工具 - 小写工具的实施，测试和维护使用. 集成的CASE工具 - 集成的CASE工具在SDLC的各个阶段的帮助，从需求收集到的测试和文档. CASE工具可以组合在一起，如果他们有类似的功能，流程活动，并得到整合其他工具的能力. CASE工具的适用范围 CASE工具的范围，进入整个软件开发生命周期. CASE工具类型 现在，我们简要地通过不同的CASE工具 图工具 这些工具被用来表示在图形形式的系统组件，数据和其中的各种软件组件的控制流程和体系结构。例如，流程图制作工具，用于创建流程图. 流程建模工具 过程建模方法来创建软件过程模型，该模型被用来开发软件。流程建模工具，帮助管理者选择的过程模型或修改它，因为每个软件产品的需求。例如，EPF作曲. 项目管理工具 这些工具用于项目计划，成本和工作量估计，项目调度和资源规划。经理人必须严格遵守项目执行与软件项目管理的每提及一步。项目管理工具可以帮助存储和整个组织共享项目信息的实时性. 例如, Creative Pro Office, Trac Project, Basecamp. 文档工具 在软件项目文档启动软件过程之前，整个云SDLC的各个阶段和项目建成后. 文档生成工具为技术用户和最终用户的文档。技术的用户大多是开发团队的内部专业人士谁是指系统手册，参考手册，培训手册，安装手册等最终用户文档描述的功能和操作方法系统，例如用户手册。例如, Doxygen, DrExplain, Adobe RoboHelp for documentation. 分析工具 这些工具可帮助收集需求，自动检查是否有任何不一致，不准确的图表，数据冗余或错误遗漏。例如, Accept 360, Accompa, CaseComplete for requirement analysis, Visible Analyst for total analysis. 设计工具 这些工具可帮助软件设计人员设计的软件，其可以进一步在使用细化技术更小的模块被分解的块结构。这些工具提供了详细的每个模块和互连模块之间的. 如，动画软件设计 配置管理工具 软件的实例下一个版本发布。配置管理工具处理 – 版本和修订管理 基线配置管理 变更控制管理 CASE工具在这有助于通过自动跟踪，版本管理和发布管理。例如, Fossil, Git, Accu REV. 变更控制工具 这些工具被认为是配置管理工具的一部分。他们处理的软件进行更改后，其基准是固定的，或者当软件首次发布。 CASE工具自动更改跟踪，文件管理，代码管理等。这也有助于在执行组织的政策变化. 编程工具 这些工具包括编程环境，如IDE（集成开发环境），内置的模块库和仿真工具。这些工具提供全面的援助建设的软件产品，其中包括功能仿真和测试. 例如, Cscope to search code in C, Eclipse. 原型开发工具 软件原型仿真版的预定软件产品。原型提供初始的外观和产品的手感和模拟实际产品的几个方面. 原型CASE工具基本上都与图形库。他们可以创建独立于硬件的用户界面设计。这些工具可以帮助我们根据现有的信息来建立快速原型。此外，他们提供的仿真软件原型。例如.Serenaprototype composer, Mockup Builder. Web开发工具 这些工具可协助设计网页的形式一样，文本，脚本，图形等所有盟国的元素。网络工具还提供了对正在开发的实时预览，以及如何将它看起来完成后。例如, Fontello, Adobe Edge Inspect, Foundation 3, Brackets. 质量保证工具 质量保证的软件组织监控工程过程和方法，通过开发软件产品，以确保质量的一致性按组织的标准。 QA工具，包括配置和变更控制工具和软件测试工具。例如, SoapTest, AppsWatch, JMeter. 维护工具 软件的维护包括软件产品的修改就交付了。自动记录和错误报告技术，误差自动售票生成和根本原因分析的几个CASE工具，可帮助软件组织在SDLC的维护阶段。例如, Bugzilla for defect tracking, HP Quality Center. 参考： http://www.tutorialspoint.com/ch/software_engineering/index.htm
滑动查看更多
暂无更多信息
-
发表了文章
2016-02-17
11GR2 RAC modify vip,public 修改VIP步骤
-
发表了文章
2016-02-17
基于Linux下 Oracle 备份策略(RMAN)
-
发表了文章
2016-02-17
mysql主从环境搭建
-
发表了文章
2016-02-17
kill killall pkill 杀死php后台进程
-
发表了文章
2016-02-18
0.0.0.0 详解
-
发表了文章
2016-02-18
Linux 命令大全-网络资源
-
发表了文章
2016-02-18
Ip地址子网划分网站
-
发表了文章
2016-02-18
内外网同时上网
-
发表了文章
2016-02-18
内外网同时使用
-
发表了文章
2016-02-18
网络路由基础认识
-
发表了文章
2016-02-18
win7入网测试
-
发表了文章
2016-02-18
内外网同时访问以及拓扑图
-
发表了文章
2016-02-18
双网卡同时上网
-
发表了文章
2016-02-18
configure: error: *** libmcrypt was not found 错误解决
-
发表了文章
2016-02-18
编译安装php时候的参数说明
-
发表了文章
2016-02-18
VMWare 网络连接模式(bridged、NAT、host-only)详解
-
发表了文章
2016-02-18
linux设置固定ip
-
发表了文章
2016-02-18
linux memcached状态查询
-
发表了文章
2016-02-18
查看mysql数据库的版本方法
-
发表了文章
2016-02-18
top命令详解
滑动查看更多
暂无更多信息