• [Elixir 基础] 复合类型: List at 2017年09月18日

    话说这个问题你还要继续追问我,那你的自我驱动能力是不是有点捉急啊?

    举个例子好了,你上网搜教程(不管什么框架/工具)大抵都是教你怎么用,在学会用的同时有没有想过:这个是怎么实现的呢?于是主动去翻翻源码也好,上 SO 提问题询问也罢,总之这都是在单纯学习之上的深入探索。

  • [Elixir 基础] 复合类型: List at 2017年09月18日

    去解决一些实际的问题,做一些学习之上的研究。学习固然重要且终生受用,但也不能一直处于被动学习的状态。另外,不要和别人比,要找到自己的目标和节奏;如果你之前没有什么基础,那么仅仅学了一年 Ruby 根本算不上什么积累,你所艳羡的那些人哪个不是拥有五年十年实际开发工作经验的?做好自己,每天进步一点就好,日积月累,持之以恒。

  • 啧啧啧,我本来也打算这么干的,可惜目前还无法全职来做,支持吧!

  • 鼓励。

    但是不必强求让绿点连成一片,这种形式上的“努力”恰恰应该是程序员所要去避免的追求。除非你同时维护很多项目或者参与了很多开源项目,因而有那么多机会去做有意义的 contribution,否则只是“看上去很美”而已。有很多工程师,特别是做具体产品开发的,在固定的时间段里只是专注一两个 repo,而因为一些 features 憋个三五天没有 push 是非常正常的事情,这并不能够反证其不努力或是不优秀。也有一些人(包括我自己)日常的 contribution 多来自于一些 private repos,而 Github 的 contribution graph 是可以选择不记录私有的 contributions 的,所以别人看不到绿成一片也不能代表他们不活跃。

    外界对于一些培训出身学员所贴的标签,大体上并非否认他们的努力(或是天分),真正黑的是那些培训组织,因为他们并没有真正的去培养程序员,他们的做法和理念只会让绝大多数学员变成码农,而且还是不合格的码农。作为学员个体,不用太在意这些标签,也不需要依赖这份经历给自己的影响。如果你自己是一个适合做程序员的人,谁也无法阻止你变得优秀。而优秀这个词,我们通常看中的是它体现出的质量而非数量。

  • erlang 与状态机 at 2017年07月20日

    跟你挑个刺,第二段话暴露了你对 SPA 的极大不了解(同时也侧面反映了现在做 SPA 的菜鸡太多),只有路由方面没做好的 SPA 才会出现你说的这种情况,做得好的话任何情况(哪怕是某个极深的路径下打开了一个 modal)都可以通过 URL mapping 还原出 UI 的状态来。

    此外,貌似你对 erlang 的文档也有误解?modules 是可以检索出具体的 URL 的。这是 gen_fsm 的:http://erlang.org/doc/man/gen_fsm.html,这是 gen_statem 的:http://erlang.org/doc/man/gen_statem.html

  • 这是机器翻译的吧,一堆的“榆树”好辣眼。

  • @fangxing204 你这个问题明显是英文不过关而不是没有答案。假设这一次你觉得自己英文水平搞不定 man tar 于是就问别人了,别人也回答你了,那下一次呢?下下次呢?从此以后呢?

    别说什么“英语我一定会好好学的,以后就不会问大家了”之类的,学习这种事情只有“现在”,没有“以后”。


    我们小时候都听过,“狐狸妈妈会把小狐狸推下山崖,然后让它们自己努力爬上来”,这个道理相信人人都明白。固然让你去 RTFM 的人比不上你的爸妈,可事情的性质并没有什么不同。别人没想那么多,你自己就不能 think one step further?

    我的观点一直都是:问答双方互不相欠,你要问就问,他愿答就答;答得好看精彩并不是因为你长得美,你是占了便宜的;答得简单甚至丑陋也不是因为你长得丑,只是今天运气欠佳。如果你觉得回答的人对你不友好,直接怼上去没商量不就完了吗?如果你觉得回答的人对你的恩情犹如滔滔江水连绵不绝……你也不需要做什么,公道自在人心,社区会尊重每一位贡献者的价值。

    至于说要成立委员会引导社区走向和文化的,我有一句话:强扭的瓜不甜。

    因为真正贡献答案的人其实一直都在贡献着,也许有时候因为太忙了顾不上,然而这本来就是义务奉献你无法要求他们更多。而那些惯于群嘲、鄙视、乱喷的人根本属于另外一个群体,即使你建立了一套社区导向,也不可能让他们遵守你的引导。最终你会发现你只有“惩罚”这条路可以走,但你以为他们在乎吗?最后的结果很可能就是激化矛盾,在一定的时间范围内搞得社区乌烟瘴气,“民不聊生”,然后那些本来“甘当孺子牛”的人们也就悄悄离开了。

    冲动是好的,可惜没在点子上。若说具体的措施,reputation 算是一个不错的方法吧,但是 reputation 机制想做好真的不容易。

  • 所以你要解决的不是“喜欢把生产环境密码提交到 github”的问题,而是他为什么“说了很多次也不听”的问题。

  • 北京面试所感 at 2017年06月22日

    这个,你问我,我也不了解杭州行情啊……如果是我的话,我心里会对自己有个大致的评价吧,然后直接去跟领导谈呗。不过你要明白一件事情,你认为的你的价值和领导眼中的你的价值,这是两件事情。如果事情不如你预料的那么顺利,也不用灰心,最好能和你领导谈一下,了解自己缺失的部分到底在哪里。

    我跟你举个例子吧,我在我的老东家任职的后期,我自己评估自己的技术能力已经超过业务的实际需求了(老东家是为一些中小企业做定制项目的,所以实际中的技术要求并不太高),换句话说:尽管我认为自己更厉害,但现实的需求却是换一个人来也能够替代企业对我的需求,所以这时候你去要一个符合你能力的薪水,领导未必会认同这一点——倒不是他不认同你的技术能力,而是觉得他的业务需求不值得花这么大成本来雇佣一个能力虽强却无用武之地的人。

    怎么办呢?我换个角度,既然业务实现上已经用不上更高的技术能力了,那我就把精力放在提升整个团队的效率和战斗力上。大体上就是两件事:第一、改造前端的工程体系,提高很多工序的自动化程度,减少各项目在基础设施建设上的消耗;第二、带新人、带实习生,给各项目组提供“物美价廉”的新鲜血液。

    这个时候,领导很容易就会给你物超所值的评价,你身边的同事甚至是跨项目组的同事也会给你好评,你不想涨工资都难啊。虽然我后来还是离开了,但不是因为报酬的问题,而是因为个人的技术追求路线,这是题外话了……

    总之,对自己的主观评估+别人给予的客观评估,综合得到的价值评判才是靠谱的薪资等价物。如果你能对这件事情有一个清楚的认知,那么争取到自己期望的薪水就不是什么难事。

  • 超赞,钩起无数回忆啊~