后台产品

第一篇博客,不当之处请交流! 首先说明下BUG: 项目上要用MQTT实现消息实时推送,后台采用 org.eclipse.paho.client.mqttv3-1.0.1.jar .页面上采用 paho-mqtt.js MQTT服务用的别人家的产品 EMQ . 后来问题来了,客户由于安全问题,不给开端口......就是不能采用EMQ这个产品了 只能在自己的项目下开MQTT服务的TCP连接和websocket连接,后台服务服务写好后测试JS中websocket连接. 连接没有问题,连接成功,接收消息时,BUG出现 由于后台写MQTT消息时格式不严谨,出现了畸形的数据 经研究发现:除了message.payloadString方法外,还有message.payloadBytes方法,返回的是Uint8Array对象. 直接将Uint8Array对象转换成String,上代码 好了,拿上对象继续做处理,BUG处理完毕,至于测试_1为什么乱码,这里就不做说明了,有兴趣的自己研究下吧! 第一次写博客,有不适当的可以评论指出,下次修改,以后会继续将工作中的BUG以博客的形式发布,为了自己的记忆,也为了和大家讨论! 文章来源: BUG脱坑日志

介绍地址 https://panjiachen.github.io/vue-element-admin-site/zh/guide/ vue-element-admin 是一个后台前端解决方案，它基于 vue 和 element-ui实现。它使用了最新的前端技术栈，内置了 i18 国际化解决方案，动态路由，权限验证，提炼了典型的业务模型，提供了丰富的功能组件，它可以帮助你快速搭建企业级中后台产品原型。相信不管你的需求是什么，本项目都能帮助到你。 建议 本项目的定位是后台集成方案，不太适合当基础模板来进行二次开发。因为本项目集成了很多你可能用不到的功能，会造成不少的代码冗余。如果你的项目不关注这方面的问题，也可以直接基于它进行二次开发。 集成方案: vue-element-admin 基础模板: vue-admin-template 桌面终端: electron-vue-admin Typescript 版: vue-typescript-admin-template (鸣谢: @Armour) 文章来源: https://blog.csdn.net/weixin_40333655/article/details/96995941

SDK 已经具备不需要代码埋点就能 自动的、动态可配的、全面且正确 的收集用户在使用 App 时的所有事件数据。除此之外，还单独开发了与之配合的圈选SDK，能够在 App 端完成对界面元素的圈配以及 KVC 配置的上传。而界面元素圈配的工作完全可以交给用研与产品人员来做，减轻了开发人员的工作量。 SDK 已有的功能可以分为两大部分： 基本事件数据的收集：基本事件的收集是指应用冷启动事件、页面事件、用户点击事件、ScrollView滑动事件等，这部分全部都是自动完成的，实现思路会在第一节中介绍。 业务层数据的收集：业务层数据的收集是指对与业务功能相关的一些数据，例如：在用户点击提交订单按钮时，收集用户购买的物品以及订单总金额的数据。这种业务层数据的收集以往大多通过 代码埋点 的方式去做，本SDK则真正的实现了 无埋点 的去获取这些想要的业务数据。这部分的实现会在本文的第二节详细介绍。 SDK的整体实现思路 SDK 整体采用了 AOP（Aspect-Oriented-Programming）即面向切面编程的思想，就是动态的在函数调用的前后插入数据收集的代码。在 Objective-C 中的实现是基于 Runtime 特性的 Method Swizzling 黑魔法。 SDK 的数据收集功能的实现主要通过 Method Swizzling 来 hook 相应的方法

　　我来到现在这家公司有一年多的时间，一直做的是财政系统相关的产品，前端的技术栈用的是传统的jQuery+bootStrap+requireJs，随着项目的开发，越来越多的弊病凸显出来。 　　首先是前后端的代码存放在同一个工程目录下，前后端工程师进行开发时，都必须把整个项目导入到开发工具中（像myEclipse和IntelliJ IDEA等），一方面前端在开发之前需要花费大量的时间来部署开发环境，如果后端上传错了文件，整个系统启动不起来，前端就只能干等着，前后端耦合性很大，另一方面使用myEclipse这样的开发工具开发前端项目操作上不熟悉，开发效率很低。 　　其次在整个项目中，组件化很明显，大多数页面中所需要的功能都是类似的，虽然可以使用require封装一些公用的组件，但是由于js技术有限，组件与组件之间还是存在很多耦合的问题，并且随着自定义的组件越来越多，经常遇到一个页面开头先加载几十个组件的情况，后期维护也很麻烦，对于有代码洁癖的人来说，这显然不是一种好方法。 　　于是就想到用react能不能解决这些问题呢？ 　　什么是前后端分离 　　这几年前后端分离被提到的越来越多，在网上查什么是前后端分离，基本是说后台只提供数据api，与用户的交互操作前端来实现。我们现在的工作模式，前端也是通过ajax请求后台数据，前端的代码单独放在工程目录的一个文件夹中，不与后台的代码耦合

