未找到

未发布 LoadRunner中脚本回放问题及解决方法(下)
by zoujiajun33 keys 分享 1488791780548
在运行脚本回放过程中,有时会出现错误,这在实际测试中是不可避免的,毕竟自动录制生成的脚本难免会有问题,需要运行脚本进行验证,把问题都解决后才加入到场景中进行负载测试。本次接着给大家分享LoadRunner中脚本回放问题及解决方法下半篇。
JavaScript中怪异的地方
by 1518409521 keys JS学习 JavaScript 1408807630369

—经历语言奇怪特性的旅程

在这篇文章中我想总结一下我们在1月YYCJS聚会讨论的一些事情。这都是关于JavaScript的怪异的部分。你可以在Youtube上找到这个视频, 在yycjs.com/the-weird-parts 找到一些幻灯片,在 JSBin 找到在线编码的部分。

进入我们所谈论的内容。我们可以使用(点)或[](方括号)操作符访问对象和对象属性,点操作符只接受有效的JavaScript变量名而方括号可以采用任何字符串:

未发布 百度正式开源其RPC框架brpc
by Harriet666 keys 分享 1506650334597
9月14日,百度正式在GitHub上基于Apache 2.0协议开源了其RPC框架brpc。brpc是一个基于protobuf接口的RPC框架,在百度内部称为“baidu-rpc”,它囊括了百度内部所有RPC协议,并支持多种第三方协议,从目前的性能测试数据来看,brpc的性能领跑于其他同类RPC产品。
 
brpc开发于2014年,主要使用的语言是C++和Java,是百度内部使用最为广泛的RPC框架,它经受了高并发高负载的生产环境验证,并支撑了百度内部大约75万个同时在线的实例。据了解,百度内部曾有多款RPC框架,甚至在2014年时还开源过另外一款RPC框架sofa-pbrpc。那brpc是在什么样的背景下诞生的?它有什么样的优势?又为何要开源?就这些问题,InfoQ记者采访了brpc负责人戈君。
 
Q:谈谈brpc的一些基本情况?什么时候开始研发的?经过了怎么样的迭代和升级?目前在内部应用情况如何?

戈君:brpc于2014年创建,在百度内部称为“baidu-rpc”。到目前为止,brpc一共进行了3000次左右的改动,现在仍在持续优化中,百度内的wiki上可以查询到每次改动的描述。brpc的主要语言是C++和Java,对其他语言的支持主要是通过包装C++版本,比如brpc的Python版包含C++版的大部分功能。
 
brpc目前支撑百度内部大约75万个同时在线的实例(不含client),超过500种服务(去年的统计,现在已不统计这类数据)。Hadoop、Table、Mola(另一种广泛使用的存储)、高性能计算、模型训练、大量的在线检索服务都使用了brpc。brpc第一次统一了百度内分布式系统和业务线的通信框架。
 
Q:为什么百度当时要研发brpc?

戈君:我们在实践中意识到,RPC作为最基础的通信组件,当时的百度已经不领先了。我当时的经理刘炀曾是Google的工程师,非常重视基础架构的建设,也愿意在这个方向投入资源。
 
我们在内部会更加深入地讨论这些问题。“好用”有时看起来很主观,但其实还是有据可循的,它的关键点是能不能真正地提高用户的效率:开发、调试、维护都要考虑到,如果用户效率真的被提高了,用户会想着你的,靠吹嘘或政令推广的东西得不了人心。我们创建brpc的初衷是解决百度业务所面临的实际挑战,同时也希望成为百度同学最喜爱的工具,哪怕离开百度也会怀念brpc。我们希望在提供了一个好用框架的同时,也展现了一种工作方法:注释怎么写,日志怎么打,ChangeLog怎么写,版本怎么发布,文档怎么组织,甚至对未来不在百度的同学的工作也有帮助,所以从这点来说brpc从一开始就是拥抱开源的。事实上,我们在口碑上做得还不错,brpc的wiki可能是百度内被点赞最多的内容之一。
 
Q:与其他的一些开源的RPC框架相比,brpc的优势是什么?

戈君:brpc主打的是深度和易用性。一方面我们没有精力像gRPC那样摊大饼,什么都做。另一方面我们也注意到gRPC(包括更早的Thrift)的深度和易用性并不够。技术方面的东西就是这样,看示例程序,文档非常牛逼,但实战中可能就是另一回事了,为什么各个公司都要造自己的轮子,一个隐藏原因就是表面高大上的东西在一些细节上让你无法忍受。

