事实上玩 Arch Linux 的都是喜欢折腾的

如果真的说人生苦短的话还是选个 Debian 系的发行版吧 😂

GitHub 这个比较严，像我们学校这种毕业后不回收邮箱的，都要求上传带有明确时间标识的学生身份证明

我把本科时候的学生证照片传上去就不给过。但 GitHub 应该不会接入学信网，P 下图改个入学年份就没问题了

想了想又觉得没有必要，自己目前没有使用 pro 的需求

正如我上面所说，校招一般一年两次，春招和秋招，秋招指的是校招的时期在夏秋季，和是否实习没有关系。

校招主要有两类岗位，正式岗和实习岗。正式岗是要等毕业以后和公司签订劳动合同后正式入职（在校生按法律规定是无法和用人单位签劳动合同的）；而实习岗随时可以入职，不需要等毕业，签的往往是一个可以随时终止的短期合同（不是劳动合同，具体算什么我也不清楚，可以咨询专业的法律工作者），一般最长不超过一年。

一般来说，每年的秋招，主要的岗位是提供给次年毕业的应届生的正式岗位，但也可能会有少数的实习岗位。这些实习岗位一般没有转正机会，主要面向的是想要找短期实习机会的年级较低或者大四已经保研/找到其他工作的学生。。

而春招主要面向的是次年毕业，打算今年暑期参加实习的学生。这种暑期实习一般有转正机会，但这个机会也是需要努力争取的，要看实习期表现，还有面试，但是比直接参加秋招要容易些。春招可能会提供少量的面向当年毕业应届生的正式岗位，比较少，相对秋招难争取。

正式入职的工资一般会在发正式岗位 offer 之前谈

1. 21 年应届生最好参加今年秋招，除非你想考研。每年都有人因为某些原因没有在秋招中拿到满意的 offer，然后参加转年的春招，但是往往岗位和 HC 的数量都偏少，更不容易拿到满意的 offer
2. 肯定要等你明年拿到毕业证才能正式签订劳动合同并入职，但是毕业前可以商量一下实习。实习工资比较低（我当年是每天 200），而且交的是 20% 的劳务税
3. 看 jd 描述上怎么写的。一般秋招不招实习生，但是想我上面所说，一般毕业前可以安排实习。
4. 三方是具备一定法律效力的，能签最好签。但签了三方不算正式入职（签了合同才算），公司仍然可以撕毁三方，而且只需要承担少量的赔偿。然而个人撕毁三方，承担的损失远比公司要大，如果不确定要去这家公司，最好三思。
5. 秋招只是发生在夏秋季的校招，是不是实习要看 jd 描述。
6. 公司安排的实习最好去。一方面，正式入职后可能要花一段时间适应工作，建议先实习热下身；另一方面，一般学校是允许学生自己找实习替代学校统一安排的实习的，自己找的实习有工资拿（一般学校找的实习只有少得可怜的补贴），何乐而不为？

相比之下，troff 语法就比较友好。比如我需要 "foo.bar"，其中 "foo." 加粗，".bar" 之间无空格：

.BR foo. bar

或者：

\fBfoo.\fRbar

Markdown 就做不到 😂

等等，楼主说的是对中文不友好？那打扰了，troff 无法原生支持中文，想要显示中文每个字符都要分别转义

这个应该是借鉴了 Kotlin 的 data class 😂

感觉这些什么七夕、214，都是淘宝等商家为了忽悠消费炒作起来的，十多年前根本没听说过有人过这个节日 😂

夫妻的感情靠生活中的点滴积累，而不是节日送礼。

有什么想要买的东西，商量好直接买就是了。非要等到节日，还得处心积虑地猜对方心思，未免太累了

起名并不重要，完全是个人喜好问题。一般来说只要足够简洁、易读，避免和同类项目重名就没问题。

如果只是为了在 GitHub 上面更容易被搜到的话，可以给仓库加上一些合适的标签，便于用关键词搜索。e.g. ffmpeg, ffmpeg-gui, video, ...
但是，除非这个项目足够优秀、有一定竞争力，并且解决了一些业界痛点，对于这样一个主要为了方便自己使用的小工具来说，我是不建议这样做的。

我一直没发现这个特性。因为我太懒，GitHub profile 连一页都填不满 🤣

昨晚梦见自己回到学生时代，熬夜认真写的作业被老师当众批评

