Gepostet vor 2023-04-14Aktualisiert vor 2023-04-14Linuxa minute lesen (Über 155 Wörter)

MKOnlinePlayer搭建在线音乐播放器

地址：https://github.com/mengkunsoft/MKOnlineMusicPlayer

搭建环境：php7.2.11，httpd，mysql8.0.17

遇到的问题：

1	undefined function json_decode()

解决办法：

centos:

1	sudo yum install php-pecl-json

ubuntu

1	sudo aptitude install php5-json

音乐搜索神器

地址：https://github.com/maicong/music

搭建环境：php5.4.16 httpd

在线Json解析

地址：https://github.com/bimohxh/jsonon

ZFile(文件管理系统)

地址：https://docs.zfile.vip/#/

搭建自己的服务

appwrite

laf

supabase

使用wordPress + WebStack搭建导航网站

wordPress
WebStack

Gepostet vor 2023-04-14Aktualisiert vor 2023-04-14DIY3 minutes lesen (Über 457 Wörter)

自己动手搭建RustDesk服务器

公司从去年开始需要打卡了，为了不受制度约束，本人开始着手寻找技术（偷懒）方案。刚开始在手机上使用企业微信+模拟定位App（有广告）能正常实现远程打卡，一段时间后，发现模拟定位在企微上不生效了（怀疑是企微屏蔽了模拟定位）。为了能找到一劳永逸的方法，便开始寻找能远程控制手机的程序，最终选择了RustDesk

使用一段时间后发现连接不太稳定，查询官网了解到默认服务器架设在国外，但是提供自建服务器的方法。

搭建服务器需要准备的步骤：

（1）自有服务器（本人使用的是阿里云最低配置（1核2G））

（2）服务器软件下载链接（按需下载）

（3）开放21115/21116/21117/21118/21119（TCP）端口）和21116（UDP）端口，使用firewall-cmd --list-ports查看开放的端口

21115 是hbbs用作NAT类型测试
21116 UDP是hbbs用作ID注册与心跳服务
21116 TCP是hbbs用作TCP打洞与连接服务
21117 是hbbr用作中继服务
21118和21119是为了支持网页客户端。如果您不需要网页客户端（21118，21119）支持，对应端口可以不开。

（4）安装运行环境（推荐使用pm2），安装命令如下

1 2	yum install npm npm install pm2

启动运行

1 2	pm2 start hbbs -- -r <your ip here> -k _ pm2 start hbbr

使用中遇到的问题

（1）No route to host (os error 113)

该提示说明防火墙端口未开放访问

（2）No route to host (os error 111)

该提示说明服务未启动

Gepostet vor 2023-04-14Aktualisiert vor 2023-04-21学习3 minutes lesen (Über 469 Wörter)

大牛的经验

当你面对做不到的需求时，你不要说这个需求做不到。尤其是，你不要马上说做不到，你要先想一下，这样让别人觉得你是想做的，但是，在认真思考过后，你觉得做不到，并
且给出一个你觉得做得到的方案。这里的诀窍是—— 给出另一个你可以做到的方案，而不是把对方的方案直接回绝掉。
当你面对过于复杂的需求时，你不要说不。你要反问一下，为什么要这样做？这样做的目的是什么？当了解完目的以后，你可以给出一个自己的方案，或是和对方讨论一个性价
比更好的方案。你可以回复说，这个需求好复杂，我们能不能先干这个，再做那个，这样会更经济一些。这里的诀窍是—— 我不说我不能完全满足你，但我说我可以部分满足你。
当你面对时间完全不够的需求时，你也不要说不。既然对方把压力给你，你要想办法把这个压力还回去，或是让对方来和你一同分担这个压力

惯用的方式是给回三个选择：

a. 我可以加班加点完成，但是我不保证好的质量，有 bug 你得认，而且事后你要给我 1 个月的时间还债。

b. 我可以加班加点，还能保证质量，但我没办法完成这么多需求，能不能减少一些？