RPC真正的痛点是什么?是可靠性、易用性和定位问题的便利性。服务中不要出现不可解释的长尾,程序的可变项要尽量少,各种诡异问题要有工具支持快速排查。而这些在目前开源的RPC框架中做的并不好,它们大多看着很牛,但就是无法在自己组织中推广开来。回到前面那三点,brpc是如何做的呢?
  • 可靠性。这一方面是代码质量问题,通过为brpc团队设立很高的招聘门槛,以及在团队中深入的技术讨论,我们确保了稳固的代码基础。另一个问题是长尾问题,这是设计问题,brpc其实包含了很多模块,其中的bthread是一个M:N线程库,就是为了更好地提高并发避免阻塞。brpc中的读和写都是wait-free的,这是最高程度的并发。技术细节请点击链接查看。
  • 易用性。有种设计是什么选择都做成选项丢给用户,号称功能都有,但一旦出问题,则是用户“配置错了”。而且这样用户还非常依赖开发团队,没有开发团队的支持基本用不了,开发团队有足够的理由扩充团队。这么做其实非常不负责任,用户面对海量的选项也很难受。brpc对于增加选项非常谨慎,框架能自己做判断的绝不扔给用户,所有用户选项都有最合理的默认值,不设也能用。我们认为这对用户体验来说非常重要。
  • 定位问题的便利性。这点其它开源框架目前做的都不好,正常使用是可以的,但出问题就麻烦了。这个问题在百度内部其实也很严重,brpc之前用户排查问题都要拉RPC同学一起排查,RPC框架对用户是个黑盒,用户根本不知道里面发生了什么。按我们的经验,基本每天都有几个用户在群里问server卡顿,client超时之类的问题,排查问题是常态,人手必然不够。时间长了用户就觉得你这个框架各种问题,人还拽的不行很少回他们消息。brpc的解决办法是给server内加入各种HTTP接口的内置服务,通过这些服务,用户可以很快看到server的延时、错误、连接、跟踪某个RPC、CPU热点、内存分配、锁竞争等信息,用户还可以使用bvar来自定义各类统计信息,并在百度的运维平台NOAH上汇总。这样大部分问题用户可以自助解决。其实我们去看也是看这些,只是会更加专业。内置服务的具体说明可以看这里。
 
Q:作为公司内部的RPC框架,在服务治理方面有什么考虑?

戈君:百度内部RPC使用非常广泛,基本都是RPC调用,一些产品线还会通过local RPC隔离工程框架和策略代码。这么多年下来,服务周边的系统也比较全面了:编译是BCLOUD,发布是Agile,服务注册和发现是BNS,认证是Giano,监控和运维是NOAH。在百度内部,brpc和这些系统做了比较紧密的绑定,用户体验是一站式的。虽然在开源版本中,这些结合大都删掉了,但用户可以根据自己组织中的基础设施来进行定制:交互协议,名字服务,负载均衡算法都可以定制。对于其中一些特别通用的,我们希望用户反馈到开源版本中来以方便所有人。
 
Q:之前百度还开源过sofa-pbrpc,brpc与它的区别是什么?

戈君:sofa-pbrpc也是百度开发的一个比较早期的RPC框架,属于sofa编程框架的一部分,在搜索有应用。brpc相比sofa-pbrpc有如下优点:
  • 对协议的抽象更一般化,并统一了全百度的通信架构。bprc能容纳非常多的协议,基于Protobuf的,基于HTTP的,百度内的nshead/mcpack,开源的Redis/Memcached,甚至RTMP/FLV/HLS直播协议,brpc能逐渐地嵌入现有系统,而不需要彻底重构,但sofa-pbrpc则不具备扩展协议的能力。类似的,sofa-pbrpc也无法定制负载均衡算法,brpc默认提供round-robin、随机、一致性哈希,Locality-aware(局部性感知)四种算法,用户还能定制。
  • 多线程质量更好。多线程编程是非常困难的,看起来简单的RPC遍布多线程陷阱,比如处理超时的代码可能在RPC还没发出去时就运行了;发送函数还没结束,处理回复的回调就被运行了;一个回复还在被处理另一个回复回来了,诸如此类。另外,一个异步RPC的回调里发起一个同步RPC会发生什么,带着锁做同步RPC会发生什么。这些问题我们都不能在sofa-pbrpc中找到满意的答案。
  • 完备的调试和运维支持。解决这个问题的本质还在可扩展性,你如何让用户参与进来定制他们感兴趣的指标,为此我们设计了bvar,让用户能用比原子变量代价还小的方式自由地定制各种指标,用户能在浏览器上看到指标的变化曲线,或在运维平台NOAH看到汇总的监控数据。brpc还加入了大量内置服务方便用户调试程序,查看连接,在线修改gflags,追踪RPC,分析CPU热点,内存分配,锁竞争等一应俱全。
