| <!DOCTYPE html> | |
| <html lang="en"> | |
| <head> | |
| <meta charset="UTF-8"> | |
| <meta name="viewport" content="width=device-width, initial-scale=1.0"> | |
| <meta http-equiv="X-UA-Compatible" content="ie=edge"> | |
| <title>Mobile HLS video</title> | |
| </head> | |
| <body> | |
| <h1>Mobile HLS video</h1> |
| # coding=utf-8 | |
| import time | |
| from datetime import datetime | |
| from threading import Thread | |
| from redis import StrictRedis | |
| from redis.exceptions import ConnectionError | |
@(工作) ####介绍 项目系统间是通过接口进行业务调用，业务目前分B2C和C2C两种交易模式，不同游戏在相同或者不同的交易模式下，校验、支付、商品交互、发货等业务处理也不一样。这就形成相同场景下不同的业务处理需求。重构前的代码部分采用了工厂模式和抽象工厂方法，但是由于抽象工厂方法的原因导致结构设计特别冗余，编码起来特别繁琐，修改起来更麻烦。重构前还有一个不好的地方是B2C和C2C的校验是放一块的，通过交易模式来划分，但是如果不同游戏的校验不一样的话，很难扩展。
重构后的设计是，按业务划分，通过交易模式和游戏类别来生成相关的交易业务Service，将相同的业务方法写到抽象父类的方法中，抽象父类对外只暴露业务接口方法，这样保证了业务入口的一致性，防止业务方法被部分调用的错误。不同游戏、不同模式的业务方法写到相关的子类中，保证业务方法的特殊性。 拿下单校验举例，代码如下：
public class TradeFactory {
| #!/usr/bin/env python | |
| # post-receive hook for git-based deployments | |
| import sys | |
| import os | |
| from subprocess import call | |
| # configuration | |
| deploy_to_path = '/path/to/deploy/directory/' | |
| deploy_branch = 'master' |
| #! /bin/env python | |
| # -*- coding: utf-8 -*- | |
| # | |
| #todo： | |
| # 使用python3 | |
| # 计算md5，不用文件名来避免重复，储存 | |
| # 存储信息：json？ pickle？ txt？数据库？ 要包括 点赞数 记录当前状态下一次继续（可行？） | |
| # 改善递归： 循环套递归? | |
| # py2exe pyinstall？ | |
| # beautiful soup |
| #!/bin/bash | |
| LOADING=false | |
| usage() | |
| { | |
| cat << EOF | |
| usage: $0 [options] dbname | |
| OPTIONS: |
| import functools | |
| import pymongo | |
| import logging | |
| import time | |
| MAX_AUTO_RECONNECT_ATTEMPTS = 5 | |
| def graceful_auto_reconnect(mongo_op_func): | |
| """Gracefully handle a reconnection event.""" | |
| @functools.wraps(mongo_op_func) |
