科技新闻

　　疫情对我们国家的生活和经济都造成了巨大破坏，当很多商业无法正常开展，用户宅在家里时，小程序的「轻」显得如此之「重」，它迅速满足了各种商业需要快速线上开展业务，有效链接用户的特性，也满足了C端用户无需下载，无需学习的「懒」需求，在2020年2月份这个极为特殊的时间，小程序互联网提前爆发了。 　　突如其来的疫情，使得小程序只用了一个多月，在2020年2月份就实现了全面爆发。 　　疫情之“危”下，小程序业态勃发生“机” 　　根据官方的消息，2019年微信小程序的日活超过了3亿，累计创造了8000多亿的交易额。截止到2月14日，小程序超市业态的访问量同比增长了115%，生鲜蔬果的访问量同比增加了168%，社区电商同比增长了83%。明显可见，各大商家在纷纷加码小程序。 　　一方面，微信作为超级APP提供了巨大的流量；另一方面，这种巨额的流量关键还是免费的。除此之外，微信团队在技术上的赋能，也是推动行业内小程序快速发展的重要原因。 　　同样我们也收集了一些客户在疫情期间使用小程序的情况： 　　疫情期间，我们生鲜超市小程序单线上营业额4000单，累计金额20万+。 　　客户的小程序收款提示都是连着串不停歇，日进斗金！ 　　太多太多案例，让我们不难发现小程序新的机会 　　1用户习惯的养成 　　抗击疫情的小长假，让我们对于娱乐、网上购物、在线学习和了解疫情等需求增加，因此视频、网络购物、购物

3 月，跳不动了？>>> mac微信小助手是mac上一款非常强大的微信插件，这款插件想必很多人都用过，其功能非常多，包括自动回复、消息防撤回、远程控制、微信多开、登录免认证、会话多选删除等。 安装教程 下载： https://www.macdown.com/mac/6396.html 微信小助手 mac版镜像包下载完成后，打开镜像包，将左侧的【微信小助手】拖到右侧应用程序进行安装，如图： 打开微信小助手弹出提示框，点击安装，如图： 点击好，如图： 选择启动微信，如图： 登陆您的mac微信，如图： 在微信菜单栏，找到微信小助手，如图： 注意！安装微信小助手出现错误提示，如图： 解决方法：右键打开微信小助手，我们选择【显示包内容】，如图： 打开【data】文件夹，如图： 打开微信小助手里面的Data文件，将install文件拖到终端里，然后点击回车键运行就解决这个问题了 微信小助手 mac版主要功能 消息自动回复 消息防撤回 远程控制(已支持语音) 微信多开 第二次登录免认证 聊天置底功能(类似置顶) 微信窗口置顶 会话多选删除 自动登录开关 通知中心快捷回复 聊天窗口表情包复制 & 存储 会话一键已读 一键清除空会话 支持国际化 去除微信url转链（从此直接打开抖音链接） 新增移除会话(不删除聊天记录) 新增是否使用微信自带浏览器开关 新增LaunchBar 扩展 来源：

常见的http状态码 100：继续 客户端应当继续发送请求。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。 101： 转换协议 在发送完这个响应最后的空行后，服务器将会切换到在Upgrade 消息头中定义的那些协议。只有在切换新的协议更有好处的时候才应该采取类似措施。 102：继续处理 由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。 200：请求成功 处理方式：获得响应的内容，进行处理（重要） 201：请求完成，结果是创建了新资源。新创建资源的URI可在响应的实体中得到 处理方式：爬虫中不会遇到 202：请求被接受，但处理尚未完成 处理方式：阻塞等待 204：服务器端已经实现了请求，但是没有返回新的信 息。如果客户是用户代理，则无须为此更新自身的文档视图。 处理方式：丢弃 300：该状态码不被HTTP/1.0的应用程序直接使用， 只是作为3XX类型回应的默认解释。存在多个可用的被请求资源。 处理方式：若程序中能够处理，则进行进一步处理，如果程序中不能处理，则丢弃 301：请求到的资源都会分配一个永久的URL，这样就可以在将来通过该URL来访问此资源 处理方式：重定向到分配的URL（永久重定向，重要） 302：请求到的资源在一个不同的URL处临时保存 处理方式：重定向到临时的URL（临时重定向，重要） 304：请求的资源未更新 处理方式