无需讳言,brpc在诞生之初和sofa-pbrpc在百度内部是有竞争关系的,但就像其他地方一样,这种竞争带来了活力。类似的,brpc和其他已经开源的RPC框架也是良性的竞争关系,在比拼谁能真正提高用户效率的过程中共同进步。每个用户都可以去对比代码、文档质量,接口设计,易用程度,扩展能力等,投出自己的一票。
 
Q:谈谈brpc的整体架构?

戈君:技术栈无外乎是从传输层垒到应用层,就略过不讲了,具体可以去看下开源出来的文档。brpc在架构上强调“在不牺牲易用性的前提下增强可扩展性”,比如brpc支持非常多的协议,在百度内部一个brpc server同端口可以支持二十几种协议,这对于服务的平滑迁移就非常好用。

Client端的协议也非常多,用户用brpc和bthread用得很爽,所以希望我们最好能统一所有的客户端,像对Redis和Memcached的客户端支持也是在这个背景下做的,这两个客户端比官方Client好用多了,感兴趣的读者可以去尝试一下。但这么多协议的配置非常简单,填个字符串就行了,比如HTTP就是把ChannelOptions.protocol设为“http”,Redis就是“redis”。Server端甚至不用设,它会自动判断每个client的协议,怎么做到的开源文档里也有。

名字服务、负载均衡也都可以定制。但为了对用户负责,我们也不鼓励“太自由”的定制,比如一点点需求的变化就要搞个新的,这时更需要想清楚本质区别是什么。这个事情我们在百度内的支持群里每天都在做,我们是开放的”乙方”,但我们也是严厉的”乙方”。
 
Q:brpc的性能如何?这么高的性能是怎么做到的?

戈君:性能是我们非常看中的一点,它和用户体验也是紧密联系的。好用但性能不行,或不好用但性能很牛,用户会很难受,我们不希望用户纠结。从另一个角度来看,在推广初期,我们要说服产品线用brpc靠什么?最直观的就是性能提升。而且这儿的性能不能停留在benchmark的图片上,而是能在真实应用中体现出来。开放出来的案例文档中或多或少都包含了性能提升,具体如下:
  • 百度地图API入口
  • 联盟DSP
  • ELF学习框架
  • 云平台代理服务
 
Q:为什么要将brpc开源?接下来在开源项目的迭代方面有什么计划吗?

戈君:因为马上还有不少依赖RPC的百度系统要开源啊。RPC作为最基础的组件,开源不仅仅是为了自身,也是为其它开源项目铺路,比如说我们马上还会开源基于brpc的RAFT库,搭建高可用分布式系统非常方便;以及使用brpc的bigflow,让流式计算变得很顺手。这些年百度对开源的认识也在不断加深,开源看似曝光了百度的核心技术,但带来的生态影响力更重要。从Apollo、PaddlePaddle开始,百度真的开始拥抱开源了。brpc的开源版和内部版很接近,只是去掉了对百度内部独有的一些基础设施的支持,我们在内网写的深入分析RPC技术细节的文档也都一并开源了,后续也会及时推送改动,请大家放心。这是一个活项目,不会拉个开源分支就不管了。
查看更多资讯>>>

未发布 wemall app商城源码Android短信监听接收器
by wemallshop keys 分享 1480147658213
未发布 .NET图像处理库ImageGear for .NET v23发布,新增AcroForm功能和亚洲OCR丨附下载
by Harriet666 keys 分享 1496731502868
ImageGear for .NET是一款图形图像处理控件,可以轻松地为程序添加扫描/压缩/条形码识别/PDF/文件查看与处理/图形编辑与处理等功能。具有扫描,压缩,浏览、添加注释,打印,图像编辑,OCR以及PDF和矢量图像支持,使开发人员可以快速地开发出图像处理程序,可用于.NET Framework2.0、3.0、3.5、4.0,ASP.NET,WPF,SilverLight,DirectX 10和Direct3D 10。支持超过100种图片格式,包含:TIFF, JPEG, CAD, Vector, 3D PDF, PDF/A, PS等。
 
