写一个玩具

写一个玩具

核心理念

  1. 以对话的形式
  2. 用摇签的交互方式
  3. 通过信息掮客赚心里按摩的钱

模型设计

用例图

@startuml
left to right direction
skinparam packageStyle rectangle

actor "求问人" as Seeker
actor "解签人" as Interpreter
rectangle "系统" as System {
  usecase "摇晃手机模拟摇卦" as UseCase1
  usecase "向解签人求问卦象" as UseCase2
  usecase "解签人回答并提供咨询" as UseCase3
}

Seeker --> UseCase1
Seeker --> UseCase2
Interpreter --> UseCase3

@enduml

类图

@startuml
interface Role {
  +interpretation(): String
  +shake(): Yao
}

class Account {
  -name: String
  -role: Role
}

class Interpreter implements Role {
  +interpretation(): String
}

class Seeker implements Role {
  +shake(): Yao
}

class DivinationCup {
  +shake(): Yao
}

class Yao {
  -value: Boolean
}

class Hexagram {
  -yas: Yao[6]
  -interpretation: String
  +getSession(theme: String, account: Account): Session
}

class Session {
  -hexagram: Hexagram
  -interpretationRecord: InterpretationRecord
  -theme: String
  -sender: Account
  -receiver: Account
  +sendToInterpreter(): void
}

class InterpretationRecord {
  -interpreterComments: String
  -question: String
  -theme: String
}

Account --> Role : has
Seeker --> DivinationCup : uses
Hexagram --> Yao : contains
Hexagram --> Session : creates
Session --> InterpretationRecord : records

@enduml


非核心业务需求描述

  1. 使用一套代码支持多种类型程序(小程序、APP、H5等)
  2. 使用相同的业务账户
  3. 将收费项目移到可控代码处

技术选型

业务前端

  1. 目前Taro+Taro-ui
  2. 微信小程序
  3. 原生APP

可控代码后端

  1. 选用Java/Go均可

一些可以提供的服务思考

一些可以提供的服务思考

技术能力

  1. 软件建模能力,完成过交易平台核心领域建模,完成过SaaS应用市场建模
  2. 软件开发能力,Go、Java、React、Python是我的常用技术栈
  3. 画过网页界面,也画过单机可运行程序
  4. 写过上位机程序
  5. 也能修改硬件程序
  6. 有一部分运维端部署的经验,Nginx,Linux,Windows Server都使用过构建系统

沟通能力

  1. 和供应商扯过皮
  2. 和开发分解过工作
  3. 和测试配和过测试,并且成功上线
  4. 和业务喝过酒,吹过牛,还能砍需求

如何用代码挣钱

  1. 卖知识
    1. 开课?
    2. 开付费渠道?
    3. 做自媒体?
  2. 卖技能
    1. 比如针对特定情况查bug
    2. 部署网络环境
    3. 甚至硬件管控?

交易系统建模

交易系统建模

平台视角

业务域

  • 聚合根
    • 管理员/商家/采购员
    • 询价单
    • 交易订单
    • 交易对手方
    • 交易时间
    • 交易内容
      • 出库单/入库单
      • 库存
      • 批次
      • 数量
    • 履约单
      • 物流单
      • 仓储单
      • 配送单
    • 售后单
    • 摊位信息
    • 图片
    • 简介
    • 商品列表
    • 广告位
    • 结算单

支撑域

  • 技术支撑
  • 外部接入
  • 对外服务

管理域

  • 工单
  • 入驻审核单

建模图片

打家劫舍(4)(2023-09-19)

打家劫舍(4)

题目

沿街有一排连续的房屋。每间房屋内都藏有一定的现金。现在有一位小偷计划从这些房屋中窃取现金。

由于相邻的房屋装有相互连通的防盗系统,所以小偷 不会窃取相邻的房屋 。

小偷的 窃取能力 定义为他在窃取过程中能从单间房屋中窃取的 最大金额 。

给你一个整数数组 nums 表示每间房屋存放的现金金额。形式上,从左起第 i 间房屋中放有 nums[i] 美元。

另给你一个整数 k ,表示窃贼将会窃取的 最少 房屋数。小偷总能窃取至少 k 间房屋。

返回小偷的 最小 窃取能力。

题目分析

这里的核心是找到最少能偷的K间房
设x是预设的偷窃能力
f(x)是在x的偷窃能力下,能够偷的房屋
随着x的增大,f(x)总是能保持增加或者相等
我们只需要找到这个搜索能力值,并且满足f(x)正好小于k的情况

翻新系统实践

翻新系统实践

基本情况

  • freemark+jsp+java14的怪异组合
  • 有部分内部接口采用feign
  • 大部分接口采用nacos作为profile管理以及服务注册发现
  • 前端部分仅使用了以jquery和easyui为主的插件,工程化程度不高

需求说明

来自于上线时候的苦恼,每次更新代码总会引发未在版本规划内的前端代码提交,且升级时间较长,失败回滚时候还有cache问题

问题分析

  1. 交互代码和逻辑代码均由同一个开发人员完成,此时心智负担较大,在工期较为短的时候,非常容易造成误操作,且只有上线后才能发现
  2. 系统经历了十年左右的开发,每个开发人员有不同的技术栈喜好,例如早期约定使用Spring Cloud的早期版本,而在五年后发现Spring Cloud很多功能又要二次开发,转向了nacos为主的国产。成员变换中不习惯,有部分接口就干脆采取域名+Nginx网关直连的形式
  3. 除此之外业务系统的拧巴逻辑也是翻新的重大障碍

方案选择