1，遇到特殊情况抛出异常而不是返回None 2，有些情况需要将重要的消息优先显示在其它内容前面，例如在用户界面绘制的时候，实现方法如下 def sort_priority(values,group): def helper(x): if x in group: # 如果在优先组内，那就排到最前面 return (0,x) # python会以特殊的形式比较两个元组，解释看下面 return (1,x) values.sort(key=helper) Python比较元组（或列表）：可以想象比较的过程[(0,7),(0,8),(1,3)]，那么Python进行比较的时候，会先进行元组的一个元素排序，然后再根据排序结果，对元组中第二个元素基于第一个元素的位置进行排序，当然最后输出的结果还是正常的列表[7,8,3]，这只是其中比较的过程 3，nonlocal声明获取闭包内的数据，但它不能延伸至模块级别，而且复杂的函数情况下应该尽量少用，如果越写越复杂，可以将相关状态封装成辅助类 class Sorter(object): def __init__(self,group): self.group=group self.found=False def __call__(self,x): #修改这个后能够使得将类的实例当函数一样调用 if x in self.group: self.found

我们都知道，WCF支持Duplex的消息交换模式，它允许在service的执行过程中实现对client的回调。WCF这种双向通信的方式是我们可以以Event Broker或者订阅/发布的方式来定义和调用WCFService。今天我们就给大家一个具体的例子：通过WCF的duplex communication方式现在Session管理。 1、Session 管理提供的具体功能 我们的例子实现了下面一些Session Management相关的功能： Start/End Session： 可以调用service开始一个新的Session或者结束掉一个现有的Session。当开始一个Session的时候，service根据client端传入的client相关的信息（ClientInfo），创建一个SessionInfo对象，该对象由一个GUID类型的SessionID唯一标识，代表一个具体的Client和Service的Session。在service端，通过一个dictionary维护者一个当前所有的activesession列表，key为SessionID，value是SessionInfo对象。当client调用相应的service，传入对应的SessionID，该SessionID对应的SessionInfo从该session列表中移除。 Session Timeout：

我们都知道，WCF支持Duplex的消息交换模式，它允许在service的执行过程中实现对client的回调。WCF这种双向通信的方式是我们可以以Event Broker或者订阅/发布的方式来定义和调用WCF Service。今天我们就给大家一个具体的例子：通过WCF的duplex communication方式现在Session管理。 一、Session 管理提供的具体功能 我们的例子实现了下面一些Session Management相关的功能： Start/End Session： 可以调用service开始一个新的Session或者结束掉一个现有的Session。当开始一个Session的时候，service根据client端传入的client相关的信息（ClientInfo），创建一个SessionInfo对象，该对象由一个GUID类型的SessionID唯一标识，代表一个具体的Client和Service的Session。在service端，通过一个dictionary维护者一个当前所有的active session列表，key为SessionID，value是SessionInfo对象。当client调用相应的service，传入对应的SessionID，该SessionID对应的SessionInfo从该session列表中移除。 Session Timeout：