最新版本的ImageGear.NET v23,为开发人员提供了新的AcroForm功能;将亚洲光学字符识别(OCR)输出添加到PDF,通过将中文、日文和韩文OCR输出结合到PDF中,扩大了适应性和在全球无缝创建PDF的能力;并通过合规性检查加强了PDF/A转换。
 
【ImageGear.NET v23最新版下载>>>】

新增功能


PDF AcroForms——创建、读取和写入PDF表单字段和数据

d353839346c4441381fb5d0d1e386b06ojpg
高级AcroForms SDK提供强大的表单功能
.NET开发中AcroForms SDK *可以将AcroForm字段添加、更新或删除到新的或现有的PDF中。这为你的用户提供从表单域读取和写入数据的方式,而无需离开你的网站或应用程序。如果他们需要更新现有的PDF,SDK会通过注释工具提供帮助。
使用表单增强你的应用程序
需要让你的用户访问数字表单?预先填充表单域允许用户直接从你的网站或应用程序将数据写入表单。将表单字段添加到PDF,包括:
·  复选框
·  文本字段
·  列表框
·  组合框
·  状态设置框
ImageGear还允许低级别访问PDF,以便用户可以直接从你的网站或应用程序访问任何文档或AcroForm。
 

亚洲OCR——包括中文、日文和韩文的语言自动检测和PDF输出
274011dbdffa41fba34c89f02c47a271ojpg

 
ImageGear增加了其先进的光学字符识别功能。ImageGear支持亚洲语言,提供中文、日文和韩文的OCR。
语言支持
亚洲OCR支持横向和纵向文字的亚洲语言。支持的语言有:
·  传统中文
·  简体中文
·  日语
·  韩语
自动语言检测技术
ImageGear使用自动语言检测技术来完成文档的OCR,包括含有亚洲语言的文档。此功能可以帮助你的业务在亚洲市场取得成功。
亚洲OCR输出格式
通过使用所有识别信息(字体细节、定位的图像区域和识别的表格结构信息)来创建格式化的输出,以重述原始文档的含义。亚洲版利用OCR引擎的强大功能,用亚洲语言创建文档图像的强大格式化输出。
亚洲版输出格式:
·  TXT
·  Word
·  Excel
·  HTML
·  PDF 

 

功能增强


OCR——改进OCR布局、分区顺序和文档

21c94ebab7e64b349fc0a74e76e8c3c0ojpg.NET,C,C ++和C#OCR
ImageGear OCR可用于Windows上的多种平台和语言,包括C,C ++,C#和其他.NET语言。ImageGear提供超过100种语言的全页光学字符识别(OCR),包括西方和亚洲语言如中文、日文和韩文。ImageGear的自动语言检测功能使OCR功能完善。
OCR可作为附件购买,为应用程序开发提供完整的文档图像库。我们的C#OCR SDK:
·  包括100多种不同的语言
·  检测并读取中文、韩文和日文
·  识别单个图像中的多种语言的字符
·  OCR样本可用于C#,VB.NET,C和C ++
全页OCR
·  通过我们的自动分区和细分功能,你的用户可以:
·  将页面自动分割为各个区域进行处理
·  根据流程、表格或图形将类型分配给定位的区域
·  用先进技术检测表格,改善数据结果重构
·  处理页面的全幅图像或单个区域
·  由用户定义区域,从文件加载或由引擎自动检测
最大精度的图像预处理
OCR之前会发生什么?看看OCR的预处理步骤:
·  高级图像处理方法可用于提高OCR精度
·  自动反转功能检测图像是否需要反转以获得最高精度
·  自动图像方向检测和调整图像
·  纠错方法检测图像并自动校正,提高分割和识别精度
·  去斑方法去除图像捕获过程中的污点和缺陷
·  分辨率增强提高了低分辨率图像的质量
预定义和可定制的字典
ImageGear的OCR在扫描文档时使用预定义的字典和数据字典。ImageGear使用17种不同语言的高级拼写检查,每种语言都在特定字典中。17个词典中的每一个都包含100,000到200,000个条目。垂直字典可以改善医疗和法律行业的拼写检查和OCR准确性。
卓越的结果处理
ImageGear OCR引擎以Unicode格式处理所有数据。可以为具有多个输出选项的特定代码页格式化数据输出,如:
·  PDF上的图像
·  基于文本的PDF
·  Microsoft Office 2007
·  Microsoft Office 97(Word,Excel和Powerpoint)
·  RTF
·  HTML
·  XML
OCR版本:ImageGear的功能选项
ImageGear有三个不同的功能选项。三个选项之间的主要区别是OCR引擎创建的输出格式。你的开发选项如下:
1、标准版
标准版为西方语言(如英语)创建输出格式。标准版仅输出文本文件并生成PDF。它包括的文件格式是可搜索的文本PDF和文本文档。
2、标准版Plus
标准版本Plus为西方语言(如英语)创建格式化输出。使用识别技术创建格式化的输出,以识别字体细节、定位图像区域并识别表格结构以创建原始文档。它包括的文件格式有Word、Excel、HTML、可搜索的PDF和文本文档。
3、亚洲版
亚洲版为亚洲语言(如中文,日语和韩语)创建格式化的输出。这种格式化的输出是使用与标识字体相同的识别技术来创建的,它标识字体细节、定位图像区域,并识别表格结构。格式包括Word、Excel、HTML、可搜索的PDF和文本文档。
*目前该功能仅适用于ImageGear for .NET。
 

