我的latex工作流 继WSL/gWSL技术使得”windows成为最好的Linux发行版“之后， 加上overleaf也是运行在linux里面的， 我发现我们的latex工作流完全可以全部迁移到*nix系统之中了。 这样的好处是我可以统一用linux的一些规范，避免一些不同系统带来的问题。 LATEX安装教程 我遇到过的错误 找不到字体STIX TWO MATH ubuntu里面可以直接用sudo apt install fonts-stix安装stix，但是它和所需的不一样。 stix2字体下载地址: 我用的ttf格式 Linux 安装字体
GIT # 设置http: git config --global http.proxy http://127.0.0.1:1080 # 设置https: git config --global https.proxy http://127.0.0.1:1080 # 设置socks: git config --global http.proxy 'socks5://127.0.0.1:1080' git config --global https.proxy 'socks5://127.0.0.1:1080' ## 取消 git config --global --unset http.proxy git config --global --unset https.proxy 或者通过git config --global -e编辑配置文件 [https "https://github.com"] proxy = socks5://127.0.0.1:7891
该内容似乎已经过时，因为目前似乎github.com.cnpmjs.org 和 hub.fastgit.org 镜像均无法使用 windows 系统安装 Scoop 包管理工具 https://scoop.sh/是一款 windows 系统下的包管理工具，根据官网只需要以下命令即可安装。 iwr -useb get.scoop.sh | iex #Note: if you get an error you might need to change the execution policy (i.e. enable Powershell) with Set-ExecutionPolicy RemoteSigned -scope CurrentUser 实际使用中，通常需要镜像加速以及修改安装位置，所以结合文章Windows 下 Scoop 安装、配置与使用，在此，我记录一下我的安装过程。 安装 SCOOP 由于我的 C 盘空间有限，可以修改安装位置我将目标目录修改为 #将Scoop安装到自定义目录(命令行方式),默认为C:\Users<user>\scoop $env:SCOOP='D:\Applications\Scoop' [Environment]::SetEnvironmentVariable('SCOOP', $env:SCOOP, 'User') #将Scoop配置为将全局程序安装到自定义目录 SCOOP_GLOBAL(命令行方式),默认为C:\ProgramData\scoop $env:SCOOP_GLOBAL='D:\Applications\GlobalScoopApps' [Environment]::SetEnvironmentVariable('SCOOP_GLOBAL', $env:SCOOP_GLOBAL, 'Machine') 我的网络质量不佳，无法直接使用iwr -useb get.scoop.sh | iex安装，可以借助镜像，来实现安装，下面的脚本会自动替换掉安装脚本中的 github 的链接。 #可能需要通过下面的命令设置权限之后再安装 Set-ExecutionPolicy RemoteSigned -scope CurrentUser #iwr -useb get.scoop.sh | iex #网络慢可以使用下面替换为cnpm和fastgit的链接 iwr -useb https://raw.fastgit.org/ScoopInstaller/Scoop/master/bin/install.ps1 | %{$_.Content.replace("github.com","github.com.cnpmjs.org").replace("raw.githubusercontent.com","raw.fastgit.org") | iex 上面这个命令应该可以正常安装 scoop 程序，但是当需要使用 scoop 安装其他程序时可能会出现问题， 可以手动将文件$env:SCOOP\apps\scoop\current\lib\manifest.ps1中读取 json 文件的命令(如下 👇🏻 第一条命令) 替换为下面的第二条命令，从而实现自动替换掉 github 链接。 ...
控制相关资源导航 图文（为主）博主 J Pan 航空工程师，主要在知乎撰写文章，有纲举目张 知乎: J Pan 系统与控制 目前发表或完成相关论文 6 篇，主要研究方向为多智能体系统与复杂网络，业余时间运营知乎网“系统与控制”账号，在国内外相关学者的合作下完成《控制理论结构图》系列工作，整理完成《自动化学科科普手册》系列版本 知乎：系统与控制 主页：https://qdu-zdh.github.io/qdu-zlh/ 推特：System control 视频（为主）博主 DR_CAN Ph.D. in Dynamics and Control 机器人工程师 B 站：DR_CAN Brian Douglas youtube：Brian Douglas 网站：https://engineeringmedia.com/ 另外也推荐matlab 思维导图 The Map of Control Theory The Map of Control Theory是 Brian Douglas 绘制的控制领域思维导图。 控制理论结构图 系统与控制博主绘制了控制领域的常用技术概览，包括多张图。发布在 medium.com、 twitter、 github 等多个平台上。 其中比较著名的有Map of Multi-Agent Control
Some Tips for git links git commit 提交规范 Conventional Commits 约定式提交: 本文 gitmoji 使用表情来规范 commit 消息: one fork LGTM : code review 行话:本文 Tip1: Commit 规范中常用 commit 类型解释 feat: 新功能、新特性 fix: 修改 bug perf: 更改代码，以提高性能（在不影响代码内部行为的前提下，对程序性能进行优化） refactor: 代码重构（重构，在不影响代码内部行为、功能下的代码修改） docs: 文档修改 style: 代码格式修改, 注意不是 css 修改（例如分号修改） test: 测试用例新增、修改 build: 影响项目构建或依赖项修改 revert: 恢复上一次提交 ci: 持续集成相关文件修改 chore: 其他修改（不在上述类型中的修改） release: 发布新版本 workflow: 工作流相关文件修改 typo：拼写错误等小错误 Tip2：code Review 行话 PR: Pull Request. 拉取请求，给其他项目提交代码 LGTM: Looks Good To Me. 朕知道了 代码已经过 review，可以合并 SGTM: Sounds Good To Me. 和上面那句意思差不多，也是已经通过了 review 的意思 WIP: Work In Progress. 传说中提 PR 的最佳实践是，如果你有个改动很大的 PR，可以在写了一部分的情况下先提交，但是在标题里写- `上 WIP，以告诉项目维护者这个功能还未完成，方便维护者提前 review 部分提交的代码。 PTAL: Please Take A Look. 你来瞅瞅？用来提示别人来看一下 TBR: To Be Reviewed. 提示维护者进行 review TL;DR: Too Long; Didn’t Read. 太长懒得看。也有很多文档在做简略描述之前会写这么一句 TBD: To Be Done(or Defined/Discussed/Decided/Determined).根据语境不同意义有所区别，但一般都是还没搞定的意思 Tips3: 一些个人感悟 变量名直观一点，不要害怕太长 人类创造编程语言，就是为了方便人类编写与理解，大部分语言编译器都会做相关的优化的 git 仓库也真的不在乎多那么几个字节，github 大小也没有限制，浅克隆问题也不大 主分支不用，其他分支少用git push -f，提交历史没有必要太好看 同上 2，多几个 commit 没什么大不了的 个人项目单分支模型就可以了，用太多分支往往徒增烦恼（这条不绝对，要看具体情况）