程序练习生

文章目录

    • 待补充
    • Linux使用记录
      • 删除软链接时切记注意
      • 软件包
    • Git, GitHub使用记录
      • 初识Git, GitHub
        • Step 1, 安装Git
        • Step 2, 创建1个本地仓库
        • Step 3, 在PyCharm中执行commit操作
      • GitHub项目协作中的pull, push
      • git clone命令
    • 深度学习工作站
    • 远程控制
    • 问题记录
      • 在PyCharm中安装依赖包
      • PyCharm Debug
    • API documentation
      • What is API documentation?
      • Three Types of API Documentation
      • Best REST API Documentation
    • 待补充
      • 待补充
    • 分割线
    • 分割线

  本文档用于日程记录与编程相关的杂货;

待补充

notepad++精美主题&字体 - longzhankunlun - 博客园 20190522

Linux使用记录

删除软链接时切记注意

  假定lnName是一个软链接,
  rm -rf lnName/这个最后带了斜杠的命令会删除软链接所链接的真实目录,而不是删除软链接其本身;
  rm -rf lnName这个最后不带斜杠的命令才会删除软链接其本身;

  • ** 记一次删除软连接的惊魂之旅(rm -rf、删库跑路)_小崔的专栏 20200327
  • rm -rf 删除软连接,血的教训==! - charleychan - 博客园20200729

软件包

  • *** Ubuntu 系统 dpkg 命令使用详解 - 云+社区 - 腾讯云20190812
  • *** dpkg命令_Linux dpkg 命令用法详解:Debian Linux系统上安装、创建和管理软件包
  • Linux进阶之软件管理 - Wolf_Coder - 博客园20190719
  • Ubuntu的软件安装管理—dpkg与apt-*详解 - 心田居士 - 博客园20190622
  • linux下彻底删除软件及配置文件_Little Garden-CSDN博客_yum remove 删除配置文件20180601

  可以使用pip intall xxxx.whl命令对下载下来的.whl库包文件进行安装
  终端操作时,如果路径名中有空格,需用“\ ”代替;

Git, GitHub使用记录

初识Git, GitHub

  • *** Git和Github详细入门教程_轻松玩编程 20200506

使用参考:

  • **** 通过pycharm使用git和github的步骤(图文详解) - 测试逍遥子 - 博客园 20200408
  • (待阅读) Git和GitHub操作详细教程_一千零一夜的博客 20190802
  • *** pycharm与github代码版本控制管理_白小狸-CSDN博客 20180311
  • git的add、commit、push的详细介绍 - 简书 20180920
  • Pycharm如何更新代码到Github? - 简书 20190126
    本博客主要内容包括:
    Q:在PyCharm中修改了代码之后,如何在PyCharm中操作将其同步到GitHub上,并带上commit message?
    A:其实很简单,就三步:修改代码,commit,push;
  • *** Git – 如何删除本地仓库_bloombud的博客 20180524

Step 1, 安装Git

  安装完 Git 之后,要做的第一件事就是设置你的用户名和邮件地址。 这一点很重要,因为每一个 Git 提交都会使用这些信息,它们会写入到你的每一次提交中,不可更改:

git config --global user.name "xxx"  # 设置用户名
git config --global user.email "[email protected]"  # 设置用户邮箱
git config --list  # 检查配置信息

lu@Lenovo-PC MINGW64 /e/WorkSpace/Server_WorkSpace
$ git status
fatal: not a git repository (or any of the parent directories): .git

# mkdir tutorial  # 在当前路径下创建一个文件夹, 用于后续创建一个repository
# cd tutorial/
# git --version
# git status  # 查看当前工作状态
# git init  # Git仓库的初始化, 创建了一个repository
记录一些git相关命令
git status
# git add . 添加当前路径下的所有文件到缓存区
git add xxx.py yyy.py # 添加一个或多个文件到缓存区
git status
git commit -m "First initial commit"  # 提交至Git本地版仓库,并附上提交描述
git status

# 在GitHub上create a new repository
# set a new remote
git remote add origin https://github.com/user/repo.git
# verify new remote
git remote -v
> origin https://github.com/user/repo.git (fetch)
> origin https://github.com/user/repo.git (push)
git branch  # 查看分支
git push origin master  # 提交到远程仓库