PDF/A——丰富的PDF/A,并具有PDF/A转换的合规性检查

55374f37758442cbb78dd8962f7c570dojpg将PDF文件转换成PDF/A文件
PDF/A是一种ISO标准类型的PDF文件,用于存档和长期保存文件,以便它们能够与原始文件完全一致。元素(如字体)必须是独立的或嵌入的,以保留原始文件的格式和属性。PDF/A已经在欧洲流行,在美国正成为更广泛使用的文件格式。
ImageGear PDF/A特点:
·  根据光栅图像文件和扫描的图像创建PDF/A文件
·  验证PDF/X(PDF/X-1a,PDF/X-3和PDF/X-4)和PDF/A(PDF/A-1a和PDF/A-1b)合规性的PDF文件
·  将不合格的PDF文件转换为符合PDF/A-1b的PDF文件
·  新的增强功能可以改善从PDF到PDF / A的合规检查和转换过程
*目前PDF到PDF/A转换仅在ImageGear .NET中可用。
 
 

未发布 盘点当前最流行的5个前端框架
by zoujiajun33 keys 分享 1498554457020
如今出现了大量的CSS前端框架,但真正优秀的框架只有少数几个。本文将会比较其中五个最佳的框架。每个框架都有自己的优点和缺点,以及具体的应用领域,你可以根据自己的具体项目需求进行选择。此外,许多选项都是模块化的,允许你仅使用所需的组件,甚至可以混合使用来自不同框架的组件。
未发布 矢量图形引擎库VectorDraw Developer Framework更新至v7.7012.1.1,周年8.5折限时特惠!
by Harriet666 keys 分享 1509529066316
VectorDraw Developer Framework(VDF)是一款构建2D、3D图形并用于应用程序可视化的矢量图形引擎库。有了VDF提供的功能,您可以轻松地创建、编辑、管理、输出、输入和打印2D和3D图形文件。该库还支持许多矢量和栅格输入和输出格式,包括本地PDF和SVG导出。VectorDraw Developer Framework最新版点击下载>>>
 
慧都十四周年狂欢开启VectorDraw Developer Framework(VDF)8.5折冰点价,限时一个月,错过不再有,马上咨询>>>
 
VectorDraw Developer Framework(VDF)v7.7012.1.1更新内容:

WebJS

新增需求(7.7012.0.1)
  • 70001107 支持vdPolyface对象的3d形状和GradientColors
  • 70001111 获取实体边界框
新增需求(7.7012.0.3)
  • 70001119 支持vdViews
  • 70001128 WebControl中增加了两个样本
新增需求(7.7012.0.5)
  • 70001115 vdViews的新功能
  • 70001133 Esc键取消整个polyline命令
  • 70001160 3d渲染支持更多的截面剪辑
新增需求(7.7012.0.7)
  • 70001171 在所有绘图实体上绘制新的临时实体
  • 70001172 获取复制的实体
新增需求(7.7012.0.9)
  • 70001194 支持标准折线和直角的宽度
 
