Repository: lazyparser/survivial-manual-for-interns Branch: master Commit: eafdef484962 Files: 17 Total size: 54.6 KB Directory structure: gitextract_2im_v92p/ ├── .gitignore ├── CONTRIBUTORS ├── LICENSE ├── Makefile ├── README.md ├── article/ │ ├── 安传旭_实习生存指南.docx │ └── 安传旭_实习生存指南.md ├── conf.py ├── first-four-weeks.rst ├── glossary.rst ├── index.rst ├── interview.rst ├── prepare.rst ├── rules.rst ├── so-you-are-writing-scripts.rst ├── team-dynamics.rst └── tips.rst ================================================ FILE CONTENTS ================================================ ================================================ FILE: .gitignore ================================================ # Node rules: ## Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files) .grunt ## Dependency directory ## Commenting this out is preferred by some people, see ## https://docs.npmjs.com/misc/faq#should-i-check-my-node_modules-folder-into-git node_modules # Book build output _book # eBook build output *.epub *.mobi *.pdf /_build/ ================================================ FILE: CONTRIBUTORS ================================================ ================================================================= 贡献者名单 ================================================================= 格式：姓名（或者ID）邮箱 提交PR的时候可以把自己的信息加入进来。 ================================================ FILE: LICENSE ================================================ Attribution-ShareAlike 4.0 International ======================================================================= Creative Commons Corporation ("Creative Commons") is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an "as-is" basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible. Using Creative Commons Public Licenses Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses. Considerations for licensors: Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC- licensed material, or material used under an exception or limitation to copyright. More considerations for licensors: wiki.creativecommons.org/Considerations_for_licensors Considerations for the public: By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor's permission is not necessary for any reason--for example, because of any applicable exception or limitation to copyright--then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described. Although not required by our licenses, you are encouraged to respect those requests where reasonable. More_considerations for the public: wiki.creativecommons.org/Considerations_for_licensees ======================================================================= Creative Commons Attribution-ShareAlike 4.0 International Public License By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions. Section 1 -- Definitions. a. Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image. b. Adapter's License means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License. c. BY-SA Compatible License means a license listed at creativecommons.org/compatiblelicenses, approved by Creative Commons as essentially the equivalent of this Public License. d. Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. e. Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements. f. Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material. g. License Elements means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike. h. Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License. i. Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license. j. Licensor means the individual(s) or entity(ies) granting rights under this Public License. k. Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them. l. Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world. m. You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning. Section 2 -- Scope. a. License grant. 1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to: a. reproduce and Share the Licensed Material, in whole or in part; and b. produce, reproduce, and Share Adapted Material. 2. Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions. 3. Term. The term of this Public License is specified in Section 6(a). 4. Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a) (4) never produces Adapted Material. 5. Downstream recipients. a. Offer from the Licensor -- Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License. b. Additional offer from the Licensor -- Adapted Material. Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter's License You apply. c. No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material. 6. No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i). b. Other rights. 1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise. 2. Patent and trademark rights are not licensed under this Public License. 3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties. Section 3 -- License Conditions. Your exercise of the Licensed Rights is expressly made subject to the following conditions. a. Attribution. 1. If You Share the Licensed Material (including in modified form), You must: a. retain the following if it is supplied by the Licensor with the Licensed Material: i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated); ii. a copyright notice; iii. a notice that refers to this Public License; iv. a notice that refers to the disclaimer of warranties; v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable; b. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and c. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License. 2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information. 3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable. b. ShareAlike. In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply. 1. The Adapter's License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License. 2. You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material. 3. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply. Section 4 -- Sui Generis Database Rights. Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material: a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database; b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database. For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights. Section 5 -- Disclaimer of Warranties and Limitation of Liability. a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability. Section 6 -- Term and Termination. a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically. b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates: 1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or 2. upon express reinstatement by the Licensor. For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License. c. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License. d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License. Section 7 -- Other Terms and Conditions. a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed. b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License. Section 8 -- Interpretation. a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License. b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions. c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor. d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority. ======================================================================= Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” The text of the Creative Commons public licenses is dedicated to the public domain under the CC0 Public Domain Dedication. Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at creativecommons.org/policies, Creative Commons does not authorize the use of the trademark "Creative Commons" or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses. Creative Commons may be contacted at creativecommons.org. ================================================ FILE: Makefile ================================================ # Minimal makefile for Sphinx documentation # # You can set these variables from the command line, and also # from the environment for the first two. SPHINXOPTS ?= SPHINXBUILD ?= sphinx-build SOURCEDIR = . BUILDDIR = _build default: $(MAKE) html latex latexpdf # Put it first so that "make" without argument is like "make help". help: @$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) .PHONY: help Makefile default # Catch-all target: route all unknown targets to Sphinx using the new # "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS). %: Makefile @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) ================================================ FILE: README.md ================================================ # 实习生存指南 Survival manual for my interns and fresh engineers. ================================================ FILE: article/安传旭_实习生存指南.md ================================================ # 实习生存指南 2020年5月14日星期四,南京,天气阴转小雨.窗外非常有规律的传来高铁的声音.已经正式入职月余的我,终于沉淀下来回望过去的研究生生涯,和穿插其中丰富的实习生活,作为对过去实习岁月的总结,和未来工作的展望. 人生的第一份实习,还是在大三暑假,学校组织了一次校企合作的实习项目,而那短短的两个周内,我们基本上也就熟悉了下职场的环境,技术和知识的获取是相当有限的,以至于在后来的回忆里,那次更像是一次集体"旅行". 第一份真正的实习,开始在大学毕业的夏天.刚从冰城毕业的我准备在研究生开学之前找份实习,锻炼下自己.机缘巧合,吴老师正在招实习生.经过一轮简单的电话面试,吴老师给了我一个远程实习的机会.当时招聘的是`ROS`开发实习生.而坦率的讲,本科毕业的我除了`C++`语言之外,和这个实习生招聘要求条件相差甚远.我并不懂什么是`ROS`,也没有接触过机器人,仅仅觉得做机器人非常的高大上,听起来就是一件不沉闷有意思的事情,就选择努力争取到这个机会,打开一扇新世界的大门. 在吴老师团队实习过的同学都知道,我们团队有一套实习生的评级准则,实习生也许刚进入团队评级很低,比如刚出"新手村"就是lv2,经过一段时间的"打怪升级"提升自己的能力,就会被升级到lv3,lv4甚至lv5.而现在的标准是低于lv2无法进入实习团队的,要继续私下提升自己,经过再次面试达到lv2方可通过.而当初的我,被惨淡的评为了lv0,也就是俗称的小白.预估产出是0.现在看起来,第一个月更像是实习培训期,吴老师安排了我跟着柴老师学习`ROS`相关知识,并在一定范围内打打下手,辅助柴老师做一些工作.就这样,我在忐忑又充满憧憬的心情中,开启了我在软件所的实习生涯. 当初选择来北京读研,有一个很重要的原因,就是看中了北京异常多的实习机会,可以接触到行业最新的技术.希望能够在研究生期间多多实践,为了未来的工作打好基础,即使将来选择继续读书,实习也是很好的一个锻炼,从中学到的东西有些是实验室和书本给不了的.所以我也鼓励大家有实习的机会,一定要好好把握,多多实习,多多扩充自己的知识边界.话题继续回到我们的实习生活中来,最初的实习,刚刚也说过了,就是单方面的培训.我开始按照吴老师和柴老师的指导,针对性的学习大量的专业技能知识,比如`Linux`,`ROS`,`Git`,`Cmake`等等.刚开始的一个月里,遭受到了很大的打击.比如最简单的安装`ROS`,重装了几次`ubuntu`系统才成功的安装了ROS,中途遇到的任何问题对于我而言都是全新的,也是痛苦的.比如一个软件包无法找到,就可能要了我一个下午的时间和数十根的头发.全新的知识带来的欢愉也是无可比拟的,第一次启动小乌龟,第一次向它发布指令`rostopic pub`,看着小乌龟在我的屏幕上移动,那种充实的收获感,瞬间就使我忘记了那个抓耳挠腮的下午,带给人的快乐堪比夏日里的冰镇西瓜... 后来的实习就慢慢跟上了节奏,不断的学习新知识,不断的扩充自己的知识边界,也经常在各种error和bug里走不出来,也会不时的做出一点新的东西开心一整天.吴老师时常给我们灌输的理念是"精英自治".自觉主动学习的习惯,应该是大学教会我们的,研究生期间,我们应该学会独立思考和创新,在面对问题的时候要自己想办法解决,这里并不表示说建议自己闷头苦干,想办法的意思是指包括独立思考,查资料问谷歌,团队协作以及寻求帮助,积极主动的"自治",这是我们团队所倡导的,也是一直贯彻的理念.后来的实习中,不断的涉足到新的领域,学习到新的知识和技能,但是”自治”的理念才是学习到的最宝贵的东西. 这段实习经历带给了我很多,不仅是简历上非常有分量的一笔,也成为了我留在这里工作最重要的原因.毕业前夕的秋招中,几乎面试的每家单位都会问及该段实习,想必也是参与实习项目比较丰富,拿到了几个还不错的offer,当然其中也有吴老师提供的正式offer.权衡了之后决定留在这个积极向上的团队,继续前进.此外这段实习生涯,也认识到了很多的大佬,结交了很多好友,同一级的实习生经过了秋招有的也留在了团队里,有的成为了我们的甲方,还有的继续读书,总之都变成了我们各自心中更好的自己. 所以,同学们,如果有机会,珍惜每一次的实习机会,如果有机会,欢迎加入我们!`do you can do ,try your best!` 2020,祝你健康. >中科院软件所智能机器人研究中心-安传旭. ================================================ FILE: conf.py ================================================ # Configuration file for the Sphinx documentation builder. # # This file only contains a selection of the most common options. For a full # list see the documentation: # https://www.sphinx-doc.org/en/master/usage/configuration.html # -- Path setup -------------------------------------------------------------- # If extensions (or modules to document with autodoc) are in another directory, # add these directories to sys.path here. If the directory is relative to the # documentation root, use os.path.abspath to make it absolute, like shown here. # # import os # import sys # sys.path.insert(0, os.path.abspath('.')) # -- Project information ----------------------------------------------------- project = u'实习求生指南' copyright = '2020, Wei Wu @lazyparser' author = 'Wei Wu @lazyparser' # The full version, including alpha/beta/rc tags release = 'v1.0-dev' # -- General configuration --------------------------------------------------- # Add any Sphinx extension module names here, as strings. They can be # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom # ones. extensions = [ ] # Add any paths that contain templates here, relative to this directory. templates_path = ['_templates'] # The language for content autogenerated by Sphinx. Refer to documentation # for a list of supported languages. # # This is also used if you do content translation via gettext catalogs. # Usually you set "language" from the command line for these cases. language = 'zh_CN' # List of patterns, relative to source directory, that match files and # directories to ignore when looking for source files. # This pattern also affects html_static_path and html_extra_path. exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store'] # -- Options for HTML output ------------------------------------------------- # The theme to use for HTML and HTML Help pages. See the documentation for # a list of builtin themes. # html_theme = 'sphinx_rtd_theme' # Add any paths that contain custom static files (such as style sheets) here, # relative to this directory. They are copied after the builtin static files, # so a file named "default.css" will overwrite the builtin "default.css". html_static_path = ['_static'] master_doc = 'index' ================================================ FILE: first-four-weeks.rst ================================================ ======================================= 四周内部培训 ======================================= TODO 将目前我用过的培训内容添加到这里。 TODO 将 https://github.com/lazyparser/weloveinterns 中的内容搬运整合到这里。 https://missing.csail.mit.edu/ The Missing Semester of Your CS Education Classes teach you all about advanced topics within CS, from operating systems to machine learning, but there’s one critical subject that’s rarely covered, and is instead left to students to figure out on their own: proficiency with their tools. We’ll teach you how to master the command-line, use a powerful text editor, use fancy features of version control systems, and much more! 以后作为LV2的入门教程了，有兴趣可以查缺补漏。 Schedule 1/13: Course overview + the shell 1/14: Shell Tools and Scripting 1/15: Editors (Vim) 1/16: Data Wrangling 1/21: Command-line Environment 1/22: Version Control (Git) 1/23: Debugging and Profiling 1/27: Metaprogramming 1/28: Security and Cryptography 1/29: Potpourri 1/30: Q&A B站链接： [[MIT]计算机科学课堂中学不到的知识 The Missing Semester of Your CS Education(2020)](https://www.bilibili.com/video/BV1x7411H7wa) 贴发票（基础财务知识） -------------------------------- 所有新入职员工或者实习生都需要掌握此项能力。 都需要找机会学会如何贴发票，按照部门的报销要求处理财务票证。 必须知晓增值税专用发票和普通发票的区别，自己保存好开票信息。 必须知道或知道如何快速确认需要购买的事项或花销需要的手续，是提前审批还是事后直接报销。 熟悉会计的基本术语。 ================================================ FILE: glossary.rst ================================================ ========================================= 常用的术语表 ========================================= 一些日常沟通的团队用语。 * PLCT: 程序语言与编译技术实验室，隶属于ISRC * y站：是指团队内部使用的gitlab系统。由于历史原因使用了一个y开头的缩写，所以简称y站。 * B站：``_ `往期技术报告传送门 `_ * q站: ``_ 是软件所机器人团队维护的机器人开发社区。 * t站： 是软件所工业仿真团队的内部系统站点。 * gh：是GitHub的缩写。 * gh/isrc：是 ``_ 的缩写。 * LV2、LV3、LV4: 是对实习生的能力等级划分。 `links `_。 * mentor: 导师，上司 * lord: 领主，是团队内部带有项目管理的资深成员的称呼。 * fief: 每个 lord 都有自己的 fief。 * owner: 一个仓库或者项目的负责人。owner可以是lord也可以不是（虎级项目不用是lord）。 * DDL、Due: DDL(deadline)任务完成的截止日期，Due 任务负责人 * LGTM：Looks good to me。在 code review 和讨论中表示认可，不会阻止。 * OTOH：On the other hand，另一方面，换一个角度来说。 * IMHO: In my humble opinion，以我的愚见（不过另一种用法就是准备开始言辞激烈的争论）。 * AFAIK: As far as I know，据我所知。 * btw：by the way。顺带一提。 * tiger、whale、dragon：用来从低到高表示三类不同的项目划分。没有外部交付要求的项目属于 tiger 级，一般是新人的培训项目以及毕业设计；whale是有外部交付但是交付时间不严格的开源项目。例如 rvv-llvm 和 pacific 都属于 whale 级；dragon 是指有严格交货日约束以及有商业保密要求的项目。所有商业类交付都属于 dragon 级。OTOH，由于在y站也进行了不同的群组区分，所以 tiger 一般是指全体员工和学生。 * 代码尸体：参考 `rules <./rules.rst>`_ * 本部：是指软件所北京本部。 * 江浙沪小队/江浙沪皖小队：是指PLCT在江浙沪皖四个城市的小伙伴组成的项目小组。经常承接长三角地区的项目委托，进行现场支持。 * 南京小队：坐标位于南京分院的PLCT小分队。具体做的项目是各自不同的。 * ISRC：智能软件研究中心，隶属于ISCAS * ISCAS： 中国科学院软件研究所 * upstream：这是个泛指，通常作为名词是指开源代码项目的官方社区；作为动词是表示将PLCT的成果提交给上游社区。 * 歧义指代：是指从上下文剥离出来之后无法知道具体指代的客体是什么的话。例如「这个、那个、上次、昨天」等。 * hq：headquarts。指挥中心，远离战区，做情报调度、分析和决策。 * FYI: for your information。给你的信息，请知悉，顺带一提。 * AFAIK/AFAICS: as far as I know/can see。据我所知。 * TL;DR: Too Long; Didn't Read。太长不看。常见于作者总结摘要的开头。 * FWIW: For what it's worth。无论如何，无论怎样。 * FTBFS: Fails To Build From Source。无法从源代码编译。 * SIG: Special interest group。专项兴趣小组。一般指专注特定技术、应用领域的工作小组。 * BoF：Birds of (a) Feather。非正式讨论小组。一般在会议活动中用于临时、或形成正式小组前的讨论，无需准备提纲等。 ================================================ FILE: index.rst ================================================ .. 实习生求生指南 documentation master file, created by sphinx-quickstart on Mon Jan 20 16:16:12 2020. You can adapt this file completely to your liking, but it should at least contain the root `toctree` directive. 实习求生指南 =============================================== .. toctree:: :maxdepth: 2 :caption: Contents: ./prepare ./interview ./first-four-weeks ./team-dynamics ./rules ./tips ./so-you-are-writing-scripts ./glossary Indices and tables ================== * :ref:`genindex` * :ref:`search` ================================================ FILE: interview.rst ================================================ ======================================= 如何通过面试 ======================================= TODO ================================================ FILE: prepare.rst ================================================ ======================================= 进行实习准备 ======================================= 看到这里，那么我相信你已经想要加入PLCT进行实习了，并且已经知道LV的含义和需要达到的能力。这里是一些具体的要求点。 * 首先C/C++/Java至少需要熟练一种。 * Linux命令行要用熟练。win10现在有WSL2，可以直接安装Ubuntu。 * Bash脚本编程需要掌握一些。找本Bash脚本编程的书，过一遍。 * Git使用要熟练。 * 可以看看MIT的 missing course，`B站搬运 BV1H7411K7pZ `_ * LV2 及以上需要复习过一边数据结构和算法的基础知识。 * LV3 及以上需要复习一遍操作系统原理和编译器原理。 * LV4 及以上要求的综合实力比较多，短期准备不了什么。进入PLCT之后慢慢锻炼吧。 * 上机考试环境是ssh远程登陆进入Linux系统，使用tmux进行屏幕分享。事先熟悉下tmux。 * 技术分享面试要求在一周左右时间内进行一次技术分享，考察能力和动机。能力可能无法短期内提高，但是报告本身很能体现出来报告人的用心和细致程度。上机考试是准入淘汰，技术分享是择优录用。所以请务必用心。 * 多搜集公开情报，从PLCT的开源仓库和活动中搜集自己感兴趣的信息。PLCT同时在进行很多有意思有挑战性的项目，如果你在面试的时候就已经很清楚自己想做什么，那么被录用的可能性就很大。 关于PLCT的薛定谔实习工资的说明： ======================================= 时间上，每个月10号ww会提交全体成员的工资表给部门，部门20号前提交给软件所，软件所30号左右发出来到各位的建设银行卡。 数额上，完全由外部可见交付物决定。目前浮动区间是下限是0，上限是11k。中位数预期是LV∂ 对应∂k/mo。 交付物，是指【外部可见】的交付物，包括在各个开源项目（upstream）上的 non-trivial PR/Issues讨论等、gh/isrc-cas 或者 gh/x-riscv 的公开贡献、知乎文章、B站技术报告视频等。统计以每个月1号和16号「PLCT开源进展」的列出条目作为主要参考。 时效性，有一定的延迟，也就是说12月30日的数额是对应11月初～12月初的产出。如果12月产出爆炸，那么会在1月10日统计提交，1月30日数额体现。 由于年底封帐，12月份提交时间提前为12月4日。 AI编译器方向的一些学习资源： ================================================ https://zhuanlan.zhihu.com/p/163717035 阿里PAI团队《AI编译优化》不错的系列文章。 虚拟机分支的同学应当看过或掌握的内容 ================================================ * Mario Wolczko @ VMSS16: A Concise and Opinionated History of Virtual Machines https://www.youtube.com/watch?v=QnQYhrpX39M&list=PLJq3XDLIJkib2h2fObomdFRZrQeJg4UIW 90分钟时间，介绍了虚拟机发展的一些历史，是系统性了解虚拟机历史发展很好的入门阅读。 * Cliff Click @ VMSS16: Bits of Advice For the VM Writer https://www.youtube.com/watch?v=Hqw57GJSrac&list=PLJq3XDLIJkib2h2fObomdFRZrQeJg4UIW&index=2 Must Read RISC-V 相关的内容 ================================================ Chisel Quick Tutorial - 1st RISC-V Bootcamp https://www.youtube.com/watch?v=pfM1WUWbfBs 2015年的第一次（？）公开有记录的 Chisel 介绍。现在已经有了很大的不同。如果是做 Chisel/FIRTTL 相关的实习生，那么值得看一看。 ================================================ FILE: rules.rst ================================================ ============================================ 工作守则速查 ============================================ 本节列举了一些在我的团队中工作默认遵守的原则（强制要求）。 绝大部分原则是不区分实习生（intern）和正式员工（staff）以及具有自治和指挥权的领主（lord）的。 我所组建和管理的团队，一般采用精英自治模式。 这要求每一位成员都具有高度的自主性、高度的技术能力和自我管理意识，同时能够同团队其他成员、以及整个团队实际要达到的目标出发进行事态分析和预测执行。 对于实习生而言，我内心并不想要降低要求。我相信优秀的人不是顿悟然后战斗力爆炸的，是通过长年累月的积累形成的。 注意，请注意，这里有一个误区。或者换个说法，现在我要开始揭示一个你可能从未认识到的事实： 这些我很珍视的品质，这种在劳动力市场上难能可贵的能力，并不需要任何超过平均值的智商、情商、数学功底、计算机功底、抑或其他任何需要痛苦自律才达到。 相反的，完全相反的，这些珍贵的品质，是需要对接下来我列出来的这些看起来微不足道的原则的遵守。 成为我的团队的一员，长期的那种，一个必须的前提是 **Be Humble**，谦卑。毕竟， 要相信只要遵守这些看起来是鸡毛蒜皮的守则就可以成为我刚才提到的顶级优秀的人才，并不是很容易。 原则 01 任何会议均要有纪要 ================================================ 没有会议纪要的会议或谈话，不曾发生过。 原则 02 任何任务均要有计划和记录 ================================================ 内部系统没有记录的任务，没有发生过。 原则 03 Learning By Teaching ================================================ 以下原则是对所有成员（实习生、学生和员工）普遍适用的： 1. 任何学习过程本身不是目标，也不能作为交付内容。（不然就应该是反过来我来收培训费啦😄） 2. 未能讲授分享的知识，未能掌握。也就是说，没学会。 原则 04 没有版本控制的代码皆为尸体 ================================================ 任何离开 git repo 的代码，都是尸体（corpus）。 原则 05 任何非官方下载的软件二进制都有后门 ================================================ 是真的。严禁百度网盘或者X网盘下载。如果下载速度慢或者被墙，找mentor。 原则 06 严格遵守开源代码版权和LICENSE ================================================ 做学生的时候，一般的工作流程是，有一个问题，分析，Google下代码，复制粘贴，修改。 It works，交作业。 但是做项目的时候是严格禁止直接复制粘贴的：没有标注引用出处的代码复制会被看成抄袭行为， 这在商业软件开发中是很严重的。这点尤其需要引起重视。 一般性的原则是，如果引用了他人的代码，首先需要检查是否LICENSE是跟你正在做的项目的LICENSE是相容的。 如果相容，那么引用的时候，需要注意保留作者的CREDITS。也就是说，如果是文件使用，本身有文件头声明， 那么要保留；如果是引用很少的片段，那么在注释中指出URL。如果是软件包使用，需要在CREDITS中进行致谢。 一般而言，模块级别的使用，放在 third_party 目录下，同时在CREDITS中致谢。而小的代码改动，则通常是自己理解了之后重写。 Jay Michaelson 的这篇文章是所有员工和实习生的必读： There's no such thing as a free (software) lunch What every developer should know about open source licensing ``_ 原则 07 只使用、无改动的工具不要放在 git repo 中 ================================================ 对于不修改只是用的软件，使用脚本自动下载和解压缩而不是放在 git repo。 例如交叉编译，要使用到 arm-linux-gcc-8 的某一版本的编译器。只是使用，不进行修改。这种情形是跟代码 LICENSE 没关系的，最好是按照脚本下载压缩文件，然后解压缩的形式。 这样【仓库中只有你写的下载-解压缩脚本，是没有这个编译器tar包的】。 .. code:: bash if 本地没有tar名字 从URL下载 # 保证有了 if 有目标目录了 删除这个目录 tar tar文件 to 目标目录 一个有用的链接： ``_ （FIXME：原则07的交叉编译器的内容或许可以放在tips） 原则 08 避免「这个、那个、上次、昨天」等模糊指代 ================================================ 模糊指代也是歧义指代，是指说的代词可以指向一个客体集合而不是唯一的客体对象。 一个检测方法是将提到了指代的话单独拎出来读一遍，看看是否可以脱离聊天上下文成立。 提到软件，最好有具体的版本号，或者 tag ，或者 commit id； 提到任务，最好有 issue number 或者 T id； 讨论问题，先在GitHub或y站进行记录，然后贴url，再开口讨论。 原则 09 避免使用「你」在对话中 ================================================ 不管是中文语言还是英语还是日语，直接使用「你/you/あなた」都是带有隐含的对抗性质的。同时，「你」也会导致文字内容复制转发的时候会需要重新编辑。 改写的方式有很多种，要看具体的上下文。一般是有意识的规避几次就好了。一个通用做法是直接写名字，「我（名字）这边」怎么怎么样，「X这边负责」怎么怎么样，类似。 原则 10 禁止在项目开始的时候就用话语给自己寻找退路 ============================================================ 语言能够塑造人的行为，并在思维上给自己预期的失败寻找理由。 在项目的开始的时候，即使你的内心是这么想的，有些话也是不可以说出来的。以下是一些在 PLCT 被要求禁止说出来的话。 **例子1: 隐式推卸责任** （当接到一个新任务和交付时间节点的时候） 「这个事情我之前没有接触过。我先看一看。」 实际上表达的潜台词： 「我不想对能否按时交付负责。我也不对结果负责。如果到了交货日期我交付不了，那要怪 mentor 自己。因为，我已经一开始就告诉 mentor 了。」 **例子2: 隐藏现状的说话方式** 当对一个事情进行解释的时候，使用了 「现状是A，因为B」的句式。在说出了A之后，非常快速的说「因为」。 这种情况，一定是在隐藏自己对A的陈述。 作为 mentor，应该立刻打断陈述，要求重复陈述A句，并仔细分析现状。不要分析原因。先确定现状。当出现这种情况的时候，就说明 **一定是出现了坏消息** 。 mentor/lord 是对项目交付最终负责的人，而不是 intern。 所以，身为 mentor 需要有这个能力。 **例子3: 模糊进展的说话方式** 在对工作进展进行描述的时候，采用大量的好像、可能、大概、应该是的说法去描述细节，不明确的表明进展情况。 这种情况是潜意识的逃避对目前的进展做说明，将进展掩盖在大量模棱两可的细节之中，会给合作伙伴和主管造成极大的困扰，造成实际进展不可见。 这种情况之下，通常进展已经不可控。 作为 intern 和 staff，以此为镜子自我观察。这几条例子都是非常、非常常见的，而且多数人已经形成了（很难改掉的）习惯。 在PLCT，不承担责任或者隐含的隐瞒坏消息是会被 wuwei 立刻抓住的。 要么改掉，要么离开PLCT。 原则 11 及时响应同事的ping，邮件每日查看 ================================================ 我们多数都是远程工作。远程工作的重要前提之一是及时响应。 不能在工作时间及时响应同事的成员，会拖累同事和项目。 如果做不到，要么调整成为 solo 工作方式，要么离职，不管是员工、兼职还是实习生。 ================================================ FILE: so-you-are-writing-scripts.rst ================================================ ======================================================================== 写 Bash / Python 脚本注意事项 ======================================================================== 不要使用绝对路径 ======================================================================== 编写脚本时,经常会在脚本中添加路径,比如编译一个特定目录的C文件,这时候不要直接将 自己的文件路径添加到脚本中,因为不同机器在运行时对应的路径可能存在差别,导致整个 脚本运行失败。 正确的方法是用变量来定义路径,并把绝对路径替换成相对路径。 对于交叉工具链，用脚本下载解压 ======================================================================== 当需要使用交叉工具链时,应该先从Ubuntu的launchpad或者Linaro官网上找,不要使用 百度云中的工具链资源,因为百度云中的资源可能有后门漏洞,无法确保安全性。使用交叉 工具链应该在脚本中依次：下载->解压->配置环境->使用。这样做在仓库中只有我们写的 脚本代码，不存在编译器的tar包，提高工作效率。 MORE @pandora ======================================================================== TODO 使用 Python3 ======================================================================== 没啥好说的。 Python2 已经死了。 尽量不要修改用户的环境配置 ======================================================================== 在脚本中尽量不要改变用户的环境配置,例如.bashrc、/etc/profile等,因为可能产生意 想不到的问题出现。建议使用export单独修改当前环境,脚本运行完成后对环境不产生其他 影响,雁过不留痕。 对环境有副作用的操作要考虑是不是幂等的 ======================================================================== 幂等指的就是一个操作多次重复产生的效果都是相同的,在脚本中许多情况下都需要注意将 操作修改成幂等的。例如,用脚本建立一个文件夹 *mkdir test* ,当第二次运行脚本时就会 出现已经有`test`这个文件夹无法生成的问题,所以对环境有副作用的操作需要考虑操作是 不是幂等的。 正确操作示例： :: DIR=test # 1. 等号赋值两边不能有空格 2. 命令与选项之间需要空格 if [ -e ${DIR} ] then echo ${DIR} exist else mkdir test fi 命令行历史 + 一个循环 ======================================================================== 第一是战术层面的【写个 for 循环】：重复性的工作，上面的重复性的工作，是不是可以写一个 for 循环来做？ 1. 简单的方法是，在你的电脑上，只用一个 terminal 来一步一步完成所有的工作。 1. 然后用 history 命令看到整个命令序列，复制粘贴到一个 editor 中。 1. 写一个 while true; do [...你的命令行历史]; sleep 500; done 的循环 1. 找个新目录，或者新的虚拟机来测试验证下，看看是否OK。 1. 根据错误提示，思考，修改，try harder 分治法：将环境初始化工作和重复性工作分开 ======================================================================== 这个方法就是经典笑话【将大象装进冰箱需要几步？（答案是3步：打开冰箱门；塞进大象；关上冰箱门】 而你现在做的事情是 【 确定哪些仓库和分支需要编译和测评，clone 下来编译一边确保配置没错误了； 写个循环♻️不停的 pull - build/compile - run tests - upload results/log； （不用关上冰箱门）】 根据这个思想，重新看自己的命令行历史，看看 1. 哪些应该在循环之内，哪些应该在之外执行？ 1. 是否漏掉了一些环境变量或者前提条件？ ================================================ FILE: team-dynamics.rst ================================================ ======================================= 团队的动力学 ======================================= TODO 添加更多PLCT内部运作的原理和过程。 * 总体上即使是实习生，也是精英自治的。尤其是远程的实习生，没有自律能力是无法在PLCT生存的。 * PLCT的人员大概分为领主、主力、新人。实习累计时间在1年以内的都属于新人。 * 按照项目进行组织管理，非常扁平。一般是每个项目由一位领主 lead。 * 每个实习生会加入一个具体的项目中进行工作。一般而言会指定一位 lord 作为 mentor，往往就是项目的负责人。 * 我们采用小团队制度，一般是1+3的模式（参考火影的最小战斗单位）。 * 团队每周三下午会举行技术分享。一般都会要求和鼓励实习生进行技术报告和分享。优秀的报告会被上传到B站公开。 * PLCT的实习生每周需要缴纳周报。周报提交时间是每周三周例会之前。提交地点是团队大群。 all2all 广播。周报不用写的长篇大论，是有固定的模式：（1）完成了什么，子弹模式；（2）计划外和坏消息；（3）本周计划；（4）其它。 * 实习生按月观察实际交付产出。由mentor和ww负责观测。如果连续两周产出低于预期ww会进行1on1恳谈，如果没有改善的话正常会在一个月内劝退。即使是实习生，PLCT不养闲人。 * 全体lord每周一进行例行会议。讨论各个项目进展。 * 实习生的招募面试过程对全体PLCT成员可见。 * 全职员工的招募对全体PLCT领主可见。 ================================================ FILE: tips.rst ================================================ ======================================= 常用工作技巧 ======================================= 请容许我再次重申：对于我们这样的小团队而言，工作效率是团队能否存活下来的重要方面。 让我说的更直白一些：作为实习生，你的工作效率是否达到我的最低要求，直接决定了是否可以留在团队。 工作效率这里是指：第一，是否能够在DDL前完成交付；第二，培养你需要占用的我的时间，是否超过了我自己做这项工作的平摊时间。 平摊时间是指我的时间投入加上以后通过将同类（不需要我再投入时间指导或返工）工作 Offloading 给你而扣除的我的时间的期望（E）。 如果做消化理解性质的技术分享 ==================================================== 不管是全职员工还是实习生，我们都是非常强调技术报告能力和组内分享。 对于实习生而言，我的培养原则是「如果不能够报告清楚一项技术内容，那么就不能说真正理解了这项技术内容的内涵」（ref： **原则03** ）。 每个实习生平均两周就会被要求进行一次技术报告。刚加入团队的实习生一般是一周一次。 消化理解型的报告形式是，对于 **已经有人做过整理或报告的技术内容，进行同样内容的报告** 。 前人做过的技术报告的内容，包括： * 技术演讲（视频） * 技术演讲的幻灯片（Slides） * 技术博客文章，内容是完整的教程或者一步一步探索的过程。 * 教程（Tutorial） 消化理解型报告的特点： 1. 报告人一定是一开始没有掌握需要报告的知识的。报告所用素材中的知识点的掌握，是报告的目标之一。 2. 报告的听众中除了mentor，还有其他的初学者。技术报告的目的是能够让其他的初学者能够更加快速的掌握所需的知识。 3. 往往是跟后续的代码开发任务直接相关。 4. 一般通过在线视频会议形式进行报告，报告结果会留存作为团队的资料，或作为公开课（MOOC）开放出来。 5. 一般从拿到自学任务到进行报告，时间不会超过一周（5天）。超过一周的工作需要进行拆分。 做消化理解型技术报告的注意事项： 1. 名誉权和出处。参考原则06。消化理解型的报告基本上不会有新内容创新，都是第三方资料以及进一步检索得到的资料汇总。因此，对于前人工作的引用和致谢就分量更重。 a) 所有的资料都需要在PPT的最后给出参考出处。 b) 没有出处的不能引用； c) 使用的截图等信息需要给出URL，在那一页引用，就在那一页的下方贴上URL。 d) 在做资料检索的时候就养成用一个 txt 文件或备忘录记载出处的习惯。 e) 不要漏掉任何 non-trivial 的引用。 2. 拿到一个slides或者视频，并不是只看这一个材料，这只是开始。从一个素材出发，根据自己知识背景的不同，要进行不同的检索。例如，V8的Turbofan视频，要理解，就先要理解 JavaScript 语言的一般特点，需要知道 hidden class 到底什么意思，为什么会有 deoptimization。 3. 要考虑受众。估计到有人可能不理解的术语和概念，要去查资料补充解释。PPT的字不能太小，颜色不能太刺眼，一页不要放太多内容。 4. 最终交付和公开是用PDF的形式。因此不要在PPT中使用特效或者按键触发的特技。 5. 默认报告会进行留存，用于后续的团队内部培训，根据需要有可能会以团队名义作为公开课开放。所以请务必注意质量。 6. 使用团队指定的PPT模版。 7. 第一页统一写上「日期、身份、姓名、邮箱、网址」。例如PLCT，就需要写 「软件所PLCT实验室实习生 某某某」，邮箱写「 https://github.com/isrc-cas 」 8. 正式报告前最好提前一天交给mentor做review，提供一些建议。 9. 当对外公开发布的时候，作者承担主要责任和荣誉。因此，第一页的名字需要写大一点 :-) 正式的学术论文比较难，需要的背景知识比较多，因此并不算在消化理解型报告中，属于专门的论文讨论型报告。 如何通过 GitHub 的 Pull Request 提交工作 ==================================================== 实习生相关的工作有超过半数是在 GitHub 上公开进行的。 因此，如何熟练的使用 GitHub 的各种功能就显得对于效率的提升尤为重要。 第一次提交PR的时候 ---------------------------------------------------- 如果是第一天在一个 GitHub 公开仓库上工作，那么遵守 fork-commit-push-PR 流程。具体流程可以 Google 到 GitHub 的官方文档或者其他优秀的教程。 需要注意的是，任何工作最好都不要在已经有的分支上进行。默认应该是每次工作开一个新的分支。 理由是如果是在已有的分支上进行commit（熟练实习生一般是偷懒或者习惯没有养成，新手实习生往往是不知道可以 checkout -b）， 那么基本上是「单线程」的工作模式：在 master 分支上 commit 之后， push 到自己的 GitHub remote， 发起 PR，然后就什么都做不了了，等我来处理。 正确做法是每次工作都开一个新的分支来做。具体： 1. Clone 下来 repo，切换到 master 或者 develop 分支（具体根据项目约定）。 2. 从项目工作约定的分支 `checkout -b` 一个 local branch，分支名字可以是 `issueNNN`，对应任务的 id。 3. work，commit，work，commit，得到一个 commit list （有时候对应的patches叫 patch set） 4. push 到你自己的 GitHub remote 的新分支，注意是新分支，一般是跟本地分支名字相同（to save your time and life）。 5. 登录进入 GitHub 网页，看到你的分支，按照提示进行 Pull Request 操作。注意一定要选对目标分支，如果不明白，跟你的mentor询问。 6. Reviewer （一般是你的mentor）进行 code review。一般会提一些意见，要求修改。 7. 如果要求修改，跳转到 3. 新的修改push到已经发起PR的分支之后不需要重复发起PR。 8. 如果被merge，那么恭喜🎉同时要注意，现在开始你的工作流程就不一样了。继续往下看。 第 N+1 次提交PR的时候 ------------------------------------------------------ OK，现在恭喜你，已经有了被 merge 的 PR。同时有一个坏消息告诉你： 从现在开始你 fork 出来的 repo 已经跟上游的 repo 不一样了。 虽然我曾经惊奇的发现过一个简单粗暴的解决办法【1】但是我并不打算告诉你。 正确的做法如下： 1. 进入已经 clone 的 repo。运行 `git remote -v`。预期看到一个 remote，名字是 origin， URL 是你的 GitHub repo，forked from repo AAA。 2. 假设你的repo是从 repo AAA fork 出来的。例如 ``_ 运行 `git remote add lazyparser URL`。 这一步的作用是添加了一个新的 remote。 remote 的名字可以自己取一个，没有什么需要遵守的规律。 3. 运行 `git fetch lazyparser` 将上游仓库的代码也 clone 一份下来到你的本地机器（跟 origin 同样保存在 .git 目录下） 4. 本地创建一个分支，从你计划 push 的 branch。具体 `git help branch` or `git help checkout`。你会发现原来这些命令都可以带两个以上参数的。一条命令搞定。 5. work，commit，work，commit，得到一个 commit list （有时候对应的patches叫 patch set） 6. 【注意】 push 到 **你自己的** GitHub remote 的新分支，注意是新分支，一般是跟本地分支名字相同（to save your time and life）。 7. 其他都跟第一次类似了。 8. 以后，如果PR遇到冲突，表示上游分支已经更新了，你需要更新自己的本地分支已解决冲突。解决方法是 git fetch 然后 git rebase。遇到冲突的时候，用 git status 查看哪些是冲突的，打开，一个个修改。搜索类似 `<<<>>>>>>>>>>>>>>>>>>>>>>>>> 使用SSH的方式下载仓库代码，需要个人在Github的 `SSH Keys设置 `_ 里配置本机的SSH公钥。 否则无法clone 源码： :: $ git clone git@github.com:lazyparser/survival-manual-for-interns.git Cloning into 'survival-manual-for-interns'... Warning: Permanently added the RSA host key for IP address '52.74.223.119' to the list of known hosts. git@github.com: Permission denied (publickey). 具体配置步骤如下： 1. 本地机器上配置SSH :: $ ssh-keygen -t rsa -C "1132021192@qq.com" Generating public/private rsa key pair. Enter file in which to save the key (/home/chenjy/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/chenjy/.ssh/id_rsa. Your public key has been saved in /home/chenjy/.ssh/id_rsa.pub. The key fingerprint is: SHA256:aCPtc0lxXkzqlawcjDbxOTo7pgIrY1wS2ig6D4iio8k 1132021192@qq.com The key's randomart image is: +---[RSA 2048]----+ | . . | | = * . | | = O * | | . . o O * | |.o. . = S = | |*.o. + o + | |O oo o * | |X=. . = . | |*E. .. | +----[SHA256]-----+ 注：邮箱修改为自己的邮箱，Enter passphrase 默认回车即可。 2. 将公钥复制粘贴到 Github 的个人SSH Keys配置里。 产生的公钥一般为 `~/.ssh/id_rsa.pub` :: $ cat ~/.ssh/id_rsa.pub ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDa+LNRQuTAjMWZjRZ8d0CK9rZFjZZBQG2Q8UqBZpHQ7GQSBMdhO4mxRYYk/Zb7t7pMj3BpEyOOGKOFXRjic7ibREnki06TQ8LBolRAFDSBv6E4oOS5ei52mwh+NiL2mT7/5GdwZwgR2eDO22MxDRCHObFr2TBHkiThRs9NTi/28UPsy3MluyuPU/0IWZNwcjr1EKRL9qNOh9Ro+8GoEEb23A6sdG2zOjiV/VKiba8so5TqBt9ZFPvjnJtKINUb8TasusC49dSay5paDCJKnDCJQoDIiOn7ggg4ivkan2w9HK4lUK5oNHjQyQRPRiFBF+mm5DJJ7TW03dheOqZq6KPT 1132021192@qq.com 选中公钥复制粘贴到Github `SSH Keys设置 `_ 的 NEW SSH key 的 key 里即可(Title自己命名)。 3. 启动SSH代理并添加密钥 :: $ eval `ssh-agent -s` $ ssh-add 最后就可以使用SSH方式下载仓库文件了。比如： :: $ git clone git@github.com:lazyparser/survival-manual-for-interns.git TODO 由实习生遇到问题之后发起PR到这里。 在gitlab/github上如何寻找其他人的ID ==================================================== 使用中文输入法的时候，用户的ID提示不会在输入 @ 之后自动提示出来。 用英文输入法就不会遇到这个问题。所以在需要 @ 他人的时候， 一种方法是切换到英文输入法，另一种是用中文输入法输入了英文之后， 按一下退格键，这会触发github/gitlab的ID查找功能，给出正确的结果。 开task的时候，如何正确的写标题 ==================================================== 比较常见错误是直接写（我要）做什么事情。这是错误的。想象下我每天看所有人的标题的时候能够看出来什么。 要求的做法是 【在X月X日提交YYY形式的交付物/完成YYY】 如果是一个 meta task，也就是说需要分解成不同的具体执行任务， 那么可以在标题的开头加上 `[meta]` 的字样。 如何正确的提问 ==================================================== 遇到问题以后，需要在y站开issue，简单而清楚的描述你遇到的问题并@你的上级或同事，最好配有截图或运行log以便他人帮助你解决。 注意不要在私下里询问技术问题，因为你遇到的问题别人也可能遇到，养成在y站中提问的好习惯，不仅可以帮助自己解决问题记录问题，也方便了其他实习同学学习参考。不要害怕去提问，问题也是宝贵的财富。发现问题，解决问题你才能变强。 如何正确的报告bugs ==================================================== 项目运行时往往会产生各种bugs,明明是按说明来的，居然报错了...尝试半天没有解决的你准备向小组报告这个bug, 下面我们说明一下怎样正确报告bugs 1. 贴出error log—error log是最直观描述错误的材料，通常debug的过程都需要参考error log来进行，比如缺少安装某个库、多打了一个空格，error log可以直接给出大部分错误产生的原因，有利于其他人快速了解问题，给你修改建议。 2. 描述bug出现的过程—一些简单的问题往往会因为没有清晰的描述而变得难以琢磨，“电脑突然黑屏了，进不去系统”，这种问题抛给任何一个专家都是令人头疼的，详细描述bug产生的过程和你做的操作，“更新了显卡驱动，然后电脑突然黑屏了，进不去系统”，更仔细的会描述帮助问题定位更加精确，有时多几个文字就可以大幅减少处理问题需要的时间。 3. 提供bug的复现步骤——“能复现的bug都是好bug”，bug的复现步骤往往是判断bug属性的关键，如果bug能够复现，那么大家都可以参与到bug的解决中来，产生不同的思路和尝试，提出不同的解决方法，高效解决问题。（如果不能复现，那么这个bug对你来说是很危险的，请仔细查看有关说明和代码，必要时尝试不同机器。） 4. 提供bug截图——无图无真相，请在报告bug时配上bug的截图或照片 如何正确的进行情报收集（Google tips） ==================================================== 学会利用专业平台进行资料搜索与问题交流，站在巨人的肩膀上去看远方。 Google的访问方式请自行百度学习VPS...，喝茶去了.... 如何做进度报告 ==================================================== TBD ZIP文件的跨OS操作注意事项 ==================================================== 压缩和解压缩的文件的时候注意，如果是zip文件，中文文件名可能会有乱码。 中文 windows 默认会使用 GBK 编码文件名，macOS 和 Linux 使用 UTF8。 解决方法在 Linux 下是使用可以指定文件名编码格式的解压命令行工具。 FIXME： macOS 下的我还没有找到。 所以保守的建议是：不要使用中文文件名，使用英文名。 如何正确简洁的复制B站的链接 ===================================================== URL 是浏览器跟WWW服务器之间的通信协议。 URL 中从问号开始的部分，参数，这部分参数，有时候是用来跟踪用户会话，而不是用来唯一标识资源的。 例如如果直接在B站搜索视频，可以得到类似 https://www.bilibili.com/video/av83277184?from=search&seid=1289633595657602924 这样的链接。而实际上在B站，问号和问号后面的是不需要的，可以改成 https://www.bilibili.com/video/av83277184 在内部系统的时候贴的可以更加简洁。而对于B站而言，有一个约定俗称的编号系统就是av号，可以进一步所见为 av83277184 就足够唯一的表示出来要指称的对象了。在满足【原则08】的基础上做到了最大程度的简洁。 中文输入法中全、半角的正确使用 ==================================================== 日常工作中技术文档的撰写普遍会有中、英文夹杂的情况。在中文输入中，需要注意全角和半角概念。简单而言， ，在英文输入法中，一个英文字符和标点符号 （如 “a”）所占的位置是半角；而在中文输入中，一个汉字所占据 的位置等于两个半角，称为“全角”。默认状态下，英文输入法和中文输入法都是半角的设置，这意味这两种输入法 下所输入的英文字符、符号和数字，都只占据一个“半角”位置。 但是，在中文输入法下，可能会因为快捷键的误操作（如： shift + space ）导致全半角误切换，切换后，输入 的英文字符、符号和数字就会被当成汉字处理，看起来占据了“更宽”的位置，例如，从半角的“hello world123” 变成“ｈｅｌｌｏ　ｗｏｒｌｄ１２３”。这看起来是很别扭的，显得很不专业。 因此，在写文档时，一定要注意中文输入法中全、半角的正确使用。 文档中粘贴超链接时，前后务必加空格 ==================================================== 文档中的超链接是用来方便读者深入阅读的，读者要么直接点击链接跳转到相关链接，要么会选择复制粘贴链接 在浏览器中访问。无论是哪一种情况，编辑超链接时，在其前后加上空格都会极大地方便读者。 例如： 这样引用超链接 https://github.com/lazyparser/survival-manual-for-interns 前后加空格是好的做法； 这样引用超链接https://github.com/lazyparser/survival-manual-for-interns前后不加空格不是好的做法。 写中英文夹杂的文档时，在中文和英文之间加入空格 ==================================================== 这样做能够方便编辑器发挥其拼写检查功能。 在使用 Word 编辑文档时，将常用的术语加入“字典” ==================================================== 这样做能够方便编辑器发挥其拼写检查功能。 拿到新电脑后可以做的事(从开箱到 llvm) ==================================================== 1. 进入系统后安装wsl/wsl2（默认ubuntu18.04），安装方法可以参考这篇官方文档 https://docs.microsoft.com/zh-cn/windows/wsl/install-win10 2. 从开始菜单进入安装好的ubuntu系统中，进入 ``/etc/apt`` 更换软件源为国内源(以阿里云软件源为例),并更新软件列表: :: $ cd /etc/apt $ vi sources.list //vim中输入 :%:cn.archive.ubuntu:mirrors.aliyun:g ,进行查找替换源 $ sudo apt-get update 3. 安装git、gcc、g++、cmake、make、ninja-build :: $ sudo apt-get install git gcc g++ cmake make ninja-build 4. 导入自己的ssh密钥(参考上方) 5. 克隆llvm项目到本地(没速度的话尝试去掉https中的s，或者从y站镜像clone) :: $ git clone https://github.com/llvm/llvm-project.git 6. 进入llvm-project，准备编译llvm+clang(由于wsl只能运行在系统盘，注意你新电脑的系统盘大小，建议剩余100G) :: $ cd llvm-project $ mkdir build $ cd build $ cmake -G "Unix Makefiles" -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi" ../llvm 7. 编译llvm，并记录你的编译用时 :: $ time make -j4 8. 验证llvm是否安装成功(参考 https://llvm.org/docs/TestingGuide.html ) :: $ make check 【1】 我曾经指导过的一位实习生，每次要解决跟我（upstream）的repo不一致时候，都是删除自己的 fork，重新 fork。提交了多少次 PR 就删除了多少次。 更好玩的是，他还教会了周围的还处在迷茫中的实习生，一度成为了。 Remote rejected (shallow update not allowed) after changing Git remote URL =========================================================================== 如果是为了带宽问题用了 `git clone -depth x` 选项，那么 push 到别的remote的时候会遇到 :: ! [remote rejected] master -> master (shallow update not allowed) 解决方法： https://stackoverflow.com/questions/28983842/remote-rejected-shallow-update-not-allowed-after-changing-git-remote-url 报告交流用的PPT/Slides需要准备中文和英文版本 ======================================================================================= 我们平时的交流，多数是讲中文，用中文的PPT。但是，现在也越来越多的有英语世界的交流。 有的时候需要用英文演讲英文slides，有的时候是需要提供几页的ppt素材给合作伙伴去国外做技术分享。 因此目前会默认要求所有的对外公开的 slides，最好自己准备全英文的版本。 同时英语要多多练习。说不定哪天实验室就来了英语世界的技术人员交流（常有的事情）。 如何为一个新的项目建立 CI/CD 机制 =========================================================================== 凡是由于项目交付压力在深夜掉头发的人，都会知道一个自动化的、有效运行的 CI/CD 机制是多么能够抚慰心灵。 以 Clang/LLVM 项目为例，介绍如何自己搭建一个 CI/CD。 **0x00 准备工作** 首先，代码需要有版本管理。而版本管理现在基本上都是 git。其他管理工具都是蕾丝，只要有命令行工具就OK。 **0x01 完成敲回车就一条龙完成的脚本** 第二，现在的代码仓库是需要能够被手工构建成功的。如果本身自己手工都还没有构建成功，就先停下来手头的工作， 把这件事情做好。可能有同学会问，有很多组件和函数都还没有实现，怎么办？答案是写一系列的空的函数， 能够保证其他部分可以正常被编译，最低要求是可以被编译构建成功，稍微进一点的要求是可以有一个固定的正确但是没用的返回结果， 让其他部分的构建和测试用例可以完成。 手工可以构建完成之后，接下来就是写到一个脚本里。以 Clang/LLVM 为例，一般的流程是： :: # clone # 下载 # checkout # 到正确的分之 # status # 检查是否 clean # git submodule update -r -f --init # 如果有子仓库 mkdir build cd build cmake -DXXX_XX=YYY .. make -j $(nproc) make check # or make test 就是帮助运行回归测试 在一个新开的 terminal 中，完成以上一系列行为。然后用 :: history 命令，复制下来，到一个 build.sh 中，编辑。 简单但是非常重要的一个验证是，切换到另一个目录下，运行 build.sh 看看是否可以成功构建。如果可以，那么进入下一步。 到目前为止，已经有了一个比较好用的脚本，可以方便的进行构建了。 **0x02 只有一个 git remote** 假设没有 gitlab 也没有 github， 所有人的代码都是（或许有人工 review 后） push 到一个分支，假设是 develop。 那么至少可以做自动化的是推送后的构建测试。写个 for 循环： :: # Clone # clone # 下载 # checkout # 到正确的分之 # status # 检查是否 clean while sleep 600 # 每隔10分钟 do git pull ./build.sh || notify-or-send-mail done 就完成了最为简单的推送后CI测试。 没错的，就是这么简单的。没有什么花哨的概念。 核心是： （1）挂了有人看有人及时修复，主线分支不修复好，禁止推送新代码； （2）build.sh 跟这个循环的内容都需要跟项目的开发变更一起更新。 **0x03 使用 gitlab CI/CD：写配置文件** 有了上一步的脚本之后。剩下来的工作就简单了。 注意，这里的做法跟官方和网上常见的做法都是不同的：这里教授的是 **个人或十人以下小团队** 从没有 CI 到有 CI 痛苦和麻烦程度最小的途径。 等 CI 建立起来之后，可以再琢磨如何使用更为正统和 docker 的方式来进行。 如果项目有一个 gitlab，那么在项目根目录放一个 .gitlab-ci.yml 这是例子 :: $ cat .gitlab-ci.yml before_script: build: stage: build tags: - rvv-llvm # 用来指定构建runner的 script: - ./build.sh $ cat build.sh set -e mkdir build cd build cmake -DLLVM_TARGETS_TO_BUILD="X86;RISCV" -DLLVM_ENABLE_PROJECTS="clang;compiler-rt;lld" -G Ninja ../llvm ninja ninja check **0x04 使用 gitlab CI/CD：配置 runner** 然后就是设置 gitlab-runner。 首先假设是 linux。别的系统请自己折腾。 按照 https://docs.gitlab.com/runner/install/linux-manually.html 国内请务必直接（可能要海外）下载一个二进制然后就开始干，不要用 apt 来安装，很慢。 之后进入项目的配置主页（需要是 gitlab 这个项目 maintainer 以上的人） 项目页面左下角 Settings - CI/CD 展开 Runners 看到 :: Set up a specific Runner manually Install GitLab Runner Specify the following URL during the Runner setup: 【你要复制粘贴的网址】 Use the following registration token during setup: 【一会儿要用到的token】 然后按照 https://docs.gitlab.com/runner/install/linux-manually.html 和 https://docs.gitlab.com/runner/register/ 进行注册。注册时候就要用到刚才显示的网址和token。 注意会要求输入 **tag** 这个 tag 是跟上文中 gitlab-ci 文件中的 tag 对应的。是 runner 的筛选机制。 同时运行环境的时候选择 **shell** 。注意这里的前提是简单，而且所有有推送权限的人都是可以信任的。 否则有 git 推送权限的人有可能控制 shell 模式 gitlab runner 所在的机器。 当然，这里我们只是个人使用或者微型团队，此类RCE问题不考虑。 之后并不会立即启动，而是需要使用 :: sudo gitlab-runner start 类似的命令（我记不清了）来启动。启动之后就会看到一些输出了。同时请务必在 tmux 中进行，避免掉线。 接下来就可以从repo页面的左边的 CI/CD - jobs 看到运行结果了。 一开始可能会有一些问题，常见的有： 没有 runner，卡住。（1）查看runner跟gitlab站点的通信时间，是否成功链接上了；（2）查看是否 tag 是匹配的。 脚本执行过程错误。恭喜，这里环境就已经构建好了。根据错误提示，判断是代码提交的bug（那就开issue）或者解决脚本自己的bug（分析、修改） **0x05 搞定了，然后持续维护起来** 坏了就赶紧修。这是CI/CD的第一原则。可能也是唯一普遍使用的原则。 TODO 加入更高级和PLCT实际使用部署的环境。 如何快速有效的处理开源社区邮件列表中一天超1000封的邮件洪水 ================================================================================================================== 首先，不要慌。 Don't Panic。 第二，使用 GMail，或者其他有着大容量的邮件系统。 第三，使用 GMail 中的 filter 功能，将邮件按照邮件列表进行分类，同时可以选择不丢弃到垃圾邮件箱。这点比较重要。 第四，使用过滤器将自己关注的发信者（例如直接 review 你的 patch 的 maintainers）过滤出来，加上「重要」或者别的标签，方便查询。 第五，使用 Thread 模式来查看邮件。要知道邮件列表做review的时候，常常一个 patch set 是 00/99 这样的规模。而 reviewer 会很仔细的一个一个的回复。使用 flatten 模式按日期排序的话，你会疯掉的。 第六，明确自己的目标，根据标题快速删除掉/已读掉自己不感兴趣的方向的邮件。 第七，对于自己感兴趣的邮件，一定要先阅读 cover letter。也就是编号为 00/xx 的邮件。这是patch作者手工写的对自己的 patch set 的介绍。 第八，使用 Thunderbird 的离线收取模式进行收取，再批量进行删除操作，再上线。这么做其实是由于国内的高墙，导致很多时候批量操作会失败，尤其是当你已经有了一个很大的邮件池子的时候。 第九，每天都要筛选和学习。隔几天一看，如山的规模，就丧失斗志了。 使用Python的时候，一定记得创建 venv / virtualenv ================================================================================================================== **实际上这已经重要到可能超越了技巧，而是形成了规则了。** 我们在开发中会借助各种开源软件工具，或者历史遗留代码。不同的代码中会有不同的操作系统要求、libc版本要求、工具链版本要求等。 python 其实也有要求，例如python2和python3的需求。尤其是如果做自动化测试又做深度学习，那么相信你的机器很快就会遇到python环境崩溃的问题了。 这里的一个血泪教训就是所有的python项目都需要使用 venv 来进行，同时注意避免引用系统的python库。 FIXME：或许我需要做一期视频讲座，邀请几位同事来镜头前现场流泪控诉下自己在两个项目交替进行的时候被浪费掉几十个小时的时间的。 如何交换WIP代码：使用 patch，不要直接传递文件 ================================================================================================================== 有时候我们团队开发需要相互交流代码。最为正式的方式是发起 PR / MR，在标题中注明 RFC 或 WIP。这里 RFC 是 req for comments 的意思。 内部松散一点的代码是可以通过push到个人的repo或者branch上进行交流的。这也是我推荐的方式：在repo中的代码是活的，脱离了repo的代码是死掉的尸体。 在老派的社区中，以及偶尔的外部开发者之间，我们使用邮件或者微信、QQ等形式来发送的时候，可能推荐的方法不好使用。那么这时候就需要用 patch。 patch 可以用 git diff 或者 git format-patch 来生成。 patch set 是对应着一个 branch 上一系列的 commits。用 patch set 组织代码更加清晰，patch更小，容易 review。同时， **要注意，每一个patch都要求不破坏项目的构建和回归测试，不然的话，后续的 git bisect 会造成干扰。** patch 还有一个我们非常看重的要素，就是注明了作者是谁。而直接传递文件，对于调试和确认两遍的代码是不是一致，带来了巨大的隐患。同时，也无法将贡献者的荣耀落于作者之上。 对于员工是严格禁止直接文件来回拷贝的。对于实习生，我们的要求要宽松一些，尽量使用 patch。LV2以下员工如果 git 操作不熟练，或者传递的是 docx 等二进制文档等，那么则通过文件名添加版本号和文件内的修订记录来进行区分和跟踪。 已经提交了 PR/MR 的 branch 和 repo，避免删除或撤销 ================================================================================================================== 已经提交MR或者PR给 mentor/reviewer 审核的代码，默认是禁止撤销的。尤其是已经被review、留下了评论意见之后。 撤销了。我花时间写的review意见就悬空了。这样对于我在内的任何reviewer都是不礼貌的。 在 upstream 社区做事尤其要注意。 删除自己的仓库也是同样的，会导致评论针对的 branch/commits 丢失，是不礼貌的。 出差/高铁/杭州东站 ================================================================================================================== - 出发层进站之后，A28那一头有报销凭证的机器，共5台，平时没有人排队。比B11旁边的自动取票机要好很多（B11那里总是排队）。 - 注意出发层站内的改签窗口（B11旁边），八点前不开门。这是唯一的改签地点。如果到的很早，那么技巧是（1）手机订票；（2）不要取报销凭证；（3）进站前或快到的时候用手机改签，可以改签30分钟后的车次。 - 有广发银行还是某某银行的VIP休息区，可以休息（不过好像人比较满一直）。 - 星巴克在 B28 方向。 出差/高铁/上海虹桥 ================================================================================================================== - **一定要注意出发层的洗手间是有两个出入口。** 带小孩子的同事尤其需要注意，极其容易在厕所出来的时候走散。 - 报销凭证建议出发层刷完身份证之后再取，临上车或下车之后再取，方便改签。 - 从张江高科去虹桥非常远，请至少保持2个小时的通勤时间。地铁稳定在 1.5 小时内到达。 B站评论/讨论技巧 ================================================================================================================== - B站现在可以识别时间轴。在评论中插入类似 ``23:33`` 这样的信息就可以得到一个跳转到对应时间的 link。 发邮件等的文件名 ================================================================================================================== - 如果是报告的录像记录，那么使用 ``202011xx - 姓名 - 报告题目`` 的形式保存，发给我。 - 如果是给行政秘书或者mentor发送，是信息收集性质的，那么不要写 ``合同.zip`` 这样的名字，而是用 ``你的名字-具体事项.zip``。这么做的好处是我可以直接从邮件附件中下载，不需要修改文件名。如果同时要收集30个人的信息，每个人都用 ``信息.zip`` 发给我，我就疯了。 创建一个仓库，整理自己的公开报告 ================================================================================================================== 各位有兴趣可以把自己的报告的链接整理整理，像 https://github.com/lazyparser/talks 一样建立一个GitHub repo。将自己做的报告从 PLCT-Open-Reports 中复制一份出来，方便以后写简历或者跟人介绍的时候使用。 我从2016年开始记录的。这个想法来自于 jserv 老师，模仿自 gh/jserv/talks macOS ================================================================================================================== Tips macOS的输入法记得关闭touchbar推荐，不然会卡顿 ================================================================================================================== 下一个技巧，欢迎提交 Pull Requests