Step 2, 创建1个本地仓库

  此前,在PyCharm中由于"File | Open… | Open File or Project"选中的是"OpenSourcePlatform"文件夹,因此通过"VCS | Enable Version Control Integration"来初始化Git仓库,会在当前的项目路径Server_WorkSpace/OpenSourcePlatform下创建一个名为.git的子目录,而我期望的是对Server_WorkSpace/OpenSourcePlatform/mmdetection进行版本控制,故需要先删除已经创建的本地仓库OpenSourcePlatform,才能在Server_WorkSpace/OpenSourcePlatform/mmdetection路径下创建本地仓库mmdetection;
  此时,创建本地仓库mmdetection,有两种方式:
  方式一:在Git Bash中,通过执行cd /e/WorkSpace/Server_WorkSpace/OpenSourcePlatform/mmdetectiongit init命令,创建一个名为.git的子目录;
  方式二:在PyCharm中"File | Open… | Open File or Project"选中mmdetection,通过"VCS | Enable Version Control Integration"操作。如果此前 在当前的项目路径Server_WorkSpace/OpenSourcePlatform/mmdetection下没有一个名为.git的子目录,则该操作会在当前的项目路径Server_WorkSpace/OpenSourcePlatform/mmdetection下创建一个名为.git的子目录;如果此前 在当前的项目路径Server_WorkSpace/OpenSourcePlatform/mmdetection下已经存在一个名为.git的子目录,则该操作启用了版本控制集成功能;

程序练习生_第1张图片
MMDet_初始化Git仓库.jpg
程序练习生_第2张图片
MMDet_Deployment_Configuration_Connection设置.jpg
程序练习生_第3张图片
MMDet_Deployment_Configuration_Mappings设置.jpg
程序练习生_第4张图片
MMDet_Deployment_Configuration_Excluded Paths设置.jpg
程序练习生_第5张图片
MMDet_VCS_Enable Version Control Integration之前.jpg
程序练习生_第6张图片
MMDet_VCS_Enable Version Control Integration设置.jpg
程序练习生_第7张图片
MMDet_VCS_Enable Version Control Integration之后.jpg

Step 3, 在PyCharm中执行commit操作

MMDet_Deployment_Configuration_Connection设置.jpg
MMDet_Deployment_Configuration_Mappings设置.jpg
MMDet_Deployment_Configuration_Excluded Paths设置.jpg
MMDet_初始化Git仓库.jpg
MMDet_VCS_Enable Version Control Integration之前.jpg  # File | Settings | Version Control | Directory设置-->Apply
MMDet_VCS_Enable Version Control Integration设置.jpg
在执行"VCS | Enable Version Control Integration"操作之前,此处显示的是"Unregistered roots";
MMDet_VCS_Enable Version Control Integration之后.jpg
在执行"VCS | Enable Version Control Integration"操作之后,此处不再显示"Unregistered roots";
MMDet_VCS_执行首次commit操作001.jpg
# 红色,表示在工作区;
# 绿色,表示在暂存区;
# 蓝色,表示文件有修改,位于暂存区;
# 文件名无颜色,表示文件位于本地仓库区或已经提交到远程仓库区;
MMDet_VCS_执行首次commit操作002.jpg  # 勾选了所有文件,并附上提交描述"the initial project version"
MMDet_VCS_执行首次commit操作003.jpg  # 执行commit操作时出现的1个弹窗提示,看来当时应该取消勾选"Check TODO";对于该弹窗提示,点击"Commit";
MMDet_VCS_执行首次commit操作004.jpg  # 文件commit之后,文件的颜色变成了无颜色;修改了此文件后,此文件的颜色变成了蓝色;
程序练习生_第8张图片
MMDet_VCS_执行首次commit操作001.jpg
程序练习生_第9张图片
MMDet_VCS_执行首次commit操作002.jpg
程序练习生_第10张图片
MMDet_VCS_执行首次commit操作003.jpg
程序练习生_第11张图片
MMDet_VCS_执行首次commit操作004.jpg

GitHub项目协作中的pull, push

  PR是Pull Request缩写,Git/svn之类用的。比如GitHub上的项目,你pull下来,修改了部分代码之后再提交PR,然后管理员觉得你改的代码没毛病,管理员确认之后,这个项目某部分代码就改成你的了;在GitLab中,MR(Merge Request)好像是类似的意思;

  团队合作的时候,由于远程端的更改多余你的本地端,你应该 先pull 然后合并远程端后 再push。如果直接强制push会让远程端的代码跟你本地的保持一致,远程端多的部分就不见了。

  CRLF line separators CRLF行分隔符
  CRLF abbr. 回车换行符(carriage return/line feed)
  expand upon详细叙述
  expand up展开,扩大

git clone命令

  git clone https://github.com/user/repo_name.git之前会在当前目录下创建一个文件夹,名字就是项目的名字repo_name。然后 git 会先拉取元信息,放在.git 这个目录里;然后拉取对应的object,同样放在.git 里;最后根据元信息和 obj这些信息建立整个代码。在最后一步开始之前终止,相当于所有拉取的东西都在.git 里。如果git clone中途终止,直接删掉.git这个文件夹重新拉取就行,看样子你是 clone 不是 pull,讲道理可以把第一步创建的项目文件夹repo_name直接删除,不影响什么。
  一般情况下,git clone传输失败都会自动删除临时文件的,存储库目录也会被自动删除的。

  • git clone 了一半,主动终止了, clone 了的几百兆数据到哪去了,需要清除吗 - V2EX 20170723
  • Github下载速度慢 提升github下载速度最新解决方案_杀手的博客20200725