一、什么是死信队列 当消息在一个队列中变成一个死信之后，它将被重新publish到另一个交换机上，这个交换机我们就叫做死信交换机，私信交换机将死信投递到一个队列上就是死信队列。具体原理如下图： 消息变成死信的三种情况： 消息被拒绝(basic.reject / basic.nack)，并且requeue = false 消息TTL过期 队列达到最大长度 二、手动签收应答模式 应答模式分为两种，手动签收和自动签收，自动应答就是消费者消费了一条消息就自动告诉队列删除消息。这样的弊端就是不管消费逻辑有没有成功，都会将消息删除，这样就会造成消息丢失。而使用手动签收后，就是在消费逻辑处理成功后，手动告诉队列消费成功，然后队列再去删除这条消息。 再消费者配置文件中开启手动签收模式 spring.rabbitmq.listener.simple.acknowledge-mode = manual 在消费逻辑处理成功后手动签收，修改消费者代码 @RabbitListener(queues = QUEUE_NAME) public void receiveMessage(Message message,@Headers Map<String,Object> headers, Channel channel) throws Exception { Jedis jedis = new Jedis(

3 月，跳不动了？>>> 一、什么是死信队列 当消息在一个队列中变成一个死信之后，它将被重新publish到另一个交换机上，这个交换机我们就叫做死信交换机，私信交换机将死信投递到一个队列上就是死信队列。具体原理如下图： 消息变成死信的三种情况： 消息被拒绝(basic.reject / basic.nack)，并且requeue = false 消息TTL过期 队列达到最大长度 二、手动签收应答模式 应答模式分为两种，手动签收和自动签收，自动应答就是消费者消费了一条消息就自动告诉队列删除消息。这样的弊端就是不管消费逻辑有没有成功，都会将消息删除，这样就会造成消息丢失。而使用手动签收后，就是在消费逻辑处理成功后，手动告诉队列消费成功，然后队列再去删除这条消息。 再消费者配置文件中开启手动签收模式 spring.rabbitmq.listener.simple.acknowledge-mode = manual 在消费逻辑处理成功后手动签收，修改消费者代码 @RabbitListener(queues = QUEUE_NAME) public void receiveMessage(Message message,@Headers Map<String,Object> headers, Channel channel) throws Exception { Jedis jedis =

一、WPF为何需要命令 我们已经知道WPF里已经有了路由事件，可以发布及传播一些消息，那为什么还需要命令呢？这是因为事件指负责发送消息，对消息如何处理则不管，而 命令是有约束力，每个接收者对命令执行统一的行为，比如菜单上的保存，工具栏上的保存都必须是执行同样的保存。 二、命令系统的基本元素 命令(Command)：实现了ICommand接口的类，经常使用的有RoutedCommand类 命令源: 是命令的发送者，是实现了ICommandSource接口的类，大部分界面的控件都实现了这个接口，Button, MenuItem 等等。 命令目标：命令的接收者，命令目标是视线了IInputElement接口的类。 命令关联：负责一些逻辑与命令关联起来，比如判断命令是否可以执行，以及执行完毕后做一些处理。 三、四个命令元素之间的关系 四、命令示例 我们让一个按钮发送Hello命令给文本框，文本框接收这个命令后显示“Nice to meet you”. view source print ? 01 < Window x:Class = "DeepXAML.MainWindow" 02 xmlns = " http://schemas.microsoft.com/winfx/2006/xaml/presentation " 03 xmlns:x = " http://schemas

应用场景 目前常见的应用软件都有消息的延迟推送的影子，应用也极为广泛，例如： 淘宝七天自动确认收货。在我们签收商品后，物流系统会在七天后延时发送一个消息给支付系统，通知支付系统将款打给商家，这个过程持续七天，就是使用了消息中间件的延迟推送功能。 12306 购票支付确认页面。我们在选好票点击确定跳转的页面中往往都会有倒计时，代表着 30 分钟内订单不确认的话将会自动取消订单。其实在下订单那一刻开始购票业务系统就会发送一个延时消息给订单系统，延时30分钟，告诉订单系统订单未完成，如果我们在30分钟内完成了订单，则可以通过逻辑代码判断来忽略掉收到的消息。 在上面两种场景中，如果我们使用下面两种传统解决方案无疑大大降低了系统的整体性能和吞吐量： 使用 redis 给订单设置过期时间，最后通过判断 redis 中是否还有该订单来决定订单是否已经完成。这种解决方案相较于消息的延迟推送性能较低，因为我们知道 redis 都是存储于内存中，我们遇到恶意下单或者刷单的将会给内存带来巨大压力。 使用传统的数据库轮询来判断数据库表中订单的状态，这无疑增加了IO次数，性能极低。 使用 jvm 原生的 DelayQueue ，也是大量占用内存，而且没有持久化策略，系统宕机或者重启都会丢失订单信息。 消息延时推送实现 在 RabbitMQ 3.6.x 之前我们一般采用死信队列+TTL过期时间来实现延迟队列。