软件过程

网速正常但是下载速度很慢什么原因啊?

匿名 (未验证) 提交于 2019-12-02 23:47:01
一、网络最小宽带 这应该是造成网速很快下载很慢的最主要的原因。这个原因也就是人们经常说的宽带不够,如果宽带比较高的话下载速度自然就快了起来,如果宽带比较低的话下载速度当然不会快。网速很快并不意味着宽带很高,因此如果宽带低的话下载速度也就变慢了就许多。   二、DNS解析速度 DNS是一个较为专业化的名词,通俗的来说,这就是域名到IP的一个过程,这个过程的速度是需要被解析的。从一台机器的工作转换到另一台机器的过程当中,机器与机器之间只认识IP,因而这个解析也需要花费一定的时间。在两台机器之间往复的进行解析以及每次解析的时间综合就是耗费的总时间。从网络上下载东西的时候,需要您的电脑与下载端的机器之间进行工作转化,这个过程是需要时间的,如果解析的过程比较复杂,则需要花费更多的时间,因此下载速度变慢了。 三、服务器软件 在下载东西的时候,有一个服务器端在运行工作,如果这个服务器端运行的软件数量比较多得话,分给下载的网络速度自然就变少了,这也就导致下载速度变慢。而如果在服务器端安装了一个防火墙软件,那它更会阻止网络的下载速度,使下载速度变慢。 四、下载软件的选择 如果您是使用浏览器自带的下载软件进行下载的话,其速度比起专业软件的下载速度就会慢许多。如果您使用迅雷这类下载软件,并且搭配上会员的话,软件自身有个下载加速的过程,这时候下载速率就提高了。(南昌壹基比)

Linux graphic_DRI介绍

匿名 (未验证) 提交于 2019-12-02 21:59:42
http://www.wowotech.net/linux_kenrel/dri_overview.html 1. 前言 上篇文章( Linux graphic subsytem(1)_概述 )介绍了linux图形子系统基本的软件框架,以及GUI、Windowing system、3D渲染等基本概念。文中提到了linux DRI(Direct Render Infrastructure)框架,但限于篇幅,没有过多介绍。 蜗蜗觉得,DRI在当前(或者说将来)的linux图形子系统中,有着举足轻重的地位,甚至可以说是新的linux图形框架核心思想的体现。本文将基于linux图形框架的发展历程,从Why、What和How三个角度,介绍DRI框架。 在GUI环境中,一个Application想要将自身的UI界面呈现给用户,需要2个步骤: 1)根据实际情况,将UI绘制出来,以一定的格式,保存在buffer中。该过程就是常说的“Rendering”。 不知道为什么,wowo一直觉得“Render”这个英文单词太专业、太抽象了,理解起来有些困难。时间久了,也就不再执著了,看到它时,就想象一下内存中的图像数据(RGB或YUV格式),Rendering就是生成它们的过程。 通常来说,Rendering有多种表现形式,但可归结为如下几类: a)2D的点、线、面等绘图,例如,“通过一个for循环

【软考】【软件设计师】【知识模块】【第2章:程序设计语言基础知识】

旧时模样 提交于 2019-12-02 17:04:01
程序设计语言基础知识 2.1 程序设计语言概述   2.1.1 程序设计语言基本概念     低级语言,面向机器的语言,如汇编语言、机器语言;       特性:进行程序设计效率低,程序的可读性差,难以修改、维护,优势是运行速度特别快;     高级语言,面向各类应用的程序设计语言。如C、C++ 、Java、Python、Delphi 、Pascal、Php          语言处理程序:负责将高级语言翻译成计算机能理解的0和1的程序;     语言之间的翻译基本方式:       汇编、解释、编译;       汇编:对使用汇编语言写成的源程序进行翻译成目标程序(机器可直接执行)的过程;       解释:将源程序翻译成中间代码(需要配合专有解释器才可执行)的过程;       编译:将源程序翻译成机器可直接执行的目标程序的过程;                解释和编译的区别在于:       对源程序进行编译后的目标程序可以在机器上直接执行,不需要源程序和编译程序配合执行;机器上运行的是与源程序等价的目标程序。       对源程序进行解释后的中间代码,需要源程序和解释程序(解释器)配合执行;            程序语言的定义涉及的三个范畴:       语义、语法、语用;     所谓高级语言,即不依赖机器硬件的;     所谓通用的程序设计语言

