• 请问大佬怎么在项目中组织页面的常用组件的,比如样式统一的按钮,输入框,弹窗等。

  • 感谢大家提供的参考建议,综合考虑了一下,最终还是选择继续用 mac pro。

    我是 8 月 21 号购买的,目前已经使用一个月了,整体感受下来,确实爽。

    过去工作中的开发场景应用全开,笔记本没再响过,之前遇到开发卡顿情况也没再出现。

    不管对笔记本做什么操作,反应都比以前快很多,比如代码保存后,页面热更新都很快。

    不知道是不是心里作用,用平时的网站看电影都快很多,难道好的笔记本还能提高网速?

    PS:我购买的是 Mac Book M2 16 寸。

  • 讨薪说明 at 2017年06月16日

    刚经历了 2016 年一场艰苦的讨薪历程。

    从 2016 年初开始杭州湛创科技有限公司(这是一家关系复杂的创业公司,就不多介绍了) 就是开始因资金问题拖欠员工工资,后至六月期间只有一次正常发放过工资,于是受不了这样的折磨,公司研发同事集体离职,当时公司已经拖欠了 3.5 个月的薪水,后来我们去了劳动仲裁寻求帮助,仲裁电话询问负责人此事,约好时间进行协商谈判,他给的说法是分十个月还清所拖欠的工资且我们每个人要求其开具各自的“工资拖欠”证明 (按手印及公司公章)。我们几人商量觉得十个月稍长且对其是否能按时执行持怀疑态度,于是走法院让法官进行协商调解,法院调解有法律保障,一旦调解形成,对方不按规定履行调解内容,则法院可强制其执行。但对方并没有接受调解,于是我们以“追索劳动报酬纠纷"为由正式起诉杭州湛创科技有限公司, 中间案件及开庭审理过程就不在累诉,初审法院判决我们赢,后对方上述至中级人民法院,维持原判依然判决我们胜诉,主要的证据就是起初拿到的那张盖有公司公章的欠款证明啊。这法院审理过程持续了半年之久,本以为事情至此就能拿到我们应得的工资,没想到对方在判决书下来之后十个工作日内没有履行判决书内容支付所拖欠员工工资,于是我们又到法院申请强制执行。申请执行至今半年又过去了。负责我们案件的执行法官以每日有上百份案件为由忽视了我们的案子,上上周电话联系询问案件执行情况,尽然只是查看对方公司开户账户 (只有十几块钱), 连法人的电话及负责人都没打过一个,在我们几个人的轮番电话压力下开始联系了法人及负责人,对方相互推责,一副反正公司没钱爱咋咋地的嘴脸。时间经过了快一年了,我们当初讨薪的几个人都投入到新的工作里,没有了当初那么愤慨的讨薪气焰,也不想在花心思和时间浪费在这种不知尽头的纠缠里。慢慢地安静地等待法院的执行结果。

    从这样的经验教训里我学到了几点感悟和大家分享一下:

    1. 如果不是自己和信得过的好伙伴的公司,只要有十天以上的拖欠工资经历,赶紧开始考虑下家,不要给他进一步剥削我们的机会

    2. 如果不幸真的被对方洗脑,已经拖欠了一段时日,那尽量收集好其有拖欠工资的证据,盖章的工资条及洗脑录音什么的,以防日后通过法律手段,追讨薪水

    3. 如果已经离职,有私下协商的机会还是一纸协商比较好,因为就像我一样,法律途径不一定是最好的方式且费时

    4. 不要让这样的事使自己的心态变得患得患失,能拿的回来最好,拿不回来,就当掉了好了,毕竟眼前的生活才是重要的

  • 离天堂软件园好近,must go !

  • #7 楼 @kooglezhang 嗯是这样的,现在就是需要好好看看 nginx 的配置了

  • #3 楼 @happyming9527 嗯,所以还是配置 nginx 是关键啊。

  • #2 楼 @kikyous 嗯是的,不过我倾向让前后端的同学在各自的项目目录下进行开发。

  • #1 楼 @kooglezhang 嗯这个我尝试过,但是在项目管理上还是觉得完完全全分开好点,因为不想前后端小伙伴的 commit 都同时在一个 history 下。

  • 刚找到一个Draft.js, 好新啊,就是功能太少

  • @hfpp2012 链接到“websocket 之 actioncable 进阶 (八)“的地址有误,仍然是第七篇的地址。

  • 额~ Backbone 有听说过吗?

  • 想我这种 junior 看了三遍还是云里雾里的,却少站在产品的角度去理解技术。学习了:)

  • #8 楼 @chessy 有收到我简历吗?我没有收到回复啊!

  • @leozwa Thx, you right, it work for me now!

  • 关于 Martini 的路由问题 at 2014年05月13日

    @tnt 其实你的压测是https://github.com/cypriss/golang-mux-benchmark 上的第一种测试类型“Simple - A single route, GET /action. Renders 'hello'.”数据比较确实 margin 要慢于 mux 很多,这和你的说法是成立的,但是你看一下第二种类型,“RouteN”,随着 N 值增大,mux 的速度是越来越慢于 martini 的。

  • 关于 Martini 的路由问题 at 2014年05月13日

    #5 楼 @tnt pypy 无甚了解,不敢做任何评论,“mux 超它一倍”有点言过其实,go-web-benchmark,其实 martini 的源码我也没有看多少,仅仅只是一个"make Martini base on MVC”的尝试的经验,我不是它的忠实使用者,但就你所说的意思通过框架本身的封装性和深度 (不知道是不是黑魔法的意思)来判断性能,有点缺乏信服力。

  • 关于 Martini 的路由问题 at 2014年05月13日

    #2 楼 是传说的中的 Go!

  • 关于 Martini 的路由问题 at 2014年05月13日

    #1 楼 thanks, it work for me now!