漏洞(7.7012.0.1)
  • 70001098 vdSelectionModified事件返回不正确的所选项目数
漏洞(7.7012.0.2)
  • 70001118 GetEntitiesFromLayer()方法中的错误
漏洞(7.7012.0.3)
  • 70001123 isCanceled在scriptCommand.select中始终返回true
漏洞(7.7012.0.4)
  • 70001127 MouseRightButton和e鼠标按钮在Web控件中不一致
漏洞(7.7012.0.9)
  • 70001198 3D视图中的鼠标位置不正确
 
通常( 7.7012.0.5)
  • 70001162 WebCad示例已添加到WebControl中
通常( 7.7012.0.7)
  • 70001179 取消动作已被双击删除
 

Converter

新增需求(7.7012.0.5)
  • 70001159 支持DWG 2018格式
 
漏洞(7.7012.0.5)
  • 70001165 错误的文本转换
漏洞(7.7012.0.9)
  • 70001195 特定的.DWG不打开
 

vdDXF

漏洞(7.7012.0.5)
  • 70001147 无法在ACAD中打开DXF
  • 70001150 DefPoint1和LinePosition在保存后交换特定径向尺寸的值
  • 70001152 DXF文件加载并保存的问题
 

Engine

新增需求(7.7012.0.1)
  • 70001096 无法选择带有窗口选择的面
  • 70001105 提升GradientColors
  • 70001106 cmdMultiline中的自我复制
新增需求(7.7012.0.4)
  • 70001144 ZoomPrevous和鼠标放大
新增需求(7.7012.0.5)
  • 70001155 启用opengl反斜杠的细线
  • 70001157 以2D线模式应用部分剪辑
新增需求(7.7012.0.7)
  • 70001176 MText改进
  • 70001185 禁用默认屏幕显示的新方法
新增需求(7.7012.0.8)
  • 70001189 相对于最后一个折线段的PolarTrack
新增需求(7.7012.0.9)
  • 70001192 使用形状编号获取SHX中形状的ShapeName
 
漏洞(7.7012.0.1)
  • 70001102 编辑文本时的EditText问题
  • 70001109 如果在没有GetGripSelection方法的情况下添加选择,则不会引发GripModified事件
  • 70001110 Mtext未正确呈现
  • 70001113 3D模式中的文本线型显示错误
漏洞(7.7012.0.2)
  • 70001114 手柄选择未正确更新,并且屏幕上仍然显示
  • 70001116 UpdatePropertiesFromPrinter丢失纸张信息
  • 70001117 实用程序GetLineTypeDlg的Wrapper不会返回正确的行类型
漏洞(7.7012.0.3)
  • 70001125 删除特定折线中的RemoveInLinePoints
  • 70001126 3DPolyline未正确导入
  • 70001137 在WPF数字键控中的控制功能可以使5位数字达到9位
  • 70001140 3D pollyine在DXF 12中无法正确保存
  • 70001141 将特定的Poly Hatches保存到DXF会导致生成无效的DXF
漏洞(7.7012.0.4)
  • 70001131 文件没有使用ocx打开
  • 70001142 线型打印出现错误的刻度
  • 70001145 vdInsert的BoundinBox不正确
漏洞(7.7012.0.5)
  • 70001151 MText对象不符合BoxWidth
  • 70001154 ActiveTextHorJustify文本命令的问题
  • 70001158 当在ATI卡中使用OpenGL设置EdgeColor时,不正确的行将被渲染
  • 70001161 vdInsert与AligneToView未正确选择
漏洞(7.7012.0.6)
  • 70001166 CmdSketch忽略MouseElevation属性
  • 70001167当活动图层冻结时,CmdDimStyleDialog预览为空
漏洞(7.7012.0.7)
  • 70001170 vdSelection选择所有的问题
  • 70001173 VDF ActiveX 64位指针问题
  • 70001175 dwg未以vds格式正确导出
  • 70001181 Mtext命令无法正常使用特定文本
  • 70001184 忽略MaxBmpMemorySize for x86应用程序
漏洞(7.7012.0.8)
  • 70001187 EMF文件在不同分辨率的PC上加载不同的绘图大小
  • 70001188 PolarTrackAngle与SnapAngle不相关
漏洞(7.7012.0.9)
  • 70001196 图像透明度在wire2dGdiPlus模式下不起作用
  • 70001199 具有自定义对象xproperties的DXF未正确保存
