• @xhj6 完全赞同你在本帖说的大部分内容,但不认同你说的:

    全栈营竭泽而渔的事实非常明显,对 Ruby 社区的伤害也特别大,但至今不见社区的活跃人士(包括管理员们)出来评论两句。

    因为这两年来,社区里关于此培训营的话题并不算少,我仅凭印象大概也能忆起:

    1. 最开始发招生贴的时候,那时候大家都不清楚这事究竟含金量几何,再加上主办人具有的知名度和交游广度/深度,大家也不便于唱反调;但就授课内容和收费来讲已经有很多人点出“不值”了。

    2. 第一期结束之后,有部分学员就来发 promotion,在里面就展示过所谓“培训成果”,当时就被很多人喷得生活不能自理了,主要聚焦于所谓“全栈”的噱头和最后的实际效果上吧。
      话说到这里插一句,作为成年人吧有时候说话总是会用点技巧,就算心里清楚那边是什么货色,但一来和自己没有直接利益关系,二来人在江湖留一面日后好相见,又没有深仇大恨,不至于“路见不平就拔刀相助”非要跟人家怼到死不可。我这么说你能理解吧?那么在此基础之上,我已经见到不少人旁敲侧击的指出这个事情的问题了;我相信脑子清楚一点的后来都打消了一头扎进去的念头,但问题别人的良心不会因为这个而变好,招生的渠道也不止这一家。在过去几年漫长的时间里,该说的能说的我认为大家其实都说到了。并且后来也有仁人义士专门发帖抨击过,这在上面几楼已经有人告诉过你了。

    3. 消停了一段时间,又冒头了出来几个代表性的帖子,主要都是埋怨为什么找不上工作或是应聘不顺利的,并且这些人都是此营培训出来的,这些帖子差不多也就是今年年内的事情吧,你往回翻翻应该还能看得到。在这些里面,你所说的活跃人士们已经不仅仅是评论全栈营了,而是真正的担负起了“课外教育”的职责,不断的把全栈营没教授的或者乱教授的东西进行补充和修正,而这些额外的努力并没有赚取过一分钱。

    基于此,我是看不懂今天你站在这里指责活跃人士们没有“评论几句”有什么站得住脚的理由?更何况你的指责还并非事实。我能理解你的愤恨之情,但貌似你怪罪的打击面有点广啊,这是万万要不得的。

  • 我知道这么做不好,不过你可以先试试,满意了再买……

    https://www.macbed.com/navicat-premium-12-0-13/

  • [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”的问题,而是他为什么“说了很多次也不听”的问题。