在使用Mob的时候，首先要去Mob官网申请注册一个账号，然后打开登录到Mob里面，打开控制界面，然后进行Mob用户后台使用的一系列设置，具体如下所示。 一、创建应用获得AppKey 1、注册Mob账号 2、登录Mob 登录到Mob用户后台之后，点击顶部菜单栏左上角的“添加应用”按钮，然后会弹出创建新应用的对话框，接着填写应用的名称。如果是使用短信验证码的用户，这个应用名称会显示在验证短信内容里面的。 二、添加功能 1、创建新应用 2、添加SMSSDK功能 3、查看概况 4、短信设置 在第一步操作填写应用名称保存成功之后，界面会跳转到设置显示界面，如果没有选择功能SDK，会显示暂未添加SDK产品的提示，然后去左侧设置菜单栏里面添加设置，选择需要的SDK功能，一个应用里面可以添加多个SDK，但是这些添加的SDK都会使用同一个App Key 和App Secret。 三、查看和修改应用信息 1、设置 应用名称可以在左侧目录的“设置”中修改。 四、查看同一账号下的其他应用 1、查看应用信息 找到左侧菜单栏的顶部，在应用名称后面有一个小三角符号的按钮，然后点击这个小三角按钮，即可显示账号下添加的所有应用，点击不同的应用可以自动切换到该应用对应的相关数据。 2、iOS的App项目里面使用集成Mob的基本添加设置方法，如下图所示： 以上就是本章全部内容，欢迎关注三掌柜的微信公众号，欢迎关注！

一、登录(login.py) from tkinter import ttk from tkinter import messagebox import tkinter import function import Main class Login(object): def __init__(self): self.root = tkinter.Tk() #去除windows 边框 self.root.overrideredirect(True) self.root.title('后台管理系统') # 禁止改变窗口大小 self.root.resizable(False, False) # 创建画布 self.canves = tkinter.Canvas(self.root, height=300, width=455) # 画布插入图片 self.image_file = tkinter.PhotoImage(file='welcome_1_meitu_3.png') # 加载图片文件 self.image = self.canves.create_image(0, 0, anchor='nw', image=self.image_file) # 放置画布（为下端） self.canves.pack(side='bottom') # 文本框（用户账号） self.en =

App 测试 web 测试的区别 单纯从功能测试的层面上来讲的话， APP 测试、web 测试 在流程和功能测试上是没有区别的 根据两者载体不一样，则区别如下： 1、系统结构方面 web项目，b/s架构，基于浏览器的；web测试只要更新了服务器端，客户端就会同步会更新 app项目，c/s结构的，必须要有客户端；app 修改了服务端，则客户端用户所有核心版本都需要进行回归测试一遍 2、性能方面 web项目 需监测 响应时间、CPU、Memory app项目 除了监测 响应时间、CPU、Memory外，还需监测流量、电量等 3、兼容方面 web项目： 1. 浏览器（火狐、谷歌、IE等） 2. 操作系统（Windows7、Windows10、OSX、Linux等） app项目： 1. 设备系统: iOS（ipad、iphone）、Android（三星、华为、联想等） 、Windows（Win7、Win8）、OSX（Mac） 2. 手机设备可根据 手机型号、分辨率不同 4、相对于 Wed 项目，APP有专项测试 1. 干扰测试：中断，来电，短信，关机，重启等 2. 弱网络测试（模拟2g、3g、4g，wifi网络状态以及丢包情况）；网络切换测试（网络断开后重连、3g切换到4g/wifi 等） 3. 安装、更新、卸载 安装：需考虑安装时的中断、弱网、安装后删除安装文件等情况 卸载：需考虑

