A

岛屿的周长 - 463. Island Perimeter

上周虽然拉跨了，但这周这个为啥一开始不对呢？
https://leetcode-cn.com/problems/island-perimeter/submissions/

我本来以为人家网站有问题，同样的题目，执行时候能过去，结果提交过不去，然后在想用java改写一下的时候，忽然看明白了，我特么一开始没return🤣

问题在于怎么没发现呢？因为，唉，截个图吧，懒得说了

最后是这样，真特么的傻B

R

我感觉自己被成功安利了pycharm professional，双十一前夕就是这么的不冷静，为了假装花钱花的更明白一些，遂有这周此节

PyCharm Professional 特性

参考原文，pycharm 2020.02版本的

Prerequisite

Django framework and the corresponding Python interpreter are properly installed on your machine.

前提条件

正确得安装Django框架和相应的Python解释器

其实我觉得不太对，细节写在Anki Saladict的 corresponding卡片上了

Supported versions of Django and Python

PyCharm supports the latest Django versions. The corresponding Python versions depend on Django. See What Python version can I use with Django?

受支持的Python和Django版本

PyCharm 支持最新的Django版本。相对应的Python版本依赖于Django。查看这里

搬运工，传送门，不过竟然给了个1.x 的链接，可见多久没人维护这个文档了，3.1的；说起来这段结合上面有点明白整体想表达的啥意思，但是总之这文档这一部分是废话，但是了解自己使用的工具得版本策略还是个挺重要的事情，中文的先看看吧，该文档还是传递了不少信息的

Django support

Django support in PyCharm includes:

• Dedicated project type.

• Ability to run the tasks of the manage.py utility.

• Django templates support (syntax and error highlighting, code completion, navigation, completion for block names, resolve and completion for custom tags and filters, and quick documentation for tags and filters).

• Ability to create templates from usage.

• Ability to debug Django templates .

• Live templates (snippets) for the quick development of Django templates.

• Run/debug configuration for Django server.

• Navigation between views and templates.

• Code insight support for Django ORM.

• Code completion and resolve in

  • views.py and urls.py files:

    • Code completion for the view.py

  • Models:

    • Code completion for the model

  • Meta model options:

    • Meta model options

  • Configuration constants in the settings.py file

    • Completion for configuration constants in settings.py file

• Class-based views. PyCharm provides Intention action to convert Django function-based generic views to class-based views.

• Generating model dependency diagrams for Django models.

Django 支持

PyCharm中包含的对Django的支持有：

• 专有的工程类型
• 能够运行manage.py任务得工具
• Django模板支持（语法和错误高亮，代码补全，导航，块名称补全，用户标签和过滤器的解析和补全，以及标签和过滤器的快捷的文档）
• 可以在使用时创建模板
• 可以调试django模板
• Live template（片段）之于Django 模板的快速开发
• Django 服务器的Run/Debug Configuration
• 视图和模板之间的跳转
• Code insight功能对Django ORM的支持
• 代码补全：
  • views.py和 urls.py文件
  • 模型
  • 元模型选项
  • 包含在settings.py文件中的配置常量
• 基于类的视图，PyCharm提供Intention action来进行基于函数的通用视图向基于类的视图的转换
• 为Django models撞见模型依赖插图

• 模板支持
  • 概述那块儿老实说没看懂，强译的乱七八糟的
  • filter是不是django template中一个特别的东西？还没探究
  • live template是个什么鬼也没给个link
• Configuration那个吧，主要是为了debug调试，好像不用它也行，至少stackoverflow里好多人是问过并且有人是给了肯定答复的——就是配置一个python manage.py，但试过一次捅后台时候不行，也不知道是不是项目结构导致的包找不到？
  • 还需要再试一次
• 视图和模板之间鼠标点击跳转导航的这个，确实方便
  • 虽然我还没用到
• 代码补全
  • create template from usage 这个很流畅，就跟有点开始习惯了先顺着思路先写高层次代码，然后在语法和语义上不全必要的变量声明，函数声明一样，这个copy原文保留了link传送门，值得去了解下（如果不记得得话）
  • view.py 的自动补全那个没试出来
  • model 目前也是，不得要领
  • settings.py 好像应该是可以出来最顶层，总之还是不得要领
• 向基于类得视图转换这点儿，说的挺牛B的，django总共就这么两个 Intention action
  • 不过还没有试
• 创建 mode dependency diagrams 这个，还没试，猜测，帝国主义那边ORM都是对象先行，然后ORM反向生成数据库，那数据库优化也就是后置的一个过程（但特么数据库schema先设计的天朝也是一样，基本上是凭需求给出来的感觉来设计数据库，而不是基于应用设计… 我感觉我好像又触及到了什么问题得本质），需要找个东西来跟关系数据库专家来讨论，这时候需要这么个可视化的东西吧
  • 没试，值得试试

再下面那段，我竟然一瞥也能看懂，就不翻了（其实是懒了），不过奇怪的是这东西有啥用，或者为啥不能做成自动的？

