精华内容
下载资源
问答
  • 中文乱码一直都是比较让人棘手的问题,我们在使用Jmeter的过程中,也会遇到中文乱码问题,查阅网上的资料解决方案都大同小异,而且不够全面或者不够详细,分享一些jmeter乱码解决方案给大家。添加HTTP请求时在...

    中文乱码一直都是比较让人棘手的问题,我们在使用Jmeter的过程中,也会遇到中文乱码问题,查阅网上的资料解决方案都大同小异,而且不够全面或者不够详细,分享一些jmeter乱码解决方案给大家。

    添加HTTP请求时在Content encoding后填入相应的编码

    接下来我们来看一下这种方式,可以解决哪些乱码问题:

    01get请求中,参数有中文,我们先不填入任何编码,看下结果会是怎样

    我们发现中文没有乱码,经过我的测试get请求时Content encoding中填入任何编码或者不填都没有影响,因为都不会乱码。

    02

    post请求中参数有中文

    第一次我们也先不填写编码:

    我们发现参数出现了乱码,那么接下来我们制定一下编码:

    我们发现不乱码了,那么经过测试此处只要填写时可以显示中文的编码,这个地方就不会乱码,但是我们不要忽略了后台程序的编码,

    如果后台程序使用的编码和你传入的编码不一致,那么会造成后台程序在接收参数时乱码,此处我将参数直接返回回来,这样我们可以直观的看一下效果。

    那么我的后台程序的编码为utf-8,我们分别来看一下设置GBK和utf-8这两种方式的结果,如下图所示:

    03

    对返回结果的影响

    我们请求一下百度,先不填编码:

    我们看一下返回数据,有乱码:

    那我们在填写utf-8编码看一下:

    我们发现还是乱码,经过测试写啥编码返回结果都是乱码,所以我们可以得到结论Content encoding并不能影响返回结果。

    02

    添加BeanShell Sampler或者BeanShell PostProcessor

    这种方式主要解决响应乱码问题的,我们以BeanShell Sampler为例讲解。

    我们先不添加BeanShell Sampler,看看结果如何:

    我们看到现在是乱码,接下来我们添加一下BeanShell Sampler在来看一下,注意要在HTTP请求后面添加:

    在Script处填写如下代码:prev.setDataEncoding("utf-8");

    我们看一下结果:

    我们发现乱码好了!!!

    总结一下这种方法的优点:灵活,随时修改,重点是不需要重启启动Jmeter。

    03

    修改Jmeter的配置文件:jmeter.properties

    这种方式经过我的测试,只是对响应结果有效果。

    找到jmeter安装目录下bin目录下的jmeter.properties文件。

    然后搜索encoding,找到如下这一行代码:

    然后把前面的#去掉,后面的编码修改成utf-8,如下图:

    然后重启Jmeter。

    接下来我们访问一下百度看一下效果,我把BeanShell Sampler禁用。

    我们发现没有乱码。

    我们总结一下这种方式的优点:一次修改,长久使用。

    04

    有的地方说可以通过添加HTTP信息管理器这种方式修改编码

    在HTTP信息头管理器中添加"Content-Type":

    "application/json;charset=utf-8"或者"Content-Type":"application/x-www-form-urlencoded;charset=utf-8"来进行修改编码。

    首先这种方式只能影响请求的参数,但是经过我的测试无论添加哪种都不起作用,在Jmeter中这个地方只能指定你的参数以哪种形式传递,是Json还是KV形式,对于编码没有作用,在这里我就不给大家进行演示了,大家可以自己进行测试。

    05

    最后来一种最牛逼的方式解决你的乱码

    最后来一种最牛逼的方式,如果以上方式都没有解决你的乱码,那么我们只能去修改Jmeter的源码来解决了,因为jmeter源码字符集不是采用的ISO,这里我们就不做介绍了,感兴趣的同学可以自己尝试一下

    其实jmeter使用过程中的乱码基本都可以找到源文件改一下源码中的字符集编码来进行解决。

    展开全文
  • 很快就发现这还远远不够。 当开发人员能够观察到的所有内容都是日志中的一行(其中之一)时,解决该问题几乎没有乐趣: 错误:EOF 错误:值的开头出现意外的'>' 错误:参数值错误 errorx库提供了一种创建工具集...
  • 9 个月前API 都搞不好,还怎么当程序员?如果 API 设计只是后台的活,为什么还需要前端工程师。...因为交付周期的原因,接入了一个第三方的库,遇到了这么一些问题:文档老旧,并且不够全面。这个问题相比于...



    9 个月前

    API 都搞不好,还怎么当程序员?如果 API 设计只是后台的活,为什么还需要前端工程师。

    作为一个程序员,我讨厌那些没有文档的库。我们就好像在操纵一个黑盒一样,预期不了它的正常行为是什么。输入了一个 A,预期返回的是一个 B,结果它什么也没有。有的时候,还抛出了一堆异常,导致你的应用崩溃。

    因为交付周期的原因,接入了一个第三方的库,遇到了这么一些问题:文档老旧,并且不够全面。这个问题相比于没有文档来说,愈加的可怕。我们需要的接口不在文档上,文档上的接口不存在库里,又或者是少了一行关键的代码。

    对于一个库来说,文档是多种多样的:一份 demo、一个入门指南、一个 API 列表,还有一个测试。如果一个 API 有测试,那么它也相当于有一份简单的文档了——如果我们可以看到测试代码的话。而当一个库没有文档的时候,它也不会有测试。

    在前后端分离的项目里,API 也是这样一个烦人的存在。我们就经常遇到各种各样的问题:

    • API 的字段更新了
    • API 的路由更新了
    • API 返回了未预期的值
    • API 返回由于某种原因被删除了
    • 。。。

    API 的维护是一件烦人的事,所以最好能一次设计好 API。可是这是不可能的,API 在其的生命周期里,应该是要不断地演进的。它与精益创业的思想是相似的,当一个 API 不合适现有场景时,应该对这个 API 进行更新,以满足需求。也因此,API 本身是面向变化的,问题是这种变化是双向的、单向的、联动的?还是静默的?

    API 设计是一个非常大的话题,这里我们只讨论:演进、设计及维护。

    前后端分离 API 的演进史

    刚毕业的时候,工作的主要内容是用 Java 写网站后台,业余写写自己喜欢的前端代码。慢慢的,随着各个公司的 Mobile First 战略的实施,项目上的主要语言变成了 JavaScript。项目开始实施了前后端分离,团队也变成了全功能团队,前端、后台、DevOps 变成了每个人需要提高的技能。于是如我们所见,当我们完成一个任务卡的时候,我们需要自己完成后台 API,还要编写相应的前端代码。

    尽管当时的手机浏览器性能,已经有相当大的改善,但是仍然会存在明显的卡顿。因此,我们在设计的时候,尽可能地便将逻辑移到了后台,以减少对于前端带来的压力。可性能问题在今天看来,差异已经没有那么明显了。

    如同我在《RePractise:前端演进史》中所说,前端领域及 Mobile First 的变化,引起了后台及 API 架构的一系列演进。

    最初的时候,我们只有一个网站,没有 REST API。后台直接提供 Model 数据给前端模板,模板处理完后就展示了相关的数据。

    当我们开始需要 API 的时候,我们就会采用最简单、直接的方式,直接在原有的系统里开一个 API 接口出来。

    v2-f46ea440e601673e4f66686eb4147f80_hd.jpg

    为了不破坏现有系统的架构,同时为了更快的上线,直接开出一个接口来得最为直接。我们一直在这样的模式下工作,直到有一天我们就会发现,我们遇到了一些问题:

    • API 消费者:一个接口无法同时满足不同场景的业务。如移动应用,可能与桌面、手机 Web 的需求不一样,导致接口存在差异。
    • API 生产者:对接多个不同的 API 需求,产生了各种各样的问题。

    于是,这时候就需要 BFF(backend for frontend)这种架构。后台可以提供所有的 MODEL 给这一层接口,而 API 消费者则可以按自己的需要去封装。

    v2-2fe6be4af17ec844b9bbfaf31155177d_hd.jpg

    API 消费者可以继续使用 JavaScript 去编写 API 适配器。后台则慢慢的因为需要,拆解成一系列的微服务。

    v2-96c36efdbb41467ab8e73c6aa83f9792_hd.jpg

    系统由内部的类调用,拆解为基于 RESTful API 的调用。后台 API 生产者与前端 API 消费者,已经区分不出谁才是真正的开发者。

    瀑布式开发的 API 设计

    说实话,API 开发这种活就和传统的瀑布开发差不多:未知的前期设计,痛苦的后期集成。好在,每次这种设计的周期都比较短。

    v2-0364ba44cea014a606cd0fc799dfc59a_hd.jpg

    新的业务需求来临时,前端、后台是一起开始工作的。而不是后台在前,又或者前端先完成。他们开始与业务人员沟通,需要在页面上显示哪些内容,需要做哪一些转换及特殊处理。

    然后便配合着去设计相应的 API:请求的 API 路径是哪一个、请求里要有哪些参数、是否需要鉴权处理等等。对于返回结果来说,仍然也需要一系列的定义:返回哪些相应的字段、额外的显示参数、特殊的 header 返回等等。除此,还需要讨论一些异常情况,如用户授权失败,服务端没有返回结果。

    整理出一个相应的文档约定,前端与后台便去编写相应的实现代码。

    最后,再经历痛苦的集成,便算是能完成了工作。

    可是,API 在这个过程中是不断变化的,因此在这个过程中需要的是协作能力。它也能从侧面地反映中,团队的协作水平。

    API 的协作设计

    API 设计应该由前端开发者来驱动的。后台只提供前端想要的数据,而不是反过来的。后台提供数据,前端从中选择需要的内容。

    我们常报怨后台 API 设计得不合理,主要便是因为后台不知道前端需要什么内容。这就好像我们接到了一个需求,而 UX 或者美工给老板见过设计图,但是并没有给我们看。我们能设计出符合需求的界面吗?答案,不用想也知道。

    因此,当我们把 API 的设计交给后台的时候,也就意味着这个 API 将更符合后台的需求。那么它的设计就趋向于对后台更简单的结果,比如后台返回给前端一个 Unix 时间,而前端需要的是一个标准时间。又或者是反过来的,前端需要的是一个 Unix 时间,而后台返回给你的是当地的时间。

    与此同时,按前端人员的假设,我们也会做类似的、『不正确』的 API 设计。

    因此,API 设计这种活动便像是一个博弈。

    使用文档规范 API

    不论是异地,或者是坐一起协作开发,使用 API 文档来确保对接成功,是一个“低成本”、较为通用的选择。在这一点上,使用接口及函数调用,与使用 REST API 来进行通讯,并没有太大的区别。

    先写一个 API 文档,双方一起来维护,文档放在一个公共的地方,方便修改,方便沟通。慢慢的再随着这个过程中的一些变化,如无法提供事先定好的接口、不需要某个值等等,再去修改接口及文档。

    可这个时候因为没有一个可用的 API,因此前端开发人员便需要自己去 Mock 数据,或者搭建一个 Mock Server 来完成后续的工作。

    因此,这个时候就出现了两个问题:

    • 维护 API 文档很痛苦
    • 需要一个同步的 Mock Server

    而在早期,开发人员有同样的问题,于是他们有了 JavaDoc、JSDoc 这样的工具。它可以一个根据代码文件中中注释信息,生成应用程序或库、模块的API文档的工具。

    v2-4f6bfec43bf6e35d43b885cd438e5abd_hd.jpg

    同样的对于 API 来说,也可以采取类似的步骤,如 Swagger。它是基于 YAML语法定义 RESTful API,如:

    swagger: "2.0"
    
    info:
      version: 1.0.0
      title: Simple API
      description: A simple API to learn how to write OpenAPI Specification
    
    schemes:
      - https
    host: simple.api
    basePath: /openapi101
    
    paths: {}
    

    它会自动生成一篇排版优美的API文档,与此同时还能生成一个供前端人员使用的 Mock Server。同时,它还能支持根据 Swagger API Spec 生成客户端和服务端的代码。

    然而,它并不能解决没有人维护文档的问题,并且无法及时地通知另外一方。当前端开发人员修改契约时,后台开发人员无法及时地知道,反之亦然。但是持续集成与自动化测试则可以做到这一点。

    契约测试:基于持续集成与自动化测试

    当我们定好了这个 API 的规范时,这个 API 就可以称为是前后端之间的契约,这种设计方式也可以称为『契约式设计』。(定义来自维基百科

    这种方法要求软件设计者为软件组件定义正式的,精确的并且可验证的接口,这样,为传统的抽象数据类型又增加了先验条件、后验条件和不变式。这种方法的名字里用到的“契约”或者说“契约”是一种比喻,因为它和商业契约的情况有点类似。

    按传统的『瀑布开发模型』来看,这个契约应该由前端人员来创建。因为当后台没有提供 API 的时候,前端人员需要自己去搭建 Mock Server 的。可是,这个 Mock API 的准确性则是由后台来保证的,因此它需要共同去维护。

    与其用文档来规范,不如尝试用持续集成与测试来维护 API,保证协作方都可以及时知道。

    在 2011 年,Martin Folwer 就写了一篇相关的文章:集成契约测试,介绍了相应的测试方式:

    v2-8399e8ee459187d97bb1dc0ff5d2eea6_hd.jpg

    其步骤如下:

    • 编写契约(即 API)。即规定好 API 请求的 URL、请求内容、返回结果、鉴权方式等等。
    • 根据契约编写 Mock Server。可以彩 Moco
    • 编写集成测试将请求发给这个 Mock Server,并验证

    如下是我们项目使用的 Moco 生成的契约,再通过 Moscow 来进行 API 测试。

    [
        {
            "description": "should_response_text_foo",
            "request": {
              "method": "GET",
              "uri": "/property"
            },
            "response": {
                "status": 401,
                "json": {
                    "message": "Full authentication is required to access this resource"
                }
            }
        }
    ]
    

    只需要在相应的测试代码里请求资源,并验证返回结果即可。

    而对于前端来说,则是依赖于 UI 自动化测试。在测试的时候,启动这个 Mock Server,并借助于 Selenium 来访问浏览器相应的地址,模拟用户的行为进行操作,并验证相应的数据是否正确。

    v2-1f4e73adfce320148f8943dadb3441f8_hd.jpg

    当契约发生发动的时候,持续集成便失败了。因此相应的后台测试数据也需要做相应的修改,相应的前端集成测试也需要做相应的修改。因此,这一改动就可以即时地通知各方了。

    前端测试与 API 适配器

    因为前端存在跨域请求的问题,我们就需要使用代理来解决这个问题,如 node-http-proxy,并写上不同环境的配置:

    v2-8f2cf9628b25b436e471eea2aa2a7f22_hd.jpg

    这个代理就像一个适配器一样,为我们匹配不同的环境。

    在前后端分离的应用中,对于表单是要经过前端和后台的双重处理的。同样的,对于前端获取到的数据来说,也应该要经常这样的双重处理。因此,我们就可以简单地在数据处理端做一层适配。

    写前端的代码,我们经常需要写下各种各样的:

    if(response && response.data && response.data.length > 0){}
    

    即使后台向前端保证,一定不会返回 null 的,但是我总想加一个判断。刚开始写 React 组件的时候,发现它自带了一个名为 PropTypes 的类型检测工具,它会对传入的数据进行验证。而诸如 TypeScript 这种强类型的语言也有其类似的机制。

    我们需要处理同的异常数据,不同情况下的返回值等等。因此,我之前尝试开发 DDM 来解决这样的问题,只是轮子没有造完。诸如 Redux 可以管理状态,还应该有个相应的类型检测及 Adapter 工具。

    除此,还有一种情况是使用第三方 API,也需要这样的适配层。很多时候,我们需要的第三方 API 以公告的形式来通知各方,可往往我们不会及时地根据这些变化。

    v2-cc3c675cde9472a0a9abe9771de67fd5_hd.jpg

    一般来说这种工作是后台去做代码的,不得已由前端来实现时,也需要加一层相应的适配层。

    小结

    总之,API 使用的第一原则:不要『相信』前端提供的数据,不要『相信』后台返回的数据。

    转载于:https://www.cnblogs.com/mouseleo/p/8277765.html

    展开全文
  • 出错处理的一些思考

    2018-01-05 00:10:00
    错误(error)和异常(exception)严格来说是不同的,两者的区别,网上不难找到...之所以还要写这方面的帖子,是觉得这些帖子和专著说的还不够全面,有补充的必要。 这个帖子很可能有后续,因为问题太多,一下子讨论不...

    错误(error)和异常(exception)严格来说是不同的,两者的区别,网上不难找到分析的帖子。暂时不想研究这个问题,因此暂不作严格区分,只简单地称之为“出错处理”。

    关于出错或者异常处理,已经有不少帖子和专著讨论了,下次有时间整理一下有代表性的几个,评论一下。

    之所以还要写这方面的帖子,是觉得这些帖子和专著说的还不够全面,有补充的必要。

    这个帖子很可能有后续,因为问题太多,一下子讨论不完。因为是边想边记,很多地方可能会不断修订。欢迎批评指正。

     

    出错处理的目的或者说目标,我想主要是两条:一是为用户提供友好和准确的提示信息,二是为开发者提供调试错误的信息。

    先说第1条。先说“友好”,如果不考虑这点,比如直接在界面上显示exception的堆栈信息,不够友好,另外可能有安全问题,比如暴露了程序文件的名称和位置等(主要是在web应用上)。

    再说“准确”,固然,给用户的提示信息不必包括某些技术细节,比如登陆数据库的用户名等,但是不能误导用户,力求给用户准确的信息。比如,真正的原因是数据库连不上,提示信息只是简单地说程序错误或者打开页面出错,都不是好的做法。

    再说第2条。这个将是重点要讨论的问题。先简要说几点。

    1.一般情况下,不能吞exception。

    这是指以下的做法:

    try

    {

         //做点什么

         ........

    }

    catch 

    {

    }

    也就是说catch块里什么都没有。缺陷是显而易见的,出错信息没有记录下来,也没有显示出来,除非调试源程序,否则无法知道出过错,在哪里出过错。

    但也有例外(好像网上的帖子很少提到这点),例外的情况下,常见的做法是在catch块里加一点注释,说明吞exception的理由。看到过log4net的代码里就有这样的做法。

    常见的理由,现在想到的有

    1).打错误日志的代码出exception(好像log4net里的代码正是这样的情况)

    2).错误不影响大局,不必要处理,而保证应用不崩溃更为重要

     

    2. 一般来说,出错信息越详细越好,特别是要把函数/方法的参数值记录到log里。

    举两个例子。1)出错信息是:某字段转换时出错,数据将被截断

    2) 将xml加载到datatable时出错,提示不合法

    如果没有参数信息,很难找出出错的数据并修正。

    实践中曾碰到一个case,开始打日志时,没有包括参数信息,结果揭示1)的错误,没法修正。后来修改了打日志的代码,包括了出错信息。第二次出同样错的时候,检查一下各个参数的值,两分钟就找到了出错的地方,在数据库里修正数据,马上就好了。

    关于如何记录参数值,以后还会讨论。

     

    3.循环中出错,要小心处理。for/while等循环结构里出错,要小心处理。很多情况下,不能简单地throw excpetion,较好的做法是:记录下出错信息,出错的记录信息(是循环里的哪一条记录出错,参数值如何),然后跳过这条记录,继续执行下一条记录,在全部循环结束时,如果有可能,显示类似“共处理N条记录,其中N条出错”之类的信息给用户。

     

    暂时先写这么多,其余以后边整理边补充。

    转载于:https://www.cnblogs.com/badnumber/p/8196784.html

    展开全文
  • iOS视频压缩处理

    2016-02-24 11:26:00
    最近忙于项目开发, 昨天才完成整个项目的开发, 今天就抽出时间, 分享一下我在开发中... iOS 视频压缩问题, 我在网上也找了资料, 但是不多, 也不够详细全面, 我就自己写了一个压缩的小demo, 用到的是系统的一个类库 ...

        最近忙于项目开发, 昨天才完成整个项目的开发, 今天就抽出时间, 分享一下我在开发中所涉及到的技术问题!

        由于近期开发涉及到视频, 所以视频压缩, 上传, 播放等一系列功能都是要涉及到的, 所以在此, 我就跟大家分享一下视频压缩!

        iOS 视频压缩问题, 我在网上也找了资料, 但是不多, 也不够详细全面, 我就自己写了一个压缩的小demo, 用到的是系统的一个类库

       #import <AVFoundation/AVFoundation.h> 中 AVAssetExportSession 这个类, 官方API 是这样解释说明的, AVAssetExportSession 是对AVAsset对象内容进行转码, 并输出到制定的路径;

    - (nullable instancetype)initWithAsset:(AVAsset *)asset presetName:(NSString *)presetName NS_DESIGNATED_INITIALIZER; 初始化方法

       asset, 参数为要转码的asset 对象,  presetName, 该参数为要进行转码的方式名称, 为字符串类型, 系统有给定的类型值, 

     

    AVAssetExportPresetLowQuality

    AVAssetExportPresetMediumQuality

    VAssetExportPresetHighestQuality 

    AVAssetExportPreset640x480

    AVAssetExportPreset1280x720

    outputURL , 为输出内容的URL, (指定一个文件路径, 然后根据路径初始化一个URL, 赋给, outputURL)

    outputFileType, 为输出压缩后视频内容的格式类型

    Demo 下载地址

    https://github.com/jessonliu/JFUpLoadVideo.git
    http://code.cocoachina.com/view/131886

    下边直接上代码, 如有错误, 或有不好的地方, 欢迎大家指正, 本人虚心学习求教, 与大家共勉!

     

    //  Created by iOS-Developer on 16/2/19.
    //  Copyright © 2016年 iOS-Jessonliu. All rights reserved.
    //
    
    #import "JFCompressionVideo.h"
    #import <AVFoundation/AVFoundation.h>
    
    
    #define CompressionVideoPaht [NSHomeDirectory() stringByAppendingFormat:@"/Documents/CompressionVideoField"]
    
    @interface JFCompressionVideo ()
    @end
    
    @implementation JFCompressionVideo
    
    + (void)compressedVideoOtherMethodWithURL:(NSURL *)url compressionType:(NSString *)compressionType compressionResultPath:(CompressionSuccessBlock)resultPathBlock {
        
        NSString *resultPath;
        
        NSData *data = [NSData dataWithContentsOfURL:url];
        
        CGFloat totalSize = (float)data.length / 1024 / 1024;
        
        AVURLAsset *avAsset = [AVURLAsset URLAssetWithURL:url options:nil];
        
        NSArray *compatiblePresets = [AVAssetExportSession exportPresetsCompatibleWithAsset:avAsset];
    
        // 所支持的压缩格式中是否有 所选的压缩格式
        if ([compatiblePresets containsObject:compressionType]) {
            
            AVAssetExportSession *exportSession = [[AVAssetExportSession alloc] initWithAsset:avAsset presetName:compressionType];
            
            NSDateFormatter *formater = [[NSDateFormatter alloc] init];// 用时间, 给文件重新命名, 防止视频存储覆盖,
            
            [formater setDateFormat:@"yyyy-MM-dd-HH:mm:ss"];
            
            NSFileManager *manager = [NSFileManager defaultManager];
            
            BOOL isExists = [manager fileExistsAtPath:CompressionVideoPaht];
            
            if (!isExists) {
                
                [manager createDirectoryAtPath:CompressionVideoPaht withIntermediateDirectories:YES attributes:nil error:nil];
            }
    
            resultPath = [CompressionVideoPaht stringByAppendingPathComponent:[NSString stringWithFormat:@"outputJFVideo-%@.mov", [formater stringFromDate:[NSDate date]]]];
            
            JFLog(@"resultPath = %@",resultPath);
            
            exportSession.outputURL = [NSURL fileURLWithPath:resultPath];
            
            exportSession.outputFileType = AVFileTypeMPEG4;
            
            exportSession.shouldOptimizeForNetworkUse = YES;
            
            [exportSession exportAsynchronouslyWithCompletionHandler:^(void)
             
             {
                 if (exportSession.status == AVAssetExportSessionStatusCompleted) {
                     
                     NSData *data = [NSData dataWithContentsOfFile:resultPath];
                     
                     float memorySize = (float)data.length / 1024 / 1024;
                     JFLog(@"视频压缩后大小 %f", memorySize);
                     
                     resultPathBlock (resultPath, memorySize);
                     
                 } else {
                     
                     JFLog(@"压缩失败");
                 }
                 
             }];
            
        } else {
            JFLog(@"不支持 %@ 格式的压缩", compressionType);
        }
    }


    /**

    *  清楚沙盒文件中, 压缩后的视频所有, 在使用过压缩文件后, 不进行再次使用时, 可调用该方法, 进行删除 

     */

    + (void)removeCompressedVideoFromDocuments {
        NSFileManager *manager = [NSFileManager defaultManager];
        if ([manager fileExistsAtPath:CompressionVideoPaht]) {
            [[NSFileManager defaultManager] removeItemAtPath:CompressionVideoPaht error:nil];
        }
    }
    @end

     

    转载于:https://www.cnblogs.com/Unclefeng/p/5212342.html

    展开全文
  • 图像处理--数据增强

    2020-08-25 09:27:12
    在机器学习训练过程中,经常会遇到数据量不足(即样本不够全面)从而导致训练出来的的模型泛华性能差的问题。此时通过人为的对数据进行扩充来生成更多种类(更加符合实际情况)的数据的技术就是数据增强。 数据增强...
  • 全面不够高效的解法 全面又高效的解法 测试用例代码 本题考点 题目 实现函数 double Power( double base, int exponent ),求base 的 exponent 次方。不得使用库函数,同时不需要考虑大数问题。本题要求实现类似...
  • 问题回复:20180715

    2018-07-13 08:27:17
     我现在正学习调制解调,购买并正在拜读您Altera版三本和锁相环技术这一整套著作,收获很大,FPGA数字信号处理方面刚开始接触,相关知识掌握不够深入和全面,目前在学习BPSK解调后位同步中遇到这么一个问题:...
  • 主要是网络上找的清理的东西不够全面,导致没有什么用处。 下面我将MySQL整体清理干净的步骤列下。 1.首先我们需要关闭服务(没有这步的可以略过)  首先我们进入开始-运行-输入cmd,然后在弹出dos下,输入...
  • 一直以来jsp中的乱码问题困扰着我,有些人的回答我总是那么一点点,不够全面。在网上找了这篇文章,感觉帮助蛮大的,讲了乱码产生的原因、讲了具体各种解决乱码的方法。 一、中文问题的来源 计算机最初的操作...
  • 最近做数据质量一直在跟各种“率”打交道,数据分析的结果往往都是类似“0.1234”的小数,但是页面需要展现的却是百分率,刚刚接触AS,就想自己写个小函数来理顺思路顺便解决问题。 小数转化百分数的逻辑并不复杂,...
  • CSS跟JavaScript开发中,最令大家头疼的问题就是浏览器兼容性了,虽然很多文章有这方面的文章,但依然让很多开发人员晕头转向,而且也不够全面。这篇文章,将全面收集css在各种浏览器下的兼容性报告,以及浏览器的...
  • 对SAP中的业务理解不够全面。比如,笔者遇到的如题目中所描述的案例分析如下: 生产成本收集器是在成品级别建立,与成品物料产生联系。其实际应用是在成品上建立一个订单容器。用于收集成品生产入库时产生的成本。...
  • 在博客园里有这篇帖子讲的已经很全面了,但是我认为还不够优雅,整个看起来好混乱,像国外这位老兄的帖子处理的就很整洁,简单记录如下: 通常的国际化处理方法 public class User { [Required...
  • 很多内容可能不够全面、不够准确、有特殊的限制条件,甚至是错误的。但我觉得这是正常的, 我不传道,不授业,不解惑,只希望能有个契机交流、请教、学习。 从输入、处理、输出的角度来看,如果我输出的结论是错误的...
  • oracle学习文档 笔记 全面 深刻 详细 通俗易懂 doc word格式 清晰 第一章 Oracle入门 一、 数据库概述 数据库(Database)是按照数据结构来组织、存储和管理数据的仓库,它产生于距今五十年前。简单来说是本身可视...
  • 虽然直接写调用Controller方法的测试用例不难,但问题在于这些测试用例不够全面。 例如,仅通过直接的方法调用我们测不到 Controller 的映射、校验和异常处理。 SpringMVC 提供给我们通过 DispathServlet 调用 ...
  • 这是一个 Pandas 快速破冰课程,主要教学对象是数据分析新手以及对 Pandas 掌握不够全面的人。 几乎所有数据分析/挖掘工程师,都需要掌握 Pandas。数据分析的过程中,第一个面临的问题就是数据处理。而 Pandas,是 ...
  •  反思工作中的不足之处范文1 1、对于领导交办的任务,办事心切,处事不够干练,想问题不够全面,不够深刻,虽然能基本完成上级交办的任务,但在工作中面对困难面对压力也感到力不从心,缺乏工作动力; 2、有时处理...
  •  (二)存在的问题 考虑问题不够全面处理问题不够果敢,为人处世过于耿直,社交能力明显缺乏。学科素养亟待提升,钻研精神时而懈怠,内向口拙不善沟通,执行能力略显不足。 二、个人三年发展规划 (一)我的...
  • 护士自查报告范文.doc

    2021-01-15 22:09:48
     一、存在问题原因分析 1、是学习的积极性不强,求知欲望不高,对专科知识学习不够深入,没有完全用理论知识武装自己的头脑,从而导致处理问题不够熟练,给病人解释不够全面。 2、是以工作忙为理由,当病人询问时...
  •  一、存在问题原因分析 1是学习的积极性不强,求知*不高,对专科知识学习不够深入,没有完全用理论知识武装自己的头脑,从而导致处理问题不够熟练,给病人解释不够全面。 2是以工作忙为理由,当病人询问时,继续...
  • 通过培训学习,自己明白到有这样的情况是因为自己了解的知识仍不够全面,还有觉悟不够深,自己也不懂的排空及放下毫无用处的知识所致,未掌握到较好的学习方法。 其次,自己在解决问题时主管能动性不够强,会有这样...
  • 通过培训学习,自己明白到有这样的情况是因为自己了解的知识仍不够全面,还有觉悟不够深,自己也不懂的排空及放下毫无用处的知识所致,未掌握到较好的学习方法。 其次,自己在解决问题时主管能动性不够强,会有这样...
  • 企业培训心得报告.doc

    2021-01-15 19:39:47
    通过培训学习,自己明白到有这样的情况是因为自己了解的知识仍不够全面,还有觉悟不够深,自己也不懂的排空及放下毫无用处的知识所致,未掌握到较好的学习方法。 其次,自己在解决问题时主管能动性不够强,会有这样...
  • 通过培训学习,自己明白到有这样的情况是因为自己了解的知识仍不够全面,还有觉悟不够深,自己也不懂的排空及放下毫无用处的知识所致,未掌握到较好的学习方法。 其次,自己在解决问题时主管能动性不够强,会有这样...

空空如也

空空如也

1 2 3 4 5 ... 13
收藏数 244
精华内容 97
关键字:

处理问题不够全面