问题描述 某机床厂生产甲、乙两种机床，每台销售后的利润分别为 4000 元与 3000 元。 生产甲机床需用 A、 B机器加工，加工时间分别为每台 2 小时和 1 小时；生产乙机床需用A 、B、C三种机器加工，加工时间为每台各一小时。若每天可用于加工的机器时数分别为 A机器 10 小时、B 机器 8 小时和C 机器 7 小时。问该厂应生产甲、乙机床各几台，才能使总利润最大？ 数学建模 设该厂生产x1x_1x1​台甲机床，生产x2x_2x2​台乙机床，获得总利润zzz， 生产甲机床需要使用A机器2x12x_12x1​小时，生产乙机床需要使用A机器x2x_2x2​小时，每天A机器使用时长不得超过10小时，故得到约束条件2x1+x2≤102x_1+x_2 \leq 102x1​+x2​≤10 生产甲机床需要使用B机器x1x_1x1​小时，生产乙机床需要使用B机器x2x_2x2​小时，每天B机器使用时长不得超过8小时，故得到约束条件x1+x2≤8x_1+x_2 \leq 8x1​+x2​≤8 生产甲机床不使用C机器，生产乙机床需要使用C机器x2x_2x2​小时，每天C机器使用时长不 ...

之前更换系统后，博客一直就没有继续更新了，今日重新clone下来，顺利地yarn install之后，执行yarn server时发生错误 pandoc exited with code null. 问题描述 详细输出如下， 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253zzq@ThinkPad-zzq:~/code/repo/blog$ hexo serverINFO Validating configINFO ================================== ███╗ ██╗███████╗██╗ ██╗████████╗ ████╗ ██║██╔════╝╚██╗██╔╝╚══██╔══╝ ██╔██╗ ██║█████╗ ╚███╔╝ ██║ ██║╚██╗██║██╔══╝ ██╔██╗ ██║ ██║ ╚████║███████╗██╔╝ ██╗ ██║ ╚ ...