软件理论基础-

浪尽此生 提交于 2019-12-02 16:07:28
一. 概念 软件:实现用户需求的源代码,及与之匹配的文档和支撑其运行的配置数据,是一种逻辑存在的资产(数据结构+算法+文档+服务) 软件测试:以用户的需求为基准,运用科学的测试方法对被测对象进行检测,找出偏离需求的需求实现 软件测试:为了尽早尽快的发现软件产品中所存在的各种软件缺陷而进行的贯穿整个软件开发生命周期对软件产品进行验证和确认的活动过程 调试:对软件程序代码对出一系列的检查和纠正的过程,以保证软件能正常运行为目的 软件测试的目的:是为了发现错误而执行错误的过程,此外,不仅发现错误,而且还有易用性等测试,这些统称为缺陷 二. 人们对软件测试目的的认知过程 证明(表明软件能够运行)-->纠错(发现错误)--> 预防(预防管理) 三. 测试执行 单元测试执行 集成测试执行 系统测试执行 四. 测试和调试的区别 测试的目的是发现错误,对象为文档和代码,有待定的流程有计划性,从已知条件开始,有预定义过程,我预定结果 调试的目的是定位问题,纠错,对象为代码,无特定流程,无计划,无已知条件和预定结果 五. 回归测试的目的 1.验证修复的缺陷或者新的的功能是否正确 2.验证对代码的修改是否引入了新的错误 六. 软件测试的主要工作 1.查视代码,评审开发文档 2.进行测试设计,写测试文档(测试计划,测试方案,测试用例等) 3.执行测试,发现软件缺陷,提交缺陷报告,并确认缺陷得到了解决 4

速读《构建之法(第三版)》总结

半腔热情 提交于 2019-12-02 13:35:12
速读《构建之法(第三版)》总结 花了两天的时间,终于是把这本《构建之法》粗略的阅读完毕,我在阅读的过程对于感兴趣的部分进行了仔细阅读,其中也碰到了一些问题。但我认为领悟这本书所传达的思想及思维方式是非常重要的,在此提出自己阅读时所收获的一些问题,不对的地方还望大家及时指正。 问题一 在软件的开发过程中,即便我们有了一定的软件开发能力后,为什么我们还要必须具备软件工程的工程思维? 从以下几个主要方面进行简单分析 软件开发的变化 追溯到计算机刚起步的时候,软件设计只是为了个特定的应用而在指定的计算机上设计和编制,当时的语言使用还是机器代码或汇编语言,软件的规模也比较小,很少使用系统化的开发方法,软件设计几乎就是在个人编程。随着现在计算机整个行业的发展,软件的增多,高级语言的出现等,软件的规模越来越大,复杂程度也越来越高,软件的可靠性问题突显出来。在这个软件开发越发成熟的今天,从软件的立项到最后软件的发出,中间的开发过程慢慢的形成了各式各样固定的体系,当软件开发还处于幼年时期时,产品大多遵循[分析→设计→实现(制造)→销售→维护],弊端是具有单向、不可逆性。后来,Winston Royce提出了具有相邻回溯的“瀑布模型”以及改进后的最终版本,后续又出现了很多“瀑布模型”的变形版。 图1.1 相邻回溯 图1.2 最终版 软件开发的模型有很多种,不同的软件可能适合不同的开发模型。

DDD领域驱动设计基本理论知识总结

