@Hant 有 MacBook Pro 为什么还要折腾呢？若是就的厚机 Macbook Pro 可以直接买 SSD 跟内存升级啊，比你这个便宜多了。
黑苹果主要的问题在于驱动，你就算照网上的来也不一定能解决。而钱的问题，我觉得可以通过分期来解决（或者去香港买吧）

@JohnDeng 不是，再看了一下他们的日志，原来是用系统自带的虚拟化，地址在这里 https://blog.docker.com/2016/03/docker-for-mac-windows-beta/

@wclebb 不是笑话，是本来该答主是在做一些关键点调优的活，本来写的代码都是简单明了效率高。但 HR 跟 SVN 管理员居然是以代码提交函数计算绩效。于是离职之前用 C++模板将之前的汇编，或者简单的代码重新写了一遍，代码量立刻膨胀了好几个数量级，居然获得老板的赞许。不过离职之后果然如该答主所料，他写的代码只有神才知道是什么意思

@JohnDeng 不是吧，最近出个了 beta ，那是原生啊， windows 也是啊，我觉得是一个 syscall 的 wrapper

我只是想说要将 editor 改成 IDE 的人，你们知道 IntelliSence 跟 auto-complete 是不一样的吗？

@kaneg 我倒想知道它如何模仿 OS 级别的隔离？只要基于 lxc ，那么他们必将共用一个内核啊，那你其中一个程序导致 kernel panic 就会全部爆炸啊，这个对不对？再模仿也不能超越技术的限制嘛。
基于 lxc 的应用不是没有， infoq 上面雪球就作过一场演讲，讲的就是他们 IO 密集型的应用都是用 lxc 部署管理的，其他 CPU 密集型服务则是 docker （原话是 DB 是用 lxc ，应用使用 docker)。

回到你所说的用 lxd 会提高开发效率的话题，我不认可，很多开发 linux 程序的同学都是用 mac 的， docker 现在至少是原生支持 OS X 了。在 OS X 上用 LXD 必然会用到 VM ，那么为什么不直接用 VM ，写一个初始化的部署脚本或者是制作一个公用的镜像又不是什么难事。去到运维的阶段，我相信运维的人员会对 docker 更加熟悉。 LXD 跟 docker 比起来没有什么优点，它不能完全取代 VM ，但在进程层面又比不过 docker ，那么为什么要用它？它这个定位我觉得是没有抓到痛点。

MySQL 自带的 MySQL workbench 不好用吗？

用了 lxc 根本就不可能像虚拟机，至少你 linux 内核能动？你一个实例导致 kernel panic 立刻全部爆炸。

有强隔离需求的同学请使用 kvm, xen, hyper-v 等虚拟化技术。对于普通的 container 需求，我认为用 docker 就好了，毕竟 docker 已经有很多人用了，坑都填了不少，网上能找到解决方案。

不是，据我了解很多公有云的系统都是内部研发的

一般人走复读，上大学(大学请参考中国高校排名）路线
天才随便走
不过在中国应该很少天才会不上学，毕竟高考对于他们来说就是小菜一碟，而且收益又很大，这样为何不做？
同时要告诉楼主，成功没有捷径，任何你看到的成功都是资本，能力，运气，缘分的成果，缺一不可。成功捷径？何不直接去澳门，那里的确可以，而且是合法的。
编程能力比你强一万倍的人还在写代码，你又怎能有成功的捷径呢？

这样的推广文案是体育老师教的？用『屌丝』称呼读者，用户？
程序员行业的自嘲多了还真以为每个程序员都是屌丝

@VmuTargh
@chztv
原来如此，果然 MAC 对 NTFS 的支持隐藏得够深，毕竟默认关闭。我之前一直以为是不支持 NTFS 的

@chztv OS X 原生可不支持 NTFS 写，如果原生可以写，请告诉我如何操作，谢谢。

总结下来， OS X 能很好地支持商业软件以及大量的 Unix-like 工具。而且有一个相对稳定可用的客户端，可以说得上开箱即用。
对于需要为 Linux 开发软件的同学，也能通过 docker, vagrant 等工具较好地解决问题。

若是完全是在国外，基本不进行中文交流，那么 Linux 跟 OS X 还是能战一下，不过 GUI 方面， Linux 的各种桌面还是没有 OS X 稳定。

@slixurd homebrew 只不过是 formula 是放在 github 上面而已，它的包可是二进制发布的

@bwangel 你只要去实现一个 session 的中间件就可以了，将 django 自带的注释掉不就可以了？

@msg7086 但题主明显就不是想要手写的 mirgation 嘛，仅机器生成的又不可能做到数据迁移嘛。

@lincanbin 写 CI ，写专利授权协议，写代码授权协议。

db.session.commit()应该放在 model 层，这不属于 model 的操作，但这属于业务逻辑，是 model 层，不是 model

view 对应的是 MVC 中的 C ，应该只做 M 的匹配（路由）。

你定义的 model 跟 MVC 里面的 M 没有关系， M 是指 model 层，一个抽象的概念，那是业务逻辑处理的地方，当然你可以将所有业务逻辑放在你的各种 Schema 类里面（此处用 Schema 替代 Model 来指代用户定义的表结构类）。但你这样做又会严重违反了 SQLAlchemy 的设计方向，毕竟 SQLAlchemy 是 Data Mapper ，因此它本身就是为了将业务逻辑，跟 Schema 分离而设计成这样的，你不见你都是在用 db.session 正在做增删改查吗？

因此我建议你多写个 service 类，所有业务逻辑放里面，数据库操作放里面(db.session.commit()也自然放里面），充当 MVC 中的 M