深度学习工作站

  • *** 深度学习工作站配置推荐 - 简书20181203
  • 如何配置一台适用于深度学习的工作站? - 量子位的回答 -
    知乎20190529

Geforce GPU 显存(GPU RAM) > 6 GB

远程控制

  • Ubuntu16 安装向日葵远程控制软件_诗酒lp的博客-CSDN博客_ubuntu安装向日葵远程控制20191219
  • 向日葵远程控制软件_app下载_视频监控软件_远程开机软件下载-Oray贝锐科技向日葵
    企业用户 控制端 for Windows_V 5.0.0.29520(2020.05)
    个人用户 向日葵 X for Windows_V 10.5.0.29613(2020.05)

问题记录

问题描述
  开始
原因分析:
  开始
解决方案:
  开始

在PyCharm中安装依赖包

问题描述
  Python Console中的python环境。
原因分析:
  通过PyCharm自带的Terminal进入的python环境 和 Python Console中的python环境 是不同的,得看它们各自使用的是哪条路径下的python.exe解释器。
  创建一个PyCharm项目时,可以根据需要自行选择确定“Project Interpreter”,以避免相关依赖包的版本冲突。
解决方案:
  在PyCharm中安装依赖包时可以采用以下方式:a.进入"File | Settings | Project Interpreter"里面,点击右边“+”号,搜索“Available Packages”并安装;b.在PyCharm自带的Terminal中,使用命令安装;

PyCharm Debug

问题描述
  PyCharm中,Debug模式下,Debugger | Variables无法显示"frame variables",Console | Show Python Prompt也无法打印输出"frame variables"的相关信息。
原因分析:
  无
解决方案:
  在PyCharm中打开File | Settings | Build, Execution, Deployment | Python Debugger, 勾选Gevent compatible;
debugging - Why does PyCharm say “Unable to display frame variables” in debug mode? - Stack Overflow 20161129
程序练习生_第12张图片

PyCharm_debug_Unable to display frame variables_20200813.jpg

API documentation

API Documentation Guide | Simple API Documentation & APIs Document Tutorials

What is API documentation?

  API docs, or API description documents, are the collection of references, tutorials, and examples that help developers use your API.
  Your API’s documentation is the primary resource for explaining what is possible with your API and how to get started. It also serves as a place for developers to return with questions about syntax or functionality. The best API docs have these answers hence why it is so important to document your API.

Three Types of API Documentation

  Your API documentation will have several types of content. Some is meant to show what’s possible to a developer considering an integration. Others will get those developers started quickly. And yet, good & simple API documentation should remain useful when that developer is deep into their work.
  Your documentation must completely describe the API’s functionality, be accurate, educational, and inspire usage. It’s a big job that can roughly be broken down into three types:

  • Reference and functionality
  • Guides and tutorials
  • Examples and use cases

  We’ll discuss these in detail, but you can think of them as moving on a continuum of facts to context. A reference describes the endpoints of an API, it lays out all the pieces. Guides take some of those pieces and start to put them together, explaining why you’d use those parts. Finally, examples offer up a very specific solution, solving a common problem.
  As you’ll see, the best API documentation nails all three of these types of content.

Best REST API Documentation

  Now that we know what types of documentation to look for, let’s look at some examples of great REST API documentation. For many years, two names continue to come up when discussing API docs: Stripe and Twilio.
  Stripe’s API reference, Twilio’s guides, Heroku’s examples;
  One of the most important jobs of documentation is to help someone completely unfamiliar with your API. At the same time, you want it to remain useful for the developer who has already used your API. Of the three types of documentation, the reference most needs to remain relevant throughout a developer’s interaction with your API.

待补充

  

待补充

  



文字居中

数学公式粗体 \textbf{} 或者 m e m o r y {\bf memory} memory
数学公式粗斜体 \bm{}

摘录自“bookname_author”
此文系转载,原文链接:名称 20200505

高亮颜色说明:突出重点
个人觉得,:待核准个人观点是否有误

分割线

分割线


我是颜色为00ffff的字体
我是字号为2的字体
我是颜色为00ffff, 字号为2的字体
我是字体类型为微软雅黑, 颜色为00ffff, 字号为2的字体

分割线

分割线
问题描述:
原因分析:
解决方案:

你可能感兴趣的:(Python相关)