c. 我可以保质保量地完成所有的需求，但是，能不能多给我 2 周时间

Gepostet vor 2023-04-14Aktualisiert vor 2023-04-21学习26 minutes lesen (Über 3879 Wörter)

技术专家方法论

一个复杂业务的处理过程

业务背景

简单的介绍下业务背景，零售通是给线下小店供货的B2B模式，我们希望通过数字化重构传统供应链渠道，提升供应链效率，为新零售助力。阿里在中间是一个平台角色，提供的是Bsbc中的service的功能。

图片

商品力是零售通的核心所在，一个商品在零售通的生命周期如下图所示：

图片

在上图中红框标识的是一个运营操作的“上架”动作，这是非常关键的业务操作。上架之后，商品就能在零售通上面对小店进行销售了。因为上架操作非常关键，所以也是商品域中最复杂的业务之一，涉及很多的数据校验和关联操作。
针对上架，一个简化的业务流程如下所示：

图片

过程分解

像这么复杂的业务，我想应该没有人会写在一个service方法中吧。一个类解决不了，那就分治吧。

说实话，能想到分而治之的工程师，已经做的不错了，至少比没有分治思维要好很多。我也见过复杂程度相当的业务，连分解都没有，就是一堆方法和类的堆砌。

不过，这里存在一个问题：即很多同学过度的依赖工具或是辅助手段来实现分解。比如在我们的商品域中，类似的分解手段至少有3套以上，有自制的流程引擎，有依赖于数据库配置的流程处理：

图片

本质上来讲，这些辅助手段做的都是一个pipeline的处理流程，没有其它。因此，我建议此处最好保持KISS（Keep It Simple and Stupid），即最好是什么工具都不要用，次之是用一个极简的Pipeline模式，最差是使用像流程引擎这样的重方法。

除非你的应用有极强的流程可视化和编排的诉求，否则我非常不推荐使用流程引擎等工具。第一，它会引入额外的复杂度，特别是那些需要持久化状态的流程引擎；第二，它会割裂代码，导致阅读代码的不顺畅。大胆断言一下，全天下估计80%对流程引擎的使用都是得不偿失的。

回到商品上架的问题，这里问题核心是工具吗？是设计模式带来的代码灵活性吗？显然不是，问题的核心应该是如何分解问题和抽象问题，知道金字塔原理的应该知道，此处，我们可以使用结构化分解将问题解构成一个有层级的金字塔结构：

图片

按照这种分解写的代码，就像一本书，目录和内容清晰明了。

以商品上架为例，程序的入口是一个上架命令（OnSaleCommand）, 它由三个阶段（Phase）组成。

@Command
public class OnSaleNormalItemCmdExe {

@Resource
private OnSaleContextInitPhase onSaleContextInitPhase;
@Resource
private OnSaleDataCheckPhase onSaleDataCheckPhase;
@Resource
private OnSaleProcessPhase onSaleProcessPhase;

@Override
public Response execute(OnSaleNormalItemCmd cmd) {

    OnSaleContext onSaleContext = init(cmd);

    checkData(onSaleContext);

    process(onSaleContext);

    return Response.buildSuccess();
}

private OnSaleContext init(OnSaleNormalItemCmd cmd) {
    return onSaleContextInitPhase.init(cmd);
}

private void checkData(OnSaleContext onSaleContext) {
    onSaleDataCheckPhase.check(onSaleContext);
}

private void process(OnSaleContext onSaleContext) {
    onSaleProcessPhase.process(onSaleContext);
}

}

每个Phase又可以拆解成多个步骤（Step），以OnSaleProcessPhase为例，它是由一系列Step组成的：

