V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  mcfog  ›  全部回复第 37 页 / 共 91 页
回复总数  1808
1 ... 33  34  35  36  37  38  39  40  41  42 ... 91  
2018-08-01 17:01:40 +08:00
回复了 ns2250225 创建的主题 程序员 有什么办法可以把后端服务器完全隐藏起来啊
告诉老板他看到的是前端服务器
2018-07-31 06:51:51 +08:00
回复了 baskice 创建的主题 问与答 奶蛋素的人是如何抑制吃肉的冲动的?
裹上鸡蛋液和面包糠炸至金黄
2018-07-24 18:30:51 +08:00
回复了 fov6363 创建的主题 git [git][rebase] git rebase 之后 git pull 如何解决?
@fov6363 已经那么干了的话先让他认识到问题,然后 feature 分支直接 reset 回到 origin/feature 即可,如果 D' 之后又开发了东西,rebase 回去
2018-07-24 18:10:52 +08:00
回复了 fov6363 创建的主题 git [git][rebase] git rebase 之后 git pull 如何解决?
@fov6363 我觉得你没看我的回答
2018-07-24 18:03:59 +08:00
回复了 fov6363 创建的主题 git [git][rebase] git rebase 之后 git pull 如何解决?
顺便,这个过程的实际操作是 git fetch && git rebase (取代 git pull ),现在 git pull 增加了 `--rebase` 开关可以直接用
2018-07-24 18:01:11 +08:00
回复了 fov6363 创建的主题 git [git][rebase] git rebase 之后 git pull 如何解决?
Bob 在已知 github 的状态的情况下,不应该做这个把 feature 从 D rebase 成 D'的操作(已经 push 到 remote 的 commit 不应该 rebase ),更不需要解决 Anna 的什么东西(因为 Anna 的 E 压根没有 push,Bob 也不可能得知 E 的信息)

rebase 更多解决的是 Anna 线 push E 到 github,Bob 同时(未拉取最新修改)在 D 上 commit 了变更 F 后,发现 push 失败

此时用 rebase 把 ABDF 变成 ABDEF 再 push,使 feature branch 的结果为一直线,避免增加 merge commit
2018-07-20 14:57:17 +08:00
回复了 Mac 创建的主题 问与答 怎么解决网面座椅脏的问题?
湿布擦吧,等更好的
2018-07-20 14:01:41 +08:00
回复了 ianva 创建的主题 问与答 谈谈现在前端的面试
考察能力,而非知识
考察经验,而非经历
试探对方能做什么,能力边界在哪里,是否能够突破,而不是遍历对方不能做什么,在能力边界八丈远的地方刁难对方

我觉得面试官不好当的一个很大的因素在于,作为面试官太难得到对面试质量本身的反馈了,面试和招人本身频率就低,入职与否,入职后表现和面试本身的质量相关性不高(除非入职后发现是个雷,那很明显是面试需要改进),更别说反向来说,筛掉的人是不是有面试不合理导致的误筛几乎不可能得知,要改进提高面试能力,更多只能靠自己 YY
2018-07-20 13:18:57 +08:00
回复了 banxi1988 创建的主题 程序员 向下工作法的一点思考:文档即代码
个人更倾向反过来,代码生成文档,毕竟让程序员写代码和让程序员写文档的难度差了不止一个数量级
另外,想换节点可以趁早换,或者 at livid 处理,换节点重发一样的帖子不好
你要和 redux vuex 抢饭碗,或者是想整合一起用,凭啥,建议在 readme 第一屏内显著写明白

另外点进去看了看,出 promise 不 return 造成 uncaught reject 的 sample code 不敢恭维

暂时先不 star 了
2018-07-12 11:24:13 +08:00
回复了 hansonwang99 创建的主题 程序员 高效编写 Dockerfile 的几条准则
我现在基本形成了本能反应:看到这种开头一张图,内容里面大量副标题和加粗的公众号文笔 就自动判定成垃圾水文,速读垂直扫几眼直接拉到底,看到一排链接,嗯,枪毙,再见
2018-07-11 09:57:00 +08:00
回复了 joeye 创建的主题 职场话题 工作两年想跳槽 目前手上两个 Offer 求建议
SAP?

想去互联网公司趁早,等你简历上有了两家三家非互联网的公司,再跳阻力就大了,可以再找找