南楼画角 提交于 2019-12-02 11:22:59
原文地址: https://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html 领域驱动设计之领域模型 加一个导航,关于如何设计聚合的详细思考,见 这篇 文章。 2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software (领域驱动设计),简称Evans DDD。领域驱动设计分为两个阶段: 以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具,在交流的过程中发现领域概念,然后将这些概念设计成一个领域模型; 由领域模型驱动软件设计,用代码来实现该领域模型; 由此可见,领域驱动设计的核心是建立正确的领域模型。 为什么建立一个领域模型是重要的 领域驱动设计告诉我们,在通过软件实现一个业务系统时,建立一个领域模型是非常重要和必要的,因为领域模型具有以下特点: 领域模型是对具有某个边界的领域的一个抽象,反映了领域内用户业务需求的本质;领域模型是有边界的,只反应了我们在领域内所关注的部分; 领域模型只反映业务,和任何技术实现无关;领域模型不仅能反映领域中的一些实体概念,如货物,书本,应聘记录,地址,等;还能反映领域中的一些过程概念,如资金转账,等; 领域模型确保了我们的软件的业务逻辑都在一个模型中

软件测试面试过程中,被问到 “你会搭建测试环境吗” 要怎么回答?

萝らか妹 提交于 2019-12-02 08:24:00
● ○ ● 你会搭建测试环境吗?● ○ ● 导语:很多人在面试软件测试的过程中,经常被问到“你会搭建测试环境吗”?面对这样的提问,你知道怎么回答么? ● ○ ● 如何回答● ○ ● 面试的时候,遇到这样的提问,很多人的都会感觉脑子一下一片空白,或者星星点点,不知道从何说起。一方面不知道面试官问这个问题的意图是什么?也不知道他想得到的答案是什么?更加不知道该从哪些方面来回答。作为一个测试行业从业8年有余的测试人员,我想跟大家分享一些我的经验和看法。 首先,毋庸置疑的是,面试官问这个问题,想要得到的是你肯定的答案,希望你是一个会搭建测试环境的优秀测试工程师。QA不管是做什么类型的测试,最基础的功能测试,需要搭建测试环境;进阶部分的性能压力测试,对搭建环境的要求更高。所以搭建测试环境是优秀测试工程师的必备技能之一,也是QA开展测试工作的前置条件。当然有些公司可能会有运维或者研发部门帮忙准备好测试环境,但是QA如果一味依赖别的部门,就会大大的局限测试工作的开展,如果别的部门没有时间或者进度滞后,会直接影响到测试工作的进度和效率;而且测试环境如果不是QA负责维护的,后期扩展业务需要优化测试环境的时候,或者遇到问题要调试的时候,都需要依赖其他部门,会导致测试工作不独立,也会显得测试工作人员不专业。 ● ○ ● 需掌握的知识● ○ ● 了解了QA具备搭建测试环境能力的重要性

面向对软件架构风格

情到浓时终转凉″ 提交于 2019-12-02 05:55:07
软件架构风格: (1)数据流风格:批处理序列;管道-过滤器。 (2)调用/返回风格:主程序/子程序;面向对象风格;层次结构。 (3)独立构件风格:进程通信;事件系统。 (4)虚拟机风格:解释器;基于规则的系统。 (5)仓库风格:数据库系统;超文本系统;黑板系统。 数据流风格-批处理序列: 批处理风格的每一步处理都是独立的,并且每一步是顺序执行的。只有当前一步处理完,后一步处理才能开始。数据传输在步与步之间作为一个整体。(组件唯一系列固定顺序的计算单元,组件只通过数据传递交互。每个处理步骤是一个独立的程序,每一步必须前一步结束才能开始,数据必须是完整的,以整体的方式传递)批处理的典型应用:(1)经典数据处理(2)程序开发(3)Windows下的BAT程序 数据流风格-管道和过滤器 在管道/过滤器的软件架构中,每个构件都有一组输入和输出,构件读输入的数据流,经过内部处理,然后产生输出数据流。这个过程通常对输入流的变换及增量计算来完成,所以在输入被完全消费之前,输出便产生了。这里的构件成为过滤器,这种风格的连接件就像是数据流传输的管道,讲一个过滤器的输出传到另一个过滤器的输入。此风格特别重要的过滤器必须是独立的实体,他不能与其他的过滤器共享数据,而且一个过滤器不知道它上游和下游的标识。一个管道/过滤器网络输出的正确性并不依赖于过滤器进行增量计算过程的顺序。 一个典型的管道