2017慧都十四周年狂欢搞事情!砸金蛋100%抽现金红包、满额豪送iPhone X、iPhone 8、DevExpress汉化免费送、团队升级培训套包劲省10万元......更多惊喜等您来探索!

未发布 Android与iOS在企业中谁的安全性更佳?答案在这里!
by zoujiajun33 keys 分享 1488865139058

在WP(Windows Phone)销声匿迹之后,如今的智能手机已经完全形成了iOS和Android两大阵营,关于这两个系统的对比评价的说法非常多。

iOS和Android系统各有优劣,喜欢哪个全凭自己,但是在安全性方面有一个普遍的共识是:iOS比Android要更加的安全可靠。真的是这样吗?

想像一下:如今的手机比20年前的超级电脑都要强大10倍,其安装的软件由数千万条代码写就而成,背后的开发者达到了百万人级别,而这些开发者中就不乏黑客的存在。因此,想要找出手机中的漏洞对强悍的黑客来说根本不是问题。


未发布 LoadRunner Vuser基本概念和应用
by zoujiajun33 keys 分享 1476437123538
本次给大家带来LoadRunner Vuser基本概念和应用,供参考和学习~
代码审查:写出好的 commit message
by ourjs keys 编程技巧 1386724567000

为什幺要关注提交信息

  • 加快 Reviewing Code 的过程
  • 帮助我们写好 release note
  • 5年后帮你快速想起来某个分支,tag 或者 commit 增加了什么功能,改变了哪些代码
  • 让其他的开发者在运行 git blame 的时候想跪谢
  • 总之一个好的提交信息,会帮助你提高项目的整体质量

基本要求

  • 第一行应该少于50个字。 随后是一个空行 第一行题目也可以写成:Fix issue #8976
  • 喜欢用 vim 的哥们把下面这行代码加入 .vimrc 文件中,来检查拼写和自动折行
autocmd Filetype gitcommit setlocal spell textwidth=72
  • 永远不在 git commit 上增加 -m <msg> 或 --message=<msg> 参数,而单独写提交信息

 近期热门 - 点击最多
  1. python基于asyncio实现 Redis 的异步操作哈希数据写入 / 读取、发布订阅消息中间件
  2. Node.js 打印vite react+go项目目录树
  3. Angular入门:用Signals状态管理和Bootstrap基础样式实现的用户登录注册实例教程
  4. 用Gitea搭建免费Git服务器自定义Actions配置CI/CD自动化部署和测试流水线
  5. FastAPI+SQLModel+PostgreSQL+React+Vite全栈项目文件结构说明环境搭建与初始化指南
  6. React结合vite使用vue3,在纯typescript的react hooks中使用vue
  7. valtio基于Proxy代理比redux\zustand更简洁的react状态管理库
  8. React Native为http网络请求添加timeout超时异常处理: 用XMLHttpRequest替换fetch发送的区别
  9. React Native使用fetch发送http登陆验证请求失败:无法读取set-cookie并显示network request failed
  10. 克服Redux的缺点在React/Native中使用消息队列,pubsub-js更加简洁的组件间通信和状态传递方法

  全端社区 - 最新回复
  1. 在无管理员权限的情况下,使用安装Python补全 pip临时配置环境变量
  2. Python鉴权方法:Depends 依赖注入;装饰器;与基于Proxy模式的Session状态管理自动计算脏属性;将用户数据存储在Redis中
  3. python基于asyncio实现 Redis 的异步操作哈希数据写入 / 读取、发布订阅消息中间件
  4. Angular入门:用Signals状态管理和Bootstrap基础样式实现的用户登录注册实例教程
  5. 用Gitea搭建免费Git服务器自定义Actions配置CI/CD自动化部署和测试流水线
  6. FastAPI+SQLModel+PostgreSQL+React+Vite全栈项目文件结构说明环境搭建与初始化指南
  7. Node.js 打印vite react+go项目目录树
  8. valtio基于Proxy代理比redux\zustand更简洁的react状态管理库
  9. Windows与Mac通过git ssh和rsync实现文件共享互传
  10. Windows与Mac通过git ssh和scp实现文件共享互传

  开源的 OurJS
OurJS开源博客已经迁移到 OnceOA 平台。

  关注我们
扫一扫即可关注我们:
OnceJS

OnceOA