V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  flyingghost  ›  全部回复第 6 页 / 共 28 页
回复总数  551
1 ... 2  3  4  5  6  7  8  9  10  11 ... 28  
站在面试官的角度想问题。

——你喜欢受试者叨逼叨滔滔不绝吗?
——不喜欢。面试节奏应由我控制。
——那受试者讲太简略讲不清楚怎么办?
——没什么讲不清楚的。你说线程池我自然知道并发和必要的同步手段,你说 https 我自然知道证书、服务器配置等细节。我不问太细,只有几种可能:
1,我觉得没必要。
2,我心虚不敢问太细。
3,我想问更多可是真的没时间了等下还有会。
——会不会担心遗漏了关键信息?
——首先,受试者应该充分梳理并概括自己的亮点和优势,这也是能力。连主次都分不清,连信息传达都做不好,逻辑能力有问题。其次,真正必要的信息即使受试者不讲我也会详细问,这样才能挖到受试者的能力边界(也就是为什么总要面试造火箭的原因),还能打击假冒伪劣(只会嘴炮的云程序员真的不少)。


站在受试者的角度,只有一条:
投面试官所好,赢得认同。
之后才是自己了解和抉择的过程。

只有一种例外,受试者才需要主动说更多:
面试官不合格,是既不会面试又不会聊天的半封闭技术男。你不说话,他都不知道该问什么,动不动场面就寂静得尴尬,问的问题也没有目的性。这时候目标就变了:你不但要表达自己,还要担负起控制面试节奏的责任。。。
2019-11-01 15:22:54 +08:00
回复了 oracleHe 创建的主题 Linux 求助,请教下 https 的配置问题
直接把域名放出来好了。。。

另外,curl -v 一下把日志贴上来也可以看出一些信息。

另外,win 电脑的话去 ie 的设置里勾上“使用 TLS1.1、1.2”试试。