抽象工厂模式案例解析 场景模拟 原本我的服务使用的是单机Redis，现在想要升级到Redis集群。 服务需要同时兼容不同种类的Redis集群，便于后期的灾备。 而不同Redis服务提供的接口各有不同，需要手动做适配抽象出来。 不能影响到目前正常运行的系统。 模拟单机Redis 12345678910111213141516171819202122232425262728293031323334package cn.zzq.redis;import cn.zzq.util.Logger;import java.util.Map;import java.util.concurrent.ConcurrentHashMap;import java.util.concurrent.TimeUnit;/** * 本类模拟了Redis单机服务，仅供模拟Redis使用 */public class RedisUtils { private final Logger logger = new Logger(RedisUtils.class); private final Ma ...

Hibernate 的基本使用 数据表定义如下： 12345create table employee( employee_id integer, name text, salary numeric,); 如下图，建立 Maven 项目工程 resources 资源文件夹下创建 hibernate.cfg.xml 的 Hibernate 配置文件 创建 Employee.hbm.xml 的 Hibernate 映射文件 创建 POJO 类 Employee 为 Employee.hbm.xml 的映射类 添加 Maven 依赖如下 12345678910111213141516<dependencies> <!-- hibernate--> <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-agroal</artifactId> ...

Smach 是一个相当好用的 ros 上的基于状态机的任务级调度框架，但是在 ubuntu20.04 上能够运行 smach 核心程序但是却无法运行 smach_viewer 去调试状态机，解决方法之一是可以通过 ros 分布式通信机制和另一台 ubuntu18.04 的 melodic 机器建立分布式通讯，在 ubuntu18.04 上运行 smach_viewer 去调试状态机。或者也可以通过虚拟机代替 ubuntu18.04 的实体机。还有一种解决方案就是将上述虚拟机更换为更轻量级的 docker 容器。 smach 的作者在 github 的一篇 issue 上回答如下， For reference: I’m using ROS Noetic and SMACH visualization is something I wanted to have to display the current state of my FSM for easy introspection and bling. I could not update it to work in Noetic fo ...

出现该问题的原因是因为Ctrl+5为Fcitx重新载入配置的全局快捷键，删除该快捷键即可。

自上而下的语法分析 面临的问题 文法左递归 一个文法是含有左递归的，如果存在非终结符P P→PαP\to P\alpha P→Pα 当产生左递归时，词法分析流没有向前进行任何的推进，而语法树却在不断地进行扩展，此时会使得分析器陷入死循环，故需要避免左递归。 回溯问题 每一步的语法分析，都面临这多个侯选式的选取问题，分析过程中，当一个非终结符用某个候选匹配成功时，这种匹配只是暂时的，当下一步出错时且无路可选时，不得不进行“回溯”操作，而这种回溯操作需要恢复先前的分析结果比较消耗性能。 构造不带回溯的自上而下的分析算法 消除文法左递归 直接左递归消除 P→Pα∣βP\to P\alpha|\betaP→Pα∣β 其中α、β∈(VT∪VN)∗\alpha、\beta\in(V_T\cup V_N)^*α、β∈(VT​∪VN​)∗，β\betaβ不以A打头 则可改写为如下右递归形式 P→βP′P\to\beta P'P→βP′ P′→αP′∣εP'\to \alpha P'|\varepsilonP′→αP′∣ε 推广 假定关于P的全部产生式 ...

LL(1)文法 构造一个不带回溯的自上而下分析的文法条件 文法不含左递归 对于文法中每一个非终结符 A 的各个产生式的候选首符集两两不相交。即，若 A→α1∣α2∣...∣αnA\to \alpha_1|\alpha_2|...|\alpha_n A→α1​∣α2​∣...∣αn​ 则FIRST(αi)∩FIRST(αj)=ϕ(i≠j)FIRST(\alpha_i)\cap FIRST(\alpha_j)=\phi (i\neq j)FIRST(αi​)∩FIRST(αj​)=ϕ(i​=j) 对文法中的每个非终结符 A，若它存在某个候选首符集包含ε\varepsilonε，则 FIRST(αi)∩FOLLOW(A)=ϕi=1,2,3,...,nFIRST(\alpha_i)\cap FOLLOW(A) = \phi \newline i = 1,2,3,...,n FIRST(αi​)∩FOLLOW(A)=ϕi=1,2,3,...,n 如果一个文法 G 满足以上条件，则称该文法 G 为 LL(1)文法。

​ 这段时间，我读了一本书《轻松Scrum之旅》，这是一本小说般的一本技术书籍，作者使用了小说的形式来介绍Scrum的基本概念，并且使用了一个完整的项目来向读者呈现出书中的主人公关毅在实行Scrum框架中遇到的各种问题以及解决思路，使读者产生更加感性的认识。 ​ 在传统的瀑布模型中，我们需要按部就班完成从需求分析，软件设计，编码实现，软件测试到软件交付与维护等一系列步骤，一般前一个步骤完成不了后一个步骤就无法推进，而这层层推进需要对文档有着很强的依赖，然而软件开发中变数太多，有时经常会遇到客户的需求发生变更等异常情况，所以提前预测变得相当困难，故如今瀑布模式的软件开发已经不适用了，现在比较流行的软件开发方法就是敏捷开发(Agile)。 敏捷宣言 对于敏捷开发宣言中的每一项，我的理解如下： 个体和交互胜于过程和工具，这句话强调以人为本。 可以工作的软件胜于面面俱到的文档，这句话强调了文档的地位在敏捷开发中的地位被削弱，每个环节的沟通一般采用最有效的方式沟通，即面对面的交流，能产出能用的产品才是重要的。 客户合作胜于合同谈判，这一点强调了敏捷开发中，客户不能像订购日用品 ...

敏捷开发Scrum开发模式 Scrum与传统瀑布模式开发的区别 Plan 瀑布模式开发通常要花几个月时间来规划产品 Build 再花几个月时间研发产品 Test & Review 接着进行产品的测试与评审 Deploy 最后发布产品 ​ 瀑布模式的重点在于要求每个活动的结果都必须经过验证，并且只有经过验证之后才能作为后续开发的基础，这使得瀑布模型特别重视模型与文档，因为这是在可执行代码产生之前唯一能够用来验证的东西，所以瀑布模型被看做是“文档驱动”的，即按照文档的划分、产生和验证来规划、组织和控制开发活动。 ​ 如果市场需求或技术环境发生了变化，那么此时研发出的产品很可能无法满足市场需求，瀑布模式的开发在遇到这种变化时会出现很多问题。 ​ 首先，产品规划必须早于后续工作之前完成，在绝大多数案例中，规划环节结束时，并没有完全理解项目，但研发工作已经完成了。通常情况下，整个项目必须送回规划阶段，然后从头再来，否则研发人员就会因为不明白产品规划而受到批评。这种情况会反复出现，比如研发完成后，进行产品测试，发现问题就要重新开发，有时甚至需要重新规划产品。 ​ 同理， ...