古老的 VSS （ Micorosoft Visual SourceSafe ），应该能满足。不过这个只能单线锁定编辑，不能像文件共享（即 Samba ）那样能让 Office 文档多人同时编辑。

能发出这种感慨，说明你干开发的时间少。Java 8 加入不用考虑时区的 java.time.LocalDateTime 时，无时区的时间，在当时可以质的提升。不同于文本显示国际化，时间的国际化，绝大多数情况下都是成本极大高于收益的东西。

@frank1256 #24 积攒的调休，有过期时间吗。

如果调休时间过期自动消失，那就当成免费加班看待了，这个除了跑路没其他应对方案。

如果调休时间能无限期积累，或者至少能够积累到年底，这样的话这个调休，在年底或者离职前，是必须调休或者折算加班费的。后面还分两种情况。一种是就你们部门加班，这个就好办了，向人力资源部门反馈你们部门偷加班费的行为，后面让人力资源去交涉。另一种是全公司都加班，那就没辙了，你们是典型的华为奋斗文化，你只剩下奋斗或者跑路两个方案。

不要直接存 URL ，你这还存的绝对路径，那天换了域名直接全挂。单独用一个表来管理各种文件资源，资源表里面存的也不是直接访问 URL ，而是资源的相对路径或者上游路径。主表里面存资源表的 ID ，这样访问只能通过主表提供的接口来访问相关资源（可通过 HTTP RESPONSE 的 Output Stream 来提供文件下载功能），也就不会发生 1 楼所说的 URL 泄露问题。

至于文件的清理，隔半年后台跑个批量任务，把资源表里面没有任何其他表关联的记录找出来，逐个去清理对应的物理文件，就行了。

完整的租房合同，需要对方的身份信息，以及法律纠纷强制送达地址。涉及的钱不多的话这些无所谓，涉及的多的话那就必须要。楼主现在这俩当初都没要，押金又不比 2000 多多少，还是别折腾了。法院那个回复，是楼主单方面的认为有了身份证就行，实际上有了身份证信息也不行。这个对方不承认的依据，应该是你没有合同或者押金凭证来正面对方收过押金。国内电话是实名的，并不会因为有电话没身份证信息对面就能不承认，法院跟你说没有身份证对面不承认，可能是没有说明白，也可能是你没听清除。

多变内容在分页显示时，不管是分页还是自动往下扩展，都会因为后台顺序变动导致重复或丢失信息，这确实是世纪难题。

对于评论，还是可以解决的，额外增加一个筛选条件“ time < 首次进入页面或者首次查询的时间” ，同时另起区域单独显示 “time > 上述时间”的新评论，就行了。这有两个前提，一，列表严格按照时间排序，二，列表的元素一旦添加就不可更改，即列表只会追加元素，不会移动元素。所以这只适合按照时间排序的评论，对于主题列表，或者不按照时间排序的评论列表，就无效了。

如果你要对标 Mac ，那么就只有微软 surface 、LG gram 、戴尔 XPS 、华硕灵耀 X 这些系列可选。这些都是溢价超高的货，性价比绝对都比 Mac 的低，“8k 以内”这个预算只能买“上一年版本”或者官翻（注意，即使是当年版，这些通常也是落后一代 CPU ，所以上一年版本 CPU 是落后两代）。

如果愿意放弃外观质感，那么以 6800U/6800H 、16G 、16:10 2K 屏幕为基准的本有很多，而且基本不超过 8000 。续航上面，只要是 AMD 的 U 就不用担心续航，只要是 12 代 core 的必然没续航。

上全套 UML 工具，然后又多出来了 UML 工具购买成本、学习成本、重构成本。

工具选型或者过程选型，需要综合成本和收益综合考虑，百人以下的团队，数据库字段描述文档、给前端的标准文档（临时文档不算）这些都是成本收益比很低的东西，代码模型文档更是纯垃圾。

非技术的问题，不要想通过技术解决。

两种都要有。第一种相当于将还款计划和还款历史这两个实体合并成一个实体，未尝不可，当然分成两个实体也可以，但是，还款计划这个数据是必须有的。第二种的数据，是以用户为维度的逾期情况，这个数据是很有必要存在的，不然你逾期提醒都不好做。