https://blog.csdn.net/paolei/article/details/94390330 背景简介 　　对于大型应用后台系统来说，稳定性至关重要。目前越来越多的大型应用系统采用微服务架构，更加需要关注稳定性的技术能力建设。稳定性是服务系统基础能力的体现。 　　基础知识 　　在介绍稳定性技术策略主题之前，我们首先梳理一些基础概念和知识。 　　针对我们业务后台系统建设，任何大型业务后台系统绝对不是一蹴而就。它是伴随着业务不同阶段，不断进行演进的过程。如果经历过从 0 到 1 建设一个业务后台系统的同学，都会有类似的体会。 　　启动阶段 　　启动阶段，业务模型相对简单，用户量少，这时候我们可以将所有的系统模块耦合在一个工程里面，进行单机部署。这时候可能仅仅需要将业务系统与数据库进行隔离。 　　探索阶段 　　探索阶段，业务模型不断演进，用户量增加，单机服务能力瓶颈凸显。这时候就需要由单机服务部署向集群服务部署来优化，利用负载均衡将请求合理分配，减少单机服务压力。另外一个方面，数据量不断的增加，也需要考虑针对数据来进行水平的扩展(主从部署，读写分离)。 　　在这一阶段，我们仅仅是做了集群扩展，但所有的业务代码都在同一个工程维护，所有的数据信息都在同一个数据库中存储。随着团队的扩充与业务交互不断复杂化，在工程维护上存在很大的风险，工程研发效率受到制约

注: 后台地理处理（64 位） 可用作 ArcGIS 10.1 for Desktop、Service Pack 1 及更高版本上的独立安装。只有在已安装 后台地理处理（64 位） 产品的情况下，以下信息才适用；否则，会以 32 位完成后台处理。 什么是 64 位后台地理处理？ ArcGIS 10.1 for Desktop— 后台地理处理（64 位） 产品的安装替代了按照标准具有 ArcGIS 10.1 for Desktop 的常规 32 位 后台处理 。使用 64 位处理功能在 RAM 容量较大的系统进行分析有助于处理在 32 位环境中无法处理的大量数据。由于所有执行工作都在原生 64 位空间中完成，因此可使用更多系统资源。 在后台执行的工具支持您当前的许可。例如，当您获得了 ArcGIS for Desktop Standard 的许可后，后台执行将会支持所有获得 Standard 许可的工具。后台处理不会消耗第二个许可；每台机器只使用一个许可。 ArcGIS 10.1 for Desktop— 后台地理处理（64 位） 可供使用 10.1 版本的客户使用，并可从 修补程序和补丁包 站点下载。该产品只能安装在 64 位操作系统上。 注: 如果您想返回至 32 位后台处理，则需卸载 64 位后台处理软件。 使用 64 位后台处理 您可通过在后台执行工具来继续与应用程序进行交互

1 APP测试基本流程 1.1流程图 1.2测试周期 测试周期可按项目的开发周期来确定测试时间，一般测试时间为两三周（即15个工作日），根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目排期。 1.3测试资源 测试任务开始前，检查各项测试资源。 --产品功能需求文档； --产品原型图； --产品效果图； --行为统计分析定义文档； --测试设备（ios3.1.3-ios5.0.1；Android1.6-Android4.0；Winphone7.1及以上；Symbian v3/v5/Nokia Belle等）； --其他。 1.4日报及产品上线报告 1）测试人员每天需对所测项目发送测试日报。 2）测试日报所包含的内容为： --对当前测试版本质量进行分级； --对较严重的问题进行例举，提示开发人员优先修改； --对版本的整体情况进行评估。 3）产品上线前，测试人员发送产品上线报告。 4）上线报告所包含的内容为： ---对当前版本质量进行分级； ---附上测试报告（功能测试报告、兼容性测试报告、性能测试报告以及app可用性能标准结果）； --总结上线版本的基本情况。若有遗留问题必须列出并记录解决方案。 2 App测试点 2.1安全测试 2.1.1软件权限 1）扣费风险：包括发送短信、拨打电话、连接网络等 2）隐私泄露风险：包括访问手机信息、访问联系人信息等 3