总之看起来像兼容性问题。
2019-10-30 09:58:35 +08:00
回复了 xinyu391 创建的主题 程序员 CSDN 作死啊,博客默认背景晃瞎眼
shi 山大魔王作死啊,把盛 shi 的碗换成黑底蓝点的了,真是看着难受。/狗头
2019-10-24 16:56:09 +08:00
回复了 argc 创建的主题 程序员 为什么程序员的女朋友都好看?
var flag = true;
if coder.hasGF { // 所有人都 false
return flag; // test 方法返回 true

真实的故事.gif
2019-10-23 10:47:30 +08:00
回复了 bbman 创建的主题 程序员 想屯波书,大家有什么推荐的吗?
@zhuangzhuang1988 买过就是读过,有什么问题?/机智
2019-10-23 10:46:17 +08:00
回复了 CivAx 创建的主题 Python 有 Python 大佬帮忙看看这个 [0] 是什么用法吗
"Backup": [
硕大一个 [ 号已经说明这是一个数组了。
2019-10-17 15:58:36 +08:00
回复了 raywong 创建的主题 Go 编程语言 请教 Go 并发上传多个文件问题
你这测试。。。根本没测到点子上吧?业务逻辑设计思路也有问题。

先来梳理一下上传文件有哪些瓶颈。

客户端磁盘读 - 浏览器单站点连接数 - 客户端网络速度 - 服务端网络速度 - 服务端应用处理速度 - 服务端磁盘写
对于单客户端来说,磁盘读一般不会造成瓶颈,更多的瓶颈是网络传输上。
对于服务端来说,网速很重要,但磁盘写入也重要了,因为它要并行处理多个客户端。

所以单机测试的话,最大瓶颈容易出在网速。这时候分多个协程是没有任何帮助的。
多机测的时候,客户端网速一般可以不考虑了,带宽窄但人多啊。这时候瓶颈容易出现在服务端网速 和 服务端磁盘。

真实压测,当然要用多 client 一起测,尤其对于上传文件这种场景来说。

但是多机天然就多连接,服务端伺服多个连接天然就并发了。有没有必要把 n*client 个上传过程再拆一步,n 个 client 每 client m 个文件变成 n*m 个连接 /goroutine 呢?这才是业务逻辑需要考虑的。

因为这直接影响到一个重要因素:传输失败率。
很多真实场景下,和服务端维持长期稳定传输是一件容易失败的事情。多个大文件捏一起,总时间更长,失败几率更高,无效传输时长更多,整体来看有效上传速度是降低了。文件越大越明显。
常见的办法就是多文件分开多个链接传输。甚至对于巨大文件,客户端直接分片给服务端。
优点是失败率降低吞吐率提高。缺点是上传逻辑更复杂,占用服务端连接数更多。

以上都是单点 server 的情况。多点的话又是另一种思路。

另外吐槽一点,MultipartForm 上传多文件已经是古代技术了。应用层处理需要的请求缓存和内存占用都会大一些。偶尔场景少量小文件传输无所谓,大量的,体积大的文件,我更倾向于 rest 风格的单文件直接 PUT。
2019-10-16 16:35:34 +08:00
回复了 sxw11 创建的主题 程序员 Github 上 Java 的每日 Trending 真的是让人无语
一项事物,如果足够小众足够专业,那 Trending 一定都干货满满。比如知乎刚上线那会。
当它拥有了一定知名度,引起大量小白疯狂涌入,那 Trending 一定难看的要死。倒不是专家都死了,而只是被淹没了而已。比如现在的知乎,现在的 github 等。
当它进一步发展为吃喝拉撒一样的日常,那 Trending 又会好看一些。那时候受众大到稍微内聚能量不足的玩意根本爆不出来,而能从浩淼的信息里爆出来的无一不是真正的内容炸弹。比如现在的微博、微信。

万事万物皆通此理,某项技术也是。

这么通用的事物发展规律都看不出来,浮躁啊。。。悲哀啊。。。/自动狗头
2019-10-16 16:25:06 +08:00
回复了 178620086 创建的主题 NGINX nginx 如何多站点配置屏蔽 geo?
前置一个 nginx 反代专做过滤。
2019-10-09 12:32:34 +08:00
回复了 prenwang 创建的主题 程序员 为什么一些我们认为很棒的软件工具被慢慢放弃了
我来举几个稍微恰当一咪咪的例子吧。
Google Reader,心中永远的遗憾,下线后世界范围内哀鸿遍野。在这点上绝不原谅 Google。
Picasa,前面的同学提过了。
G+,挺可惜的,环的概念稍显复杂,但其实工程师们准确描述了真实社交的数学模型。成也萧何败也萧何,工程文化真的没有社交基因。
Delicious,书签+社交的王者,和 GR 在细分社交领域几乎同等。商业化运作失败( Yahoo 收购的就没一个好下场,当然 Yahoo 自己也可以在这个榜单内)。
FlashGet,一统江湖的优秀下载工具,开发者玩魔兽去了。。。否则下载工具领域也许根本没有迅雷什么事。
饭否,因为不可描述的原因。。。
快播,因为众所周知的原因。。。
MSN,微软的傲慢玩残了这个曾经世界级的 IM 工具。
WPS,没跟得上 windows 时代的王者。再跟上来已经成了边缘小透明。现在仅靠政策倾斜活着。
ACDSee,特指 3.2 版本。后来的越来越屎,在我心中早就死了。
Flash,为互联网带来丰富多样性的技术,死于自己的坑。当年那些闪客们现在都去哪里了?
飞信,手握巨大资源,胸藏宏伟蓝图,脚下时代机遇,打出一手烂牌。鄙视。

再追加一个:
艾德·史塔克,卧槽!纳尼!什么鬼!不会吧!/狗头
2019-09-19 11:47:48 +08:00
回复了 smallpython 创建的主题 程序员 有没有专门为程序员打造的背单词 app?
英文:程序员专用翻译
bug: bug
IP: IP
MAC: MAC
web: web
Java: Java
摔!这什么破词典!
我猜是图标缓存出错了。
搜一下 mac 清除图标缓存试试。
噗嗤。。。不留意还真没发现是 3 个应用。。。
我司小服务直接海外 DNS 解析到香港,香港转发国内速度还行。
2019-09-17 14:33:45 +08:00
回复了 xdtr 创建的主题 Linux 求占内存少的 Linux 发行版
我的虚拟机从来不开桌面。。。命令行跑跑可以了。

如果非要虚拟机跑桌面的话。。。

话说槽点难道不是 8G 跑 chrome+JB 系内存大户还要上虚拟机太勉强了点吗?
这。。。为啥必须二元论单选题?
就像问“你们吃饭是用筷子还是用勺子”一样,难道不是同时右手筷子吃面左手勺子喝汤吗?

一边给相对他能力来说较复杂的有挑战的题目,一边时刻关注进度把控方向必要时亲手协助突破瓶颈,这应该是更常见更合理的路子。
有挑战是相对的,点拨方式也是视情况而定的,手段选择灵活一些嘛。
2019-09-10 14:37:00 +08:00
回复了 saytesnake 创建的主题 程序员 版本强迫症到底是谨慎还是玄学?
1,版本强迫症不是玄学,是经验,是历史教训,是血泪史,是成本和效用之间的妥协。
2,你家公司这是伪强迫症,是人云亦云的教条主义,是不求真理但求合规的本本主义。
我一直强调,爱心不等于免责。

爱心要积极,责任要承担。这两点要同时兼顾不能顾此失彼。

我小区有 100 栋楼,垃圾分类政策后分类的落地实施和监督检查非常困难。
业委会说我们组织义务劳动者负责监督、协助分拣吧!居民表示非常赞同。毕竟自己的小区要自己爱。
✅对门大户说我忙我懒我不够热心,我只负责付出 1%的爱心,也就每年一百万左右吧。20 栋楼我雇人包了。
❌楼下狗三说我穷但我热心啊!我付出我的 80%业余时间,负责一栋楼!但实际上落地的时候发现,狗三一个人累死累活负责一栋楼真的完全不足,这栋楼住户从此享受着平均三天轮到一次的热心服务,臭气冲天,怨声载道,又看着狗三热心人也辛苦,都不好意思说。恰巧,你在这栋楼。
✅楼上小红说我也不富裕能力也有限,我付出我 20%的业余时间来帮大家。也负责不了一栋楼,就负责我楼上的孤寡老人张大爷一家好了。平时帮大家发发传单做做宣传之类的吧。小红的付出虽然不多,但尽责,做的到位,收到了大家的好评。

从道德 /热心 /付出比例 /群众情感来看,狗三>小红>大户。大户对这事真是不怎么上心。
从贡献量角度来看,大户>狗三>小红。狗三真的很尽力了。
从对大家的伤害来看,其他人的尽责确实提供了或多或少的帮助,只有狗三造成了实质性的伤害。
从对最终事情的影响来看,大户>小红>0>狗三,只有狗三的综合结果是负面的,把一部分人的生活拖入了比分类之前更糟糕的境况。最终忍了三个月之后,大家不得不叫停了狗三的行为。

狗三问题在哪里?不是不够热心,不是风格不高,是爱心和能力和责任的严重不匹配,最终坏了事。
而小红的方式,才是更值得鼓励的,哪怕它看起来更微薄更不足道一些。

不要运动,不要虚假,不要伤害。
1 ... 2  3  4  5  6  7  8  9  10  11 ... 28  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5066 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 33ms · UTC 03:47 · PVG 11:47 · LAX 19:47 · JFK 22:47
Developed with CodeLauncher
♥ Do have faith in what you're doing.