如果参考信用卡，你还需要一份数据，账单。当然你们要不是正规金融机构的话，还款计划、还款记录、账单，这三个可以合并成一个实体来处理。以用户为维度的逾期情况这个实体，就没法合并了，要合并它也是合并到用户实体上。

其实这个设计过程，跟数据库没关系。你得先设计好了这些实体关系，然后再去往数据库上映射。

这跟技术，貌似没有关系。如果不考虑渠道，那么自动续费的每次自动扣费过程，跟一次性付费过程，是一样的，都是商家端发起用户端同意渠道端转账，只是前者事先做了三方协议从而可以让用户端自动同意。简单的说：一，定价权掌握在商家端那里；二，每次扣费都是独立账单。在苹果、微信、支付宝渠道上，渠道端会拿走一部分定价权，但这仍然是商务，跟技术没关系。

商务的东西，万事皆可商量。你看到的订阅规则，跟大客户看到的订阅规则，是不一样的。

你网上的说法不对。第一，around before/after 必定与 before/after 对应出现，要么 around 在外，即 around before — before — after — around after ，要么 around 在内，即 before — around before — around after — after ，你网上那种顺序不符合常理 。第二，先执行方法后执行 after 切面，同时 return 是在方法内部的，所以 afterReturning 早于 after 更复合常规。

数据大屏本身是个没啥用的东西，但是要把它支撑起来，下面需要完善的业务系统和 OLAP/大数据分析系统，以及最重要的，持续集成或持续开发。你需要的是一个能够全权负责乙方的高级 IT 主管，不是干杂事的码农。

上面 JVM 堆内存描述有误，应该时：启动时只占用 -Xms 指定的大小，后面随需要扩大占用，直到 -Xmx 指定的大小。

#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 2863661056 bytes for committing reserved memory.
# Possible reasons:
# The system is out of physical RAM or swap space
# In 32 bit mode, the process size limit was hit
# Possible solutions:
# Reduce memory load on the system
# Increase physical memory or swap space
# Check if swap backing store is full
# Use 64 bit Java on a 64 bit OS
# Decrease Java heap size (-Xmx/-Xms)
# Decrease number of Java threads
# Decrease Java thread stack sizes (-Xss)
# Set larger code cache with -XX:ReservedCodeCacheSize=
# This output file may be truncated or incomplete.
#
# Out of Memory Error (os_linux.cpp:2640), pid=18191, tid=0x00007f6c15c70700
#
# JRE version: (8.0_172-b11) (build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.172-b11 mixed mode linux-amd64 compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

这一段已经说明错误现象，可能的原因，和大致的解决方案了。

现象：JVM 向基本系统申请内存的时候失败了，2863661056 bytes 大概 356 MB 。
这里申请的不是 -Xms -Xmx 指定的 JVM 堆内存，而是 JVM 需要占用的其他内存，JVM 堆内存在 JVM 启动的时候就独占了，后面不会再申请。Java 实例化后的对象（实际上是对象的成员变量），方法运行期间的变量，这俩是放到 JVM 堆内存的。但是 Java 类定义本身（类结构、类当中方法的函数定义、类的静态变量这些），是放到额外内存中的。此外 JVM 本身也会占用内存。后两个内存是动态的，现在要申请的可能就是这俩内存，然后因超出物理机或者进程内存上限而失败了。

原因就两个：一，物理机内存，包括实际物理内存和交换区（ Windows 下就是虚拟内存），都满了；二，32 位程序，单进程内存通常上限是 4G 。

如果单看编程，base64 编码进 json 里面，省事的不光前端，也有后端，而且后端省事的更多。这个的问题是，随着文件的增大，接口的处理时间、服务器的并发能能力、网关、日志等多处地方的性能都会收到影响，而且通常影响程度至少是指数级。这东西是要在编程省事和性能优化之间做权衡的，做这个权衡的，应该是架构师或者有过经验的人，不是是当事开发前后端双方。

公司专利，主要不看谁写，看专利作者是谁。手下写专利领导领奖金，不过就是教授剽窃学生论文的翻版而已。

此外，不管专利作者是谁，在公司写的专利的所有权都是公司，意味着：专利一旦通过里面的发明方法就必须有公司的授权才能用，哪怕你是原始发明者。所以，除非是打算干到养老的公司，别把自己的压箱底本是拿来给公司申请专利。