那些大写字母公司一个都不认识......
过段时间也要准备求职, 看完压力山大
记笔记: 拉钩快不行了, 用 boss 直聘

前两年不是有过调查了么, 23K 以上

https://paste.ubuntu.com/p/Rrjf3k4ZD4/

看了

@est #14 有蔷在, 再差也差不到哪去, 我也就看看热门的, 配合 hackernews 了解点新鲜东西, 没太多时间划水

老毛桃 大白菜 完美 PE 的时代已经过去了, 现在很多假的, 这俩域名貌似都对, 但是我都查到毒...... 不敢用了, 还老是给我改首页或者加开机广告, 就算做了那个推广任务去掉广告, C 盘里也有垃圾文件没清除

这几年已经是微 PE 和优启通的时代了

最近那么多 "如何看待 XXXX", 就知道多不多了

quora 我也用不习惯, Reddit 是真不错

减少划水时间才是良方

很多笔记应用都带多种浏览器的 web clipper 插件 https://chrome.google.com/webstore/search/web%20clipper?hl=zh-CN&_category=extensions

虽然我看了一眼你的要求反而有点想 read later 那些, 比如 pocket 什么的...

@whoami9894 #15 你说的对... 貌似没什么问题不用改了... 缓存看心情

@whoami9894 #9 Failed requests 那个如果全是 Length 的一般不用管, 说失败是因为你发的请求返回结果长度变化不一定是真错, 如果真错, 你在状态码或者 connection 层面就检查到了
如果只是单表 select, 这性能不太正常, 是不是没命中索引 (explain 看看)

别太指望数据库的缓存, 可以考虑给函数拉个内存的 lru cache, 必要时候 redis 做层缓存可以进一步提高性能, 也更灵活点. 看你不同并发数量时候 Time per request 差距那么大, 应该瓶颈就是数据库那头了, 也可以考虑连接池开大点.

测试时候并发数盲目高了没什么用, 实际情况下的当前 qps 是比较均匀也不大可能到 700 的, 毕竟一天八小时里才四万人并不是太高, 除非你还有个抢课系统, 那个是真的坑, 稍微扛不住就被 DOS...

我对测试的理解也不是太深刻, TPS 和 QPS 这些只做个参考没法预测真高压下的复杂环境, 再说八小时里就算不均匀分布, 学生在中午吃饭一块修改并发数也是有限的

简单地说, 目测数据库操作部分还有可以优化的时间, 查询的函数或者表结构那边, 至少搞下缓存也是好的. 目前的性能对学生来说问题已经不大, 打好日志真机上线试试看

更纱黑体
等宽更纱黑体

我几乎开源免费的大都试过了, 实在是......

最后只选汉字等于两字符宽度的了, 别的再好看, 对不齐有什么用

teamviewer 近几年抽风老说我非个人使用了
anydesk 体验不如 teamviewer 稳定快速, 勉强用用还不错
向日葵... 我甚至连为什么不用它的理由都给忘了

猜测解释器不一致

import sys
print(sys.executable)

看看二者是不是同一个

对后端不太熟, 看这份结果问题不大, 响应时间很多超过 1 秒有分析过哪里 block 的么, 比如数据库语句的优化, 如果是网络传输的话就不算问题

做好 Get 请求的缓存, Post 的可以模拟下更高并发数, 一般情况下数据库比想象中能抗的多, 毕竟用户量就那么点, 真扛不住改 MQ 那种设计, 或者加机器, 或者数据库读写分离, 或者冷热数据分库

以前上学用的学生系统, 修改信息时候一两秒的等待还可以接受, 只要别失败的时候让我重填就好, 以前用的教务处 MIS 甚至让我修改的时候说当前队列拥堵, 让我排队等待多少秒... 弄得跟打游戏似的, 不过这种设计对低配环境的并发限制还挺有用的(非常态高并发的情境下节省成本).

饮食稍微注意一下, 平时酌情锻炼吧
然后, 睡前不要玩电脑玩手机, 直视可见光源坏处还是蛮多的
视情况严重程度酌情考虑褪黑素, 年轻的话还是少吃, 不是习惯性熬夜自身分泌的就够用了

习惯性晚睡很难调整, 尤其是还分困而不眠和压根不困两种情况...

默认终端如果不想折腾 还是 git-bash 省心... 很多常用 linux 命令也兼容, 编码也 ok
看截图似乎是你默认 cmd 启动不起来了

https://github.com/nvie/gitflow 一把梭

不过看你说的, 好像是 CI / CD 方面的东西...

一楼先赞为敬

很多人用框架的根本原因除了不重复造轮子, 最大的可能是: 自己造半天还没人家造的好...
看个人习惯吧, Instagram 当年选 Django 我猜测可能也是为了最快速度占领市场, 开发成本(很多公司刚创业时候的成本很大部分还就是开发人员的薪水...)有限的前提下把产品做出来推出去, 当初不到十个人做出一个产品来...
等用了一段时间, 可以按自己需要各种魔改就好了, 很多人喜欢微框架也是方便魔改不动随时替换, 微服务也这道理
网上不推荐的可能是学习成长过程中过分在意使用框架, 而不去关注底层思维的掌握, 毕竟很多语言上手以后, 用框架都是打开文档就使, 没人会去背诵一大堆函数名称作为工作经验

Users on the GitHub website are able to "star" other people's repositories, thereby saving them in their list of Starred Repos. Some people use "stars" to indicate that they like a project, other people use them as bookmarks so they can follow what's going on with the repo later.

@Scvoet #2 你用法没错误啊... 就是考虑到国内人口基数太大, 马太效应有点跑偏了, 不过大多数情况问题不大, 搜索为主


@OhYee #1
点赞以后回帖貌似触发 CSRF 没发出去... 已经忘了当时怎么回帖了, 重新回一次...
感觉你说的挺对的, 确实没必要降权和 unstar, 当时被那群老外的帖子带节奏了, 现在感觉已经适应了, 反正也没谁指望 Github 的推荐系统做到太个性化, 毕竟初衷就不是搞这个的, 真需要的时候, 微软也会自研一套合适的(现在其实感觉比前几年推荐的靠谱多了), Github 还是越纯粹越好