原因是作业本里夹了好几只蟑螂，老师认为我是故意的，不尊重老师

全班哄堂大笑

简历中有 typo

（其实这句话里面还有语病，后面那个“一款”应该去掉）

标题里有 typo

具体原因不知，但说起国内开源环境的问题，不外乎：

• 白嫖党多，愿意帮助项目的人少，愿意捐助的人更少。开发者孤军奋战，没有动力
• 伸手党多，有主动解决问题精神的人少，能提出有价值建议的人更少。开发者需要不停地解决巨婴用户的小白问题，不解决还容易被喷，心累
• 有能力贡献代码的人都自起炉灶，搞商业化去恰钱了，还常常用不正当竞争手段打压，令开源开发者雪上加霜

为什么我说 V2EX 是重讨论的呢？一个重讨论的社区，要更完整地还原用户讨论的过程。如果内容可以随意的被删除和修改，那当浏览者看到的时候，时间线可能已经面目全非。比如一个人发表了一个有争议的观点，被批评以后修改了，这样在修改之前所有针对这一发言的回复均会处于一个过时的状态，浏览者需要查看修改历史并比对时间才能对这里发生过什么有一个全面的认识。这对于还原用户讨论的过程是不利的。当从设计上就不可修改时，时间线就会变得更加连贯和完整，因为用户只能以发表新的评论这种方式来对自己旧的评论进行勘误。

重内容的社区是什么样的呢？一个重内容的社区，会推动用户更好地展现、完善自己发布的内容，并下放给用户一定的控制权。诸如支持主题的格式、排版、音视频的插入、富文本编辑器，都有利于用户展现自己发布的内容。而提供内容修订、版本控制等功能，利于用户完善内容。让用户对自己的内容有一定的控制权，包括修改内容，以及折叠/删除一些针对自己内容的恶意评论，使得用户更放心将内容托管在这样的社区上。

所以哪些社区是重讨论的呢？除了 V2EX，还有各类以 mailing list 为形式的社区、各类以即时聊天为形式的社区等等，都满足上面说的特征。哪些社区是重内容的呢？可以说绝大多数技术类的社区形态都是往重内容的方向靠拢的，即使他们的设计者没有思考过这个问题。当然这并不是绝对的，现在很多重内容的社区加入了重讨论的副产品，比如 OSCHINA、LearnKu 的“动弹”，黑客派的聊天室等等，都是为了在保证社区内容质量的同时，为满足用户讨论需求的一个妥协。

最后声明一下，我并没有任何吹捧 V2EX 的意思，我对 V2EX 的所有评价都是基于一个客观的角度。我也曾经负责过中型规模社区从产品设计到开发落地到推广的全过程，对社区这类产品有很多自己的思考，并非无脑忽悠和人云亦云。

V2EX 是一个重在讨论而不是重在内容的社区，使用 V2EX 就像是一群人聚在一个小圆桌讨论。最终产出的重在交互的过程，而不是主题帖。发表的主题和评论不能删除，是为了让用户对自己的发言负责，说出去的话就如同泼出去的水，是收不回来的。

如果想在 V2EX 发长篇技术类帖子的话，正确的姿势是写好标题和摘要，然后在正文里面发微信公众号文章或者博客链接引流。实际的内容在自己可控的平台上，如果有修改完善文章的需求，在对应的平台上修改就可以了。

用 JSON 做实体这种操作很新颖，一定程度上也简化了开发（至少不用搞一大堆 data class 了），但并不是所有人都能接受 😂

之前在一个公司内部技术群推荐过 latke，结果一群人，包括阿里 P7 来的一个大佬，都在吐槽这一点，说这是“反模式”😂

其实在很多公司（尤其是国外公司），即使是在个人休息时间，不使用工作资源进行的开发，也是归公司所有。具体是不是这种情况，劳动合同里面会有明细条款。

业界有一些典型案例，比如去年 Nginx 之父被捕，就是因为软件版权的冲突。

出于对这类情况的考虑，一些开源组织，比如 FSF，要求开发者在为 GNU 贡献代码之前，如果正处于被雇佣的状态，需要让雇主公司出具正式的、具备法律效力的 disclaimer，声明开发者所做的这项开发与公司无关（如果劳动合同中有明确条款说明不需要这个 disclaimer，出示劳动合同也可以）。

时间应该是让开发来定，而不是产品定