• 我估计是它做不成自动的，因为从外部导入的工程结构有可能不是它设想的，比如我一开始那种直接保留了缺省两层同名的顶层目录的（这个我觉得也挺奇怪的，tutorial里面为啥不把destination这个参数介绍了，可能涉及太多与django无关的工程组织部分吧）
• 它这个感觉就是外部导入的需要手动打开（我是从community的工程直接打开的），关闭…不知道什么时候需要关闭
• 可能是那些没有安利成功的

综上所述，值得买，不过不着急，而且买了两个估计就买全家桶更值吧（其实也不确定瘪得用得上用不上）

仔细看了一下renew或者switch到全家桶的订单细节，先把之前2019年得一个优惠code给用了，现在java ide到2022年3月底但不是最后一天，挺奇怪的，它为什么是363天的续约，没懂，反正一两天的不计较了，就当给同行打call了

具体转全家桶，还是等pycharm这一个月试用结束吧

为了最终搞明白这件事情，截图转换订单

T

git rebase —strategy-option theirs

• 有这个需要，同时受这篇启发，了解到的一些option
  • 更细节的用法其实是git checkout —theirs — README.md
    • README.md的位置其实标准名称是pathspec
    • 如果是rebase过程中，标记为冲突的
    • 就会是那个样子就是<<<<<<<======>>>>>>这堆，具体数量这里写的可能不对，文档截图
    • 比较常规的用法参照这个
• rebase本身这个策略，比较粗旷，其实可能会导致预期错，但其实没问题，比如说它其实只是冲突的时候使用theirs，没有冲突的还是会rebase在rebase基准的后面的
  • 当然这个行为其实是我根据我自己那个例子场景得结果，自己瞎猜的，具体还是应该参考文档和实际跑一下，反正git保存好了先在一个分支里，基本丢不了东西
• 这个东西如果想搞明白，需要明确这么几个东西
  • <<<<<<<和=======之间的东西是ours
  • =======和>>>>>>>之间的东西是theirs
  • git merge b1，b1的东西是theirs
  • git rebase b1，b1的东西是ours
  • 很多人觉的上面这个merge和rebase是拧巴的，不好理解，是因为没有理解这两个代词都是相对于实际实现过程时，所处于的当前位置的
    • git merge的时候，就是，其实是git merge （ sth to current），就是直接在current上操作
    • git rebase的时候，其实（应该是？其实不是很确定，但是冲突时候听下来git status时候，确实是这么一个情况的感觉）是detach到一个游离分支上操作，这个游离分支的HEAD和b1是指向一个地方的，所以b1的是ours，倒不如说ours☞向了b1的，总之，current分支（执行git rebase时候所在的那个分支），在conflict停下来的那个时候，反倒成了“别人”了

• 对于这篇，还是有话要说的

  • 真漂亮，如果可能，我想看懂这篇的设计精髓，比如CSS等等
  • 但是从内容上讲，一切上来不讲清楚ours和theirs就开始扯得这个问题得，那不是耍流氓，而是自己未必真的明白了

    git diff commit1..commit2

• 这个主要参考这里

• 另外再记录一个常用的git diff —name-only，这个没有自动补全提示不知道为什么，这个我现在用在一些增量提交的检查上
  

  S

  Pycharm的专业版特征之一

  
  其实不止
  
  所有非本地的都可以，服务端开发确实有这个问题，Java的还好，运行起来比如NIO会有点差别，但是coding基本上没什么差别，maven也就算基本一样吧，但是python这个venv在不同平台上就有不同的路径，一个叫bin，一个叫Scripts

但是这个功能应该不是为了屏蔽venv差异的，他可能更多的适合用来调试线上某环境为什么不符合预期…

目前为止（2020-10-27）还是不太确定专业版的必要性…

IDE和缺陷系统或者说issue tracker的联动

本来这周不太想用这个jetbrains的tip糊弄事儿的，但是意外看见这个，确实沉思了那么一小下

• 确实现在的组织，对待issue系统过于粗糙了，原因有很多这里略过先
• IDE作为一个很好的 集成 的聚合点，应该好好利用，如果最下面那个PyCharm Professional Customization是真的，那么专业版可能就还真的很值得入

PyCharm和Django的集成

参考

• 官方文档

  会心一击

• manage.py 的命令提示…，直接看文档吧

• 好像django自己是有个shell的，但是，用的感觉不是那么顺手

  其他有意义？的启发

• 或者说是给了个胆子

• 用pycharm createproject的时候，发现它直接把pycharm的项目根目录放在使用django-admin startproject时候双层同名目录的上层了
  • 也就是venv是和带着setting.py的那个目录以及manage.py是同级的
  • 这个级别相当于让项目顶层目录等同于python xxx.py时候，xxx.py所在的那个./ 目录了，应该是能消除一些不必要的麻烦
  • django文档里面也已经明确说明了上层那个目录其实名字可以随便改，内层目录就是个包（含一个init）
• 这时候猜也猜到了startproject这个命令 后面应该两个参数，一个是项目名字，一个是项目目录位置
  • 那么实际上如果是手动创建工程骨架，顺序估计会是python -m venv venv ; source venv/bin/activate; pip install django; django-admin myproject .
• 忽然也明白了，为啥name不能用中横线，因为…那是个包，中横线不满足pep8的命名规则😂

  双11