如何用天纵快速开发平台快速开发办公系统

喜你入骨 提交于 2019-12-02 02:08:34
谈到开发软件,很多人的第一感觉就是这是一个高技术的活,不懂程序的话肯定连想都不敢去想。其实随着各种创新开发工具的出现,软件开发不再是只有软件工程师才能做的活了,没有学过编程的人完全可以在短时间快速开发软件。不懂编程的我用实践证明了这一说法。 去年年底,公司领导让我负责搭建一家公司的内部办公和核心业务系统。这家公司不大,不可能去买几万几十万的现成系统,即便是买了现成的系统,他们也怕日后如果要调整系统或增加一点功能,只能求原软件开发商定制开发,那更是天价了。再说现成的系统也不适合他们小公司的实际情况,他们对软件功能要求其实很简单,务实够用就行,没用的复杂的东西不要,只想解决公司核心业务功能。 他们在网上搜索一些解决方案,看到不少公司有他们同样的苦恼,且也有这方面的解决方法了,那就是用一种叫做免编程的配置型快速开发平台。这种快速开发工具可以解决企业在不懂编程但懂业务的情况下开发真正符合公司实情的管理系统。而且,这种开发平台可以在日后公司业务或管理发生变化时随时调整功能模块,也可以根据按需增加其他模块。经过公司内部相关人员的讨论,他们达成了共识,决定采购这种快速开发平台进行开发。经过十几天的询价和评估,他们选择了我们天纵新智能开发平台,并外包给我们定制开发。 接到公司交给我的开发任务,我很快制定出软件开发计划和日程表。这是我多年养成的习惯,做事之前必须要有计划,这样才可以确保项目按时完成。

项目管理经验

冷暖自知 提交于 2019-12-02 00:41:23
如果你与软件行业有若干联系,但是还不知道Joel这个人以及他的博客,那么赶快拿起百度,然后尽可能多的了解他和他的思想,对你肯定有好处。这篇是他博客中的经典之作,收录在他的两本书中:《Joel on Software》和《Smart & Gets Things Done》,这两本书主要收录和整理了他的博客中的经典文章,有必要一看。 要翻译出原作者的味道真的很难,所以我们经常骂一些翻译过来的中文书籍太烂,特别是由那些不懂技术的人翻译的技术书籍。所以如果你是是程序开发人员,再次善意的提醒您:“学好英文”,这句话被很多人重复,也不多我一个了,当然听不听由你。 你有没有听说过 SEMA ?这是一个非常复杂的软件开发团队评价体系。等等!千万别去研究它!仅仅是理解它就将花掉你六年时间。所以我自己搞了一套软件开发团队评价体系,信不信由你,这套体系最大的优点就是只需三分钟就可掌握!你可以把省下的时间去读医学院了。 Joel 的12条测试问题 你们用了源代码管理软件吗? 你们是否一步就能实现从源代码到可发布的产品? 你们每天都把源代码管理系统的代码做一次生成操作吗? 你们有软件Bug管理系统吗? 你们在编写新代码前解决bug吗? 你们有没有一个时常更新的进度计划? 我的这套体系非常简洁,你只需对每个问题回答“是”或者“否”就可以了,你不需要去算什么每天写的代码行数或者平均bug数等等,回答“是