经过和开发小组成员讨论,建议先从增量做起,避开旧有尚能完备运行的业务,其中最简单的是需要抽出一个专门的开发人力,进行前端框架的搭建。(目前使用vue2,开发人员易于招聘)

框架需要完成以下几个事项:

  1. 要替换掉原来依靠服务器进行状态管理的现状,将状态管理放在前端
  2. 要将功能路由管理放在前端框架进行管理
  3. 要维护一个列表,标记哪些路由是用于直接走原来的逻辑,哪些路由是新增的有前端管理的逻辑
  4. 需要后端软件新增接口用以维护新旧软件的状态(一次性开发成本)

在前端框架开发完成一个月后,选取更新频率最低的应用作为试点应用,避免与正在开发的任务同时进行

当前后端代码可以剥离完毕后,在考虑后端的技术栈提纯,不应将改造任务混杂

一些结局

  1. 成功改造了从外包厂商回收的代码
  2. 在重要业务中,成功替换了进门抬杆页面的代码
  3. 为后续的业务不中断升级铺平道路

证券、信息聚合系统框架与搭建(三)

证券、信息聚合系统框架与搭建

问题

  1. 现有的所有的渲染都放在客户端,服务端只有数据
  2. 客户端为了新增图表都需要更新客户端
  3. 目标用户更新客户端意图不强烈

扩大视角范围

不再只关注渲染层的事项,关注整个富客户端的架构

参考

参考后台开发组件化的趋势,做一个大而完整的软件平台

考虑到是软件平台,必须要解耦所有组件之间的直接调用关系

基础组件构成

  • 组件注册中心
  • 组件间通信工具(消息队列、消息总线)
  • 本地数据库
  • 渲染容器
  • 与行情交易柜台对接的各容器适配器

软件组件划分

高频变动数据,低变更

原生程序开发

低频数据

使用Chromium做Web开发,降低开发成本,同时因为Web软件的天然容易更新的属性,能够在变更时候不需要客户端更新基础组件

组件Example

证券,信息聚合前端框架设计与搭建(二)

证券,信息聚合前端框架设计与搭建(二)

技术选型

现有的React可能比较符合需求,但react的diff&patch是O(n^3)级别的算法,这里可能会限制我们单页Component数量

UI界面的话,可以任意选用各个大厂的UI,例如ant.design(PC)ele.me(手机H5)

另外可以自然的引入React Native

但不应该绑死在React技术栈上,防止其授权失效直接导致业务下线

实现路径

早期验证业务阶段可以自行封装Component,系统内部采用封装后的Component来进行代码的编写(Wrap)

等开发中常见的工具类,常见的Class均稳定后,替换Component的内部实现,可以考虑重新通过开源的virtual dom库来实现

设立低时延展示组件

完全避开react的渲染逻辑

手动Bind数据,手动确认渲染时刻并将其渲染时机封装在Component下,避免当高频数据到来时CPU全部分配至JS引擎来处理差分数据合并而Render线程被阻塞

逐步封装Table,List等组件

证券,信息聚合前端框架设计与搭建

证券,信息聚合前端框架设计与搭建

主旨

工程上

  • 减少前端文件的大小
  • 方便更新版本
  • 最好是单页面应用,减少sso成本
  • 代码混淆

通信性能要求

对于高频信息,应以websocket为主,主要需要解决的问题是从服务器到达客户端的延时抖动,以及TCP的延时断线问题

对于中频信息,应以定时任务刷新即可满足

若是采用差分数据方法,可以减少网络IO消耗

高频信息(ms级别)

  • L2交易数据
  • L1行情更新

中频信息(分钟级别)

  • IM
  • 公司公告

渲染性能要求

优先级高的,高频信息,应尽可能快的渲染(60FPS)(16.67ms)内合并vDom事件然后渲染

中频信息按需渲染

应给调用者refresh接口,方便业务可以直接触发更新界面事件

鸿蒙读书笔记

鸿蒙读书笔记

核心系统

kernel基本定义了线程,内存,基础数据结构的公共部分

是其他组件的基石

losbase

定义了基本的信号

定义了内存运算接口

定义了内存对齐接口

定义了休眠接口

bitmap

一些bitmap的运算

bitmap的数据结构

cpup

cpu使用量统计

err

err的IO定义于,err的定义

event

系统事件定义,及调度函数

其他

一些通用的数据结构定义

例如

  • 几种常见的锁
  • NodeList
  • mux
  • 系统类型
  • 队列
  • 进程结构

Socket编程实践(二)

Socket编程实践(二)

最近新任务,需要写一个Socket服务端,用来接收设备透传数据

考虑以下几点

  1. 设备规模(300~2000)
  2. 链接方式(长连接)
  3. 文本协议未定
  4. 有持久化需求
  5. 有前端控制页面

方案选型

  • 因为涉及有持久化需求,应该都是数据库相关操作,直接使用SpringBoot套件
  • 因为有前端控制需求,直接添加SpringMVC作为控制面板开发套件
  • 因为设备规模仅有2000个且是长连接,直接使用BIO协议开发效率更高(更推荐Netty来做开发模型,可惜不太熟悉)

类设计

以下三个类代表了领域模型核心,其他功能均基于以下三个对象做开发或辅助

Device

代表了具体的一个设备

  1. 设备验证与登录
  2. 设备状态维护
  3. 设备数据接收
  4. 设备数据维护与持久化

DevicePool

代表了设备们的管理功能,如

  1. 监测在线
  2. 监测是否有数据到达
  3. 设备上线下线处理

Waitress

代表了SocketServer接待处

仅用来分发接收到的socket然后交给线程池就不管事了