理想很美好，现实很骨感。排期当然是由开发来定。但是往往有一些紧急需求是有硬 deadline 的，到时候上不了是会有严重后果的。只能申请加班或者加人（加人意味着组里的其他项目要 delay 了）😂

为啥你会有 python 代码难维护的错觉 不应该更容易维护么？

还有 JS 的相关轮子也不少啊

我大三参加校招（实习）的时候把我写的几个轮子放在简历里了，有 MVC 框架，有网络库，还有其他一些乱七八糟的东西。结果面试官大多数问都没问，基本上只关注项目经历那块。唯一一个问了的还是一个名不见经传的小公司的面试官，问我有没有将这些东西应用于生产环境，我说只有那个 MVC 框架用了，用在学校的一个项目上，然后就没后文了。

后来进了公司实习，才发现，公司有专门的基础架构部门，负责造轮子并应用于公司的生产环境。其中哪怕是一个很不起眼的小组件，可能经历了半年多的开发周期，凝聚着数十人的心血，承受着成百上千个测试样例的考验。这就能解释为什么面试官看不上应聘者在简历上面写的那些充其量只能算作玩具的开源项目了。

那时候我就问自己，作为一个初涉行业的菜鸟，我为什么要搞开源项目？

希望能够彰显自己的能力，扩大个人影响力，让自己应聘的时候脱颖而出？显然是做不到的，甚至有可能适得其反（这让我回想起知名网红程序员“轮子哥”，他在微软做面试官的时候最讨厌的就是应聘者在简历里塞一堆 GitHub 上面的垃圾项目，遇到这种他直接甩一道算法题，答不出来就滚蛋）。

希望自己的项目能够帮到别人？在某种程度上确实有可能，但作为新手菜鸟，做的项目从各方面都比不上业界流行的开源解决方案。别人为什么要用我的项目，替我踩坑，而不是用成熟的方案呢？

其实到这里答案已经很明了了。我在业余时间搞开源、造轮子，练手、锻炼自己的能力是一方面，但最主要的还是图个开心。这就好比职业足球运动员可以踢比赛赚钱，普通人也可以踢球来娱乐和锻炼身体，虽然心里知道，自己永远不可能成为职业运动员。

当然，我还是本着认真负责的态度对待自己每一个开源项目。既然花费了心血在上面，就一定要善始善终。中规中矩的代码风格、完善的文档、丰富的测试样例等等，这些都是必不可少的。至于有没有 star，有没有人在用，这些却是无关紧要的。当未来的某一天，不管自己站在什么位置，是 CTO 也好，转行的报废程序员也好，回首看看自己成长的足迹，也就可以心满意足地向那段岁月告别了。

不是 bug 吧，我的界面也是这样的 😂

先要选中文件才会加载编辑器

我司的 python 项目里有大量这种代码：

try:
    # some code...
except Exception:
    pass

如果 commit 要规范的话，一开始就要规范好

我在公司做的一个项目，看一下其他同事 commit 记录。一个小 feature，动辄几百上千个 message 为 "update" 之类的 commit。

看的我都不想好好写 commit message 了，也懒得 rebase 了

report abuse 走一波

净化开源社区环境，人人有责

这桌椅比我的强太多 🤣

现在的理财产品不就是这种形式么？你把钱给银行，让银行代替你去做高风险投资，赚了就分给你一部分收益，赔了就没收益甚至损失部分本金。效果是风险和收益都分摊弱化了。

现在好像已经全量推送了 🤔

仅仅需要闷头写代码的码农太少了，与人沟通也是工作的内容之一。首先看那是不是你的工作职责，如果不是的话，把问题路由给实际负责的同事。如果应该你来做，可以视紧急程度优先或延迟处理。但一定要及时给予反馈（哪怕甩给对方一个文档链接都可以），不能把对方晾在那里，这是职场的大忌。

在我们部门是有轮流值班的制度的，轮到你值班，哪怕是开会讲到一半、凌晨三点在睡觉、正在和新婚媳妇闹洞房，用户找到你，你都应该高优响应用户需求。如果常常响应不及时，轻则影响晋升（用户是晋升评委），重则影响绩效（领导评绩效时会参考用户意见）。

因此我们一般排期都要充分考虑到值班客服所带来的成本，一般按自己值班那天零产出来排。周末或者假期如果有重要事情无法客服，也会提前和同事商量好，倒一下班。

题解见：https://hacpai.com/article/1591734772761

再给你一条提示