@Phase
public class OnSaleProcessPhase {

@Resource
private PublishOfferStep publishOfferStep;
@Resource
private BackOfferBindStep backOfferBindStep;
//省略其它step

public void process(OnSaleContext onSaleContext){
    SupplierItem supplierItem = onSaleContext.getSupplierItem();

    // 生成OfferGroupNo
    generateOfferGroupNo(supplierItem);

   // 发布商品
    publishOffer(supplierItem);

    // 前后端库存绑定 backoffer域
    bindBackOfferStock(supplierItem);

    // 同步库存路由 backoffer域
    syncStockRoute(supplierItem);

    // 设置虚拟商品拓展字段
    setVirtualProductExtension(supplierItem);

    // 发货保障打标 offer域
    markSendProtection(supplierItem);

    // 记录变更内容ChangeDetail
    recordChangeDetail(supplierItem);

    // 同步供货价到BackOffer
    syncSupplyPriceToBackOffer(supplierItem);

    // 如果是组合商品打标，写扩展信息
    setCombineProductExtension(supplierItem);

    // 去售罄标
    removeSellOutTag(offerId);

    // 发送领域事件
    fireDomainEvent(supplierItem);

    // 关闭关联的待办事项
    closeIssues(supplierItem);
}

}

看到了吗，这就是商品上架这个复杂业务的业务流程。需要流程引擎吗？不需要，需要设计模式支撑吗？也不需要。对于这种业务流程的表达，简单朴素的组合方法模式（Composed Method）是再合适不过的了。

因此，在做过程分解的时候，我建议工程师不要把太多精力放在工具上，放在设计模式带来的灵活性上。而是应该多花时间在对问题分析，结构化分解，最后通过合理的抽象，形成合适的阶段（Phase）和步骤（Step）上。

图片

过程分解后的两个问题

的确，使用过程分解之后的代码，已经比以前的代码更清晰、更容易维护了。不过，还有两个问题值得我们去关注一下：

★ 领域知识被割裂肢解

什么叫被肢解？因为我们到目前为止做的都是过程化拆解，导致没有一个聚合领域知识的地方。每个Use Case的代码只关心自己的处理流程，知识没有沉淀。

相同的业务逻辑会在多个Use Case中被重复实现，导致代码重复度高，即使有复用，最多也就是抽取一个util，代码对业务语义的表达能力很弱，从而影响代码的可读性和可理解性。

★ 代码的业务表达能力缺失

试想下，在过程式的代码中，所做的事情无外乎就是取数据–做计算–存数据，在这种情况下，要如何通过代码显性化的表达我们的业务呢？说实话，很难做到，因为我们缺失了模型，以及模型之间的关系。脱离模型的业务表达，是缺少韵律和灵魂的。

举个例子，在上架过程中，有一个校验是检查库存的，其中对于组合品（CombineBackOffer）其库存的处理会和普通品不一样。原来的代码是这么写的：

boolean isCombineProduct = supplierItem.getSign().isCombProductQuote();

// supplier.usc warehouse needn’t check
if (WarehouseTypeEnum.isAliWarehouse(supplierItem.getWarehouseType())) {
// quote warehosue check
if (CollectionUtil.isEmpty(supplierItem.getWarehouseIdList()) && !isCombineProduct) {
throw ExceptionFactory.makeFault(ServiceExceptionCode.SYSTEM_ERROR, “亲，不能发布Offer，请联系仓配运营人员，建立品仓关系！”);
}
// inventory amount check
Long sellableAmount = 0L;
if (!isCombineProduct) {
sellableAmount = normalBiz.acquireSellableAmount(supplierItem.getBackOfferId(), supplierItem.getWarehouseIdList());
} else {
//组套商品
OfferModel backOffer = backOfferQueryService.getBackOffer(supplierItem.getBackOfferId());
if (backOffer != null) {
sellableAmount = backOffer.getOffer().getTradeModel().getTradeCondition().getAmountOnSale();
}
}
if (sellableAmount < 1) {
throw ExceptionFactory.makeFault(ServiceExceptionCode.SYSTEM_ERROR, “亲，实仓库存必须大于0才能发布，请确认已补货.\r[id:” + supplierItem.getId() + “]”);
}
}

然而，如果我们在系统中引入领域模型之后，其代码会简化为如下：

if(backOffer.isCloudWarehouse()){
return;
}

