@leriou 前端保持不变的情况下 这个办法不可行, 你要改表单的逻辑

关于线程的问题不算宽泛吧

@leriou 跨站请求伪造 和 服务端有什么关系?

@lolizeppelin 我一直很困惑说这话的人: 机器可读性??

@kcats 在 UNIX 编程的艺术 这本书中有关于 文本 和 二进制数据格式讨论, 建议看一下. 至于说 JSON 不适合传输, 那么常见的 JSON 载体 HTTP 更不适合传输了.

@1194129822 JSON 不适合机读有什么证据吗?

同感

人类可读性的话用 DSL

机器可读性的话用 JSON

语法糖 DSL 的问题

http://www.yinwang.org/blog-cn/2017/05/25/dsl

这个就和把业务逻辑写在储存过程中一样



1. 违反了单一职责原则, 你把代码和部署环境强耦合了.
2. 违反了开闭原则, 扩展性和灵活性肯定不如写在代码中好.
3. 违反了依赖倒置原则, web 服务器是一种部署方式, 是细节, 业务代码不应该依赖于任何细节.
4. 违反了过早优化原则, 没有经过测试的优化都是瞎搞.

我其实比较反感那些拿谷歌, Facebook 或者是国内大公司来举例子的人.

对方多大规模, 自己多大规模?




对方面临多大的业务复杂度, 自己又面临多大的复杂度?



对方发明的技术是为了解决在某个特定领域的问题, 自己又真的有这个需求吗?



如果上述你都满足, 那么你提到的这些技术经过你方的业务程序检验了吗? 在这个过程中你主导了哪些技术, 踩了哪些坑, 可有分享?

你的事务级别是什么?

@12101111 无知者无畏

不觉得 Python 有什么优点

我 120 收了一个 D525 跑软路由, 除了功耗高一点, 好像都满足

1. 并发是基础, 学的时候还能接触到 Java 内存模型.
2. 网络层的分层来学, Web 开发用到的 HTTP 协议, 那么 HTTP 要熟, 同时还要往下一层探究: TCP
3. 操作系统, 这里面的操作系统指的操作系统原理, 而不是 Linux 系统管理, 大概分为 3 个部分: 虚拟化, 并发(第一点接触过), 持久化(IO)
4. 数据库大概有几个部分: 1. 数据库设计 2. sql 语法 3. sql 执行过程包括优化 4. 物理层的数据存储, 事务, 索引的实现(操作系统中的知识点都会涉及).

单机学到这里应该差不多了, 分布式没接触过.


至于设计模式属于一个不断学习的过程, 因为全靠不断的犯错才能正真体会到设计模式的优点, 所以这个要在项目中不断积累.

你需要的是文件共享吧， 不是代码同步。

samba 映射到公网， 随便编辑。


需要手动同步？ rsync 自己配置规则， 同样需要一个公网服务器。

@ericv 除了他还有谁