• 花了半个月捡垃圾 at 2017年2月14日

    #8楼 @ywjno X5690 真的发热惊人。。。TDP 比 AMD fx-8350 还大。。。

  • 花了半个月捡垃圾 at 2017年2月14日

    #4楼 @ywjno MC560 的话改装难度小好多,不过 CPU 是单路的。

  • 花了半个月捡垃圾 at 2017年2月14日

    #5楼 @cxh116 北桥还好,只有 40°C 左右,我北桥芯片上就带一个铝制的散热片可能解决了很大问题。还有就是机箱风道设计得好的话整机温度还是很稳定的。就是这 CPU 待机 45°C,满载也不过 55°C

  • 花了半个月捡垃圾 at 2017年2月14日

    #1楼 @huacnlee 这 5000 里有块全新的 GTX 970 就占了近 2000,还插了块 SSD。主要是这俩是我房间里翻出来的,没有单独买,否则压缩一下预算还是可以的。只是这核心数和这内存大小用来跑很多纯并行运算真的很爽(逃

  • midori 百日记 at 2017年1月17日

    #28楼 @luikore mruby 下的线程栈还挺小,但生态太糟糕

  • midori 百日记 at 2017年1月16日

    #25楼 @gihnius 很多稳定性问题主要是 eventmachine 本身导致的,而不是异步。我也打算在下一个大版本中把基于 eventmachine 的绑定改成基于 nio4r 的绑定。rust 线程比 gorouting 快很多,但是 rust 上基于的 tokio-rust 的网络通讯会比线程更快。扯到 IO 的时候,只有在完全解决阻塞的情况下,问题才会落在内存、网络、磁盘上,一旦出现线程阻塞,那性能必定是非常糟糕的。异步的做法就是用来解决阻塞问题的,但是异步的做法代码很难看,这才是这几年很多语言设计都在极力克服的问题。高性能的 Web 服务器,从 Apache 到 nginx 没有一个不是在使用 I/O 多路复用技术来解决问题,甚至连使用哪种复用技术都经过了几代的改变,更不要说单纯同步靠创建线程来解决 I/O 导致的线程阻塞,运行效率实在是太低下。

    IO 密集型还是用线程。

    这种表述实在是难以苟同,你基本找不到单机 10k 并发以上的应用是通过纯线程来解决的,因为单纯靠创建新线程,*NIX 线程创建的性能代价是极大的。

  • midori 百日记 at 2017年1月14日

    #23楼 @mizuhashi 在多线程下不会阻塞是指,他们在多个线程连接数据库的时候互不阻塞,但对于当前线程就出于阻塞状态了,我在实现 pg 的 adapter 的时候就发现了这一问题。主要是大家没有共享同一个 event loop

  • 有点奇怪,既然是 Let's encrypt 的证书,为什么不直接申请呢?在又拍云上申请 Let's encrypt 证书有什么区别?

  • 怎么看都像是脱裤啊。。。

  • 这帖子让我想起来不少事情。我自己从 BASIC 开始 Delphi, C++, PHP, Python, Java, JavaScript, Scala, Objective-C, Ruby, Common Lisp, Swift 都先后学过。最后想想语言和框架真的是这么好学的东西吗?是也不是。

    是的部分是语言的语法确实是一通百通的,基本就可以分为类 C 语言和类 Lisp 语言这两大类。不是的部分是,如果大家的设计都这么接近,那么为什么会有这么多语言呢?事实上,理解一门语言的重要部分就是理解这门语言的设计思想。

    如果你会写 C++,学习 Java 的第一天你就可以开始干活了,但你很容易写出 C++ 风格的 Java。这就好像谭浩强的 C 语言书有那么多问题,除了本身的语法问题,一个就是对于语言设计思想本身谭浩强不理解,另一个就是保有了大量谭浩强之前 BASIC 程序员的风格。

    所以如果你学过很多语言,学得好,你优势就会很大。比如你又会写后端,又掌握前端,在你开发时你就能很好的对接,设计出更合适的接口,极大地提高沟通和开发的效率。学得不好,那么这些东西反而会成为阻碍,让你什么事情都没法做好。这是全栈工程师和全栈 Hello World 工程师最大的区别。

    不过反过来说,如果只学一样东西,即使这项技术没有过时,那么你就能专精了吗?其实也不是。很多外包公司的 Java 程序员所谓的 10 年经验难道不是半年经验用九年半吗?

    所以本质上来说,要想有好的职业规划,需要对自己有明确的认识。永远知道自己知识薄弱的地方,永远知道自己要学习要接触新的东西。好的程序员其实吃饭的时候在想怎么更好抽象,排队的时候在想怎么提高性能,洗澡的时候在想怎么优化风格。用框架用语言的同时会提出这些框架语言设计的问题,并思考能不能解决,怎么解决,这样才能对这些东西理解更加深刻,这样才能让自己写起代码来游刃有余。

    其实真的好好思考后,就算是业务代码也并不会繁杂。业务逻辑上的繁杂通常就是由于没有正确的抽象,从一开始就没有好好做好,从而使得复杂度越来越高,永远是打补丁,在补丁上打补丁,代码越来越糟糕,最后让思路越发混乱,越发不能维护。如果是这种情况,别说 Rails,世界上任何一种语言、一个框架都能写出这种垃圾代码出来。

    于是说,如果因为自己买了台 iPhone,就能荒废 Android 开发的技能,这种坚持和努力程度实在是太低了。我很难苟同说楼主现在这样的情况的主要原因是环境造成的。