if (backOffer.isNonInWarehouse()){
throw new BizException(“亲，不能发布Offer，请联系仓配运营人员，建立品仓关系！”);
}

if (backOffer.getStockAmount() < 1){
throw new BizException(“亲，实仓库存必须大于0才能发布，请确认已补货.\r[id:” + backOffer.getSupplierItem().getCspuCode() + “]”);
}

有没有发现，使用模型的表达要清晰易懂很多，而且也不需要做关于组合品的判断了，因为我们在系统中引入了更加贴近现实的对象模型（CombineBackOffer继承BackOffer），通过对象的多态可以消除我们代码中的大部分的if-else。

图片

过程分解+对象模型

通过上面的案例，我们可以看到有过程分解要好于没有分解，过程分解+对象模型要好于仅仅是过程分解。对于商品上架这个case，如果采用过程分解+对象模型的方式，最终我们会得到一个如下的系统结构：

图片

写复杂业务的方法论

通过上面案例的讲解，我想说，我已经交代了复杂业务代码要怎么写：即自上而下的结构化分解+自下而上的面向对象分析。

接下来，让我们把上面的案例进行进一步的提炼，形成一个可落地的方法论，从而可以泛化到更多的复杂业务场景。

上下结合

所谓上下结合，是指我们要结合自上而下的过程分解和自下而上的对象建模，螺旋式的构建我们的应用系统。这是一个动态的过程，两个步骤可以交替进行、也可以同时进行。

这两个步骤是相辅相成的，上面的分析可以帮助我们更好的理清模型之间的关系，而下面的模型表达可以提升我们代码的复用度和业务语义表达能力。

其过程如下图所示：

图片

使用这种上下结合的方式，我们就有可能在面对任何复杂的业务场景，都能写出干净整洁、易维护的代码。

能力下沉

一般来说实践DDD有两个过程：

★ 套概念阶段：了解了一些DDD的概念，然后在代码中“使用”Aggregation Root，Bounded Context，Repository等等这些概念。更进一步，也会使用一定的分层策略。然而这种做法一般对复杂度的治理并没有多大作用。

★ 融会贯通阶段：术语已经不再重要，理解DDD的本质是统一语言、边界划分和面向对象分析的方法。

大体上而言，我大概是在1.7的阶段，因为有一个问题一直在困扰我，就是哪些能力应该放在Domain层，是不是按照传统的做法，将所有的业务都收拢到Domain上，这样做合理吗？说实话，这个问题我一直没有想清楚。

因为在现实业务中，很多的功能都是用例特有的（Use case specific）的，如果“盲目”的使用Domain收拢业务并不见得能带来多大的益处。相反，这种收拢会导致Domain层的膨胀过厚，不够纯粹，反而会影响复用性和表达能力。

鉴于此，我最近的思考是我们应该采用能力下沉的策略。

所谓的能力下沉，是指我们不强求一次就能设计出Domain的能力，也不需要强制要求把所有的业务功能都放到Domain层，而是采用实用主义的态度，即只对那些需要在多个场景中需要被复用的能力进行抽象下沉，而不需要复用的，就暂时放在App层的Use Case里就好了。

注：Use Case是《架构整洁之道》里面的术语，简单理解就是响应一个Request的处理过程。

通过实践，我发现这种循序渐进的能力下沉策略，应该是一种更符合实际、更敏捷的方法。因为我们承认模型不是一次性设计出来的，而是迭代演化出来的。

下沉的过程如下图所示，假设两个use case中，我们发现uc1的step3和uc2的step1有类似的功能，我们就可以考虑让其下沉到Domain层，从而增加代码的复用性。

图片

指导下沉有两个关键指标：

复用性

内聚性

复用性是告诉我们When（什么时候该下沉了），即有重复代码的时候。内聚性是告诉我们How（要下沉到哪里），功能有没有内聚到恰当的实体上，有没有放到合适的层次上（因为Domain层的能力也是有两个层次的，一个是Domain Service这是相对比较粗的粒度，另一个是Domain的Model这个是最细粒度的复用）。