不想去互联网公司的话,autodesk 风险小,另一家你得自己去调研确认是有核心竞争力而不是风口上的裸泳公司
对于高端 /稀缺的职位来说,一家公司在招聘换句话说有职位空缺这件事本身就是某种意义上的商业秘密,猎头的一个作用就是保护客户公司的商业秘密,尽量避免无谓的信息泄露

当然也有的是虚张声势,类比中国有 5 所 top3 大学,10 所 top5
2018-07-10 19:03:33 +08:00
回复了 Livid 创建的主题 Docker 未来会不会有这样的一种基于 Docker 或者其他容器技术的云服务
嗯嗯,算力分布好做,数据分布难做,事务分布 (还要自动地,业务无关地) 那是地狱难度了
2018-07-10 14:58:51 +08:00
回复了 pheyer 创建的主题 macOS Mac 下这么多窗口管理 app 有居中半屏的功能却比较少见
window tidy / mosaic
@RoyGo "以上"
想到哪写到哪儿

1. “时间预估” 对于外包和公司自有项目的意义和含义是不一样的。前者是真的雷打不动的 deadline,而且基本不能以客户需求变更或其他意外为借口来打破,但后者相反,有合理的问题发生 delay 是正常的,但代价是绝对不能用乘法(至少我认为这属于不负责任) 个人没做过外包所以对外包的描述是瞎猜的,下面所有的看法都是基于公司自有项目

2. 时间预估之所以叫预估就是因为不准。实际上每个任务的完成时间都不是一个数字,而是一个概率模型( 30% 半天做完 40% 一天做完 25%两天做完 5% 需要更长时间)而你给出的那个实际的数字,一般应当是 80%左右能做完,10%左右稍微超一些时间 or 加班 能做完的一个预期时间

3. 一份好的时间预估中,任何一天以上的任务都是不被接受,需要进一步拆分的

4. 以月为单位的项目当中,用几天的时间来做技术文档,并最终给出详细的时间预估是合理且必要的,这样的项目中表结构都没有定,技术文档都没有,你就给我时间预估我是不信的

5. 如果你有技术 leader,可以和他直接沟通你的困难,包括技术的选型和时间预估的困难,另外你的时间预估必须和你的搭档核对,并且写清楚你们所有的配合的时间点,什么时候定公共的数据结构、你们内部的接口形式和字段,什么时候你们两部分可以联调等

6. 题外话,要不是看到下面的数字列表还算整齐,我看到第一行其实就有关窗口的冲动。重复 3 遍想表达什么?你用什么语言和项目时间预估也关系不大。 包括你后面 7 里面写的一堆,你以为会呛你一句风凉话让你离职的人会仔细看你写的那么多东西?或者是看了以后他们就会认真给建议了? 论坛里面的一些信息噪音当作没看到就好( V2EX 甚至有 block 功能),不要和他们战斗,更不要这样因为他们影响其他人的阅读体验,要不是有数字列表方便我扫一眼就跳过,我可能就跑了
2018-07-02 10:00:59 +08:00
回复了 fingerprint 创建的主题 问与答 大厂(AT)营收部门和小公司核心开发怎么选?
没去过大厂选大厂,更何况是营收部门

去过大厂还问出这样的问题的话…那还是蹲在大厂混日子吧
2018-06-27 13:54:48 +08:00
回复了 yantianqi 创建的主题 程序员 前端迷茫了,不知道该学习什么
建立自己的知识体系

“建立自己的” - 不是去搜一下看一个脑图完事儿,也不是死记硬背,而是真正自己理解的,即使忘了也能从头在白板上稀里哗啦画出差不多的知识体系
“体系” - 不是线性的清单,而是有组织的,从上级概念慢慢具体到知识点的体系

别人叫你看源码你就去看源码是没有用的,也大概率看不懂,就算看懂了你还是想问“我看懂了 vue 的代码,迷茫了,不知道该学什么”,不如说你可能都无法判断自己是否看懂了
1 ... 33  34  35  36  37  38  39  40  41  42 ... 91  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   765 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 37ms · UTC 22:34 · PVG 06:34 · LAX 15:34 · JFK 18:34
Developed with CodeLauncher
♥ Do have faith in what you're doing.