比如，在我们的商品域，经常需要判断一个商品是不是最小单位，是不是中包商品。像这种能力就非常有必要直接挂载在Model上。

public class CSPU {
private String code;
private String baseCode;
//省略其它属性

/**
 * 单品是否为最小单位。
 *
 */
public boolean isMinimumUnit(){
    return StringUtils.equals(code, baseCode);
}

/**
 * 针对中包的特殊处理
 *
 */
public boolean isMidPackage(){
    return StringUtils.equals(code, midPackageCode);
}

}

之前，因为老系统中没有领域模型，没有CSPU这个实体。你会发现像判断单品是否为最小单位的逻辑是以StringUtils.equals(code, baseCode)的形式散落在代码的各个角落。这种代码的可理解性是可想而知的，至少我在第一眼看到这个代码的时候，是完全不知道什么意思。

业务技术要怎么做

写到这里，我想顺便回答一下很多业务技术同学的困惑，也是我之前的困惑：即业务技术到底是在做业务，还是做技术？业务技术的技术性体现在哪里？

通过上面的案例，我们可以看到业务所面临的复杂性并不亚于底层技术，要想写好业务代码也不是一件容易的事情。业务技术和底层技术人员唯一的区别是他们所面临的问题域不一样。

业务技术面对的问题域变化更多、面对的人更加庞杂。而底层技术面对的问题域更加稳定、但对技术的要求更加深。比如，如果你需要去开发Pandora，你就要对Classloader有更加深入的了解才行。

但是，不管是业务技术还是底层技术人员，有一些思维和能力都是共通的。比如，分解问题的能力，抽象思维，结构化思维等等。

图片

用我的话说就是：“做不好业务开发的，也做不好技术底层开发，反之亦然。业务开发一点都不简单，只是我们很多人把它做“简单”了。

因此，如果从变化的角度来看，业务技术的难度一点不逊色于底层技术，其面临的挑战甚至更大。因此，我想对广大的从事业务技术开发的同学说：沉下心来，夯实自己的基础技术能力、OO能力、建模能力… 不断提升抽象思维、结构化思维、思辨思维… 持续学习精进，写好代码。我们可以在业务技术岗做的很”技术“！。

Gepostet vor 2022-10-24Aktualisiert vor 2024-09-05Android / 大纲a minute lesen (Über 184 Wörter)

Android学习大纲

Java并发

Java创建线程的三种方式

Java线程池

死锁

Synchronized/ReentrantLock

volatile关键字

CAS原子操作

AbstractQueuedSynchronizer详解

深入理解ReentrantLock

Java并发集合——ArrayBlockingQueue

Java并发集合——LinkedBlockingQueue

Java并发集合——ConcurrentHashMap

Java虚拟机

对象的创建、内存布局和访问定位

Java内存区域与内存模型

Java类加载机制及类加载器详解

JVM中垃圾收集算法及垃圾收集器详解

JVM怎么判断对象是否已死？

Android

Android基础

Activity全方位解析

Service全方位解析

BroadcastReceiver全方位解析

ContentProvider全方位解析

Fragment详解

Android消息机制

Android事件分发机制

AsyncTask详解

HandlerThread详解

IntentService详解

Gepostet vor 2022-10-24Aktualisiert vor 2024-09-05Android2 minutes lesen (Über 310 Wörter)

Android知识梳理目录

Java&Android 基础知识梳理(2) - 序列化

 Java&Android 基础知识梳理(3) - 内存区域

 Java&Android 基础知识梳理(4) - 垃圾收集器与内存分配策略

 Java&Android 基础知识梳理(5) - 类加载&对象实例化

2.7 状态栏

Android 状态栏知识点总结

六、多线程知识梳理

八、NDK 知识梳理

NDK 知识梳理(1) - 使用 CMake 进行 NDK 开发之初体验
 NDK 知识梳理(2) - 使用 CMake 进行 NDK 开发之如何编写 CMakeLists.txt 脚本