leatomic 最近的时间轴更新 leatomic 最近的时间轴更新 | leatomicV2EX 第 340644 号会员，加入于 2018-08-13 01:16:56 +08:00 |
leatomic 最近回复了
165 天前 回复了 wonderqs 创建的主题 Markdown 有没有人觉得 markdown 并不适合拿来写文档？ |
@Narcissu5 "《黑客与画家》里面专门有一章讲为什么要用纯文本"，没看过这书，这是直接否定对样式的真实需求吗？
你说的最大好处是只记录内容不规定样式（列表项/表格单元格/链接等等内容就是各种格式了，你说的应该是指样式），不规定，是分离内容和样式而已，没错，方便在不需要编辑内容的情况下随意调整样式。主要是限制了元素的多样性，标题只有 6 级(记得好像是)，所有 1 级标题样式统一，不需要那么灵活，对于所有的一级标题，极少需要针对某些个一级标题整出花来差异化表达出额外的信息)，合作者的样式再难苟同，内容格式正确，到我这来按照我喜欢的样式展示，依旧很好看。
然后非常重要的是输入方式，我不知道 word 有没有特殊的指令/宏之类的将当前输入的元素的样式设置为一级标题，在我认知中只能先输入内容，然后由键盘切换到鼠标操作...在键盘和鼠标中切换，对于大脑来说注意挪动手掌位置，是一种很重的消耗，尤其是需要频繁操作，严重影响心流，这才是主要的一大痛点吧。markdown 输入起来确实爽多了，至少常见的大部分元素是覆盖了，当然我指的是在所见即所得的编辑器下的。
你说的最大好处是只记录内容不规定样式（列表项/表格单元格/链接等等内容就是各种格式了，你说的应该是指样式），不规定，是分离内容和样式而已，没错，方便在不需要编辑内容的情况下随意调整样式。主要是限制了元素的多样性，标题只有 6 级(记得好像是)，所有 1 级标题样式统一，不需要那么灵活，对于所有的一级标题，极少需要针对某些个一级标题整出花来差异化表达出额外的信息)，合作者的样式再难苟同，内容格式正确，到我这来按照我喜欢的样式展示，依旧很好看。
然后非常重要的是输入方式，我不知道 word 有没有特殊的指令/宏之类的将当前输入的元素的样式设置为一级标题，在我认知中只能先输入内容，然后由键盘切换到鼠标操作...在键盘和鼠标中切换，对于大脑来说注意挪动手掌位置，是一种很重的消耗，尤其是需要频繁操作，严重影响心流，这才是主要的一大痛点吧。markdown 输入起来确实爽多了，至少常见的大部分元素是覆盖了，当然我指的是在所见即所得的编辑器下的。
165 天前 回复了 wonderqs 创建的主题 Markdown 有没有人觉得 markdown 并不适合拿来写文档？ |
@hhharuka 需要"约定优于配置"！
222 天前 回复了 Chanlarin 创建的主题 职场话题 国内程序员还有出路么？？ |
@sn0wdr1am 问题是，哪里出了问题，会全球和国内，环境都恶化成这样，有没有可能避免，如何避免，没人在乎这个问题似的
255 天前 回复了 Oxonomy 创建的主题 Java 都已经 2025 年了，为什么 Java Boy 还是不能接受 var 关键字 |
个人觉得 var 、val 、fun 这类真的鸡肋，我们的代码中不需要充斥着这些"冗余"信息，编程语言就可以理解为一种 DSL ，语法体现在那了。
我们需要的是对齐，"var : Type"这种也不是不可以接受，最好还是 IDE 支持：
1. 值/表达式.var 然后自动识别类型，光标先选中并定位在变量，然后再选中定位到类型，可以按 Tap 之类的跳过不需要修改的
2. 选中一组变量，按快捷键自动对齐变量名
还有，像访问修饰符，大多数情况下属性是需要封装起来的，默认应该是 private 级别，而不是 package 级别，这类默认项是值得优化的。
我们需要的是对齐，"var : Type"这种也不是不可以接受，最好还是 IDE 支持：
1. 值/表达式.var 然后自动识别类型，光标先选中并定位在变量，然后再选中定位到类型，可以按 Tap 之类的跳过不需要修改的
2. 选中一组变量，按快捷键自动对齐变量名
还有，像访问修饰符，大多数情况下属性是需要封装起来的，默认应该是 private 级别，而不是 package 级别，这类默认项是值得优化的。
327 天前 回复了 zsmile 创建的主题 Java 国内的 Java 体系真的很落后吗？ |
@kandaakihito 兄弟我不是针对你啊，那么问题来了，为什么不是让需求三思而后行，反倒让开发团队反复做无用功呢？(我不信所有人都只是拿钱办事的态度)。我不知道 Mybatis 是否还停留在 SQL 和接口分离的阶段，但那种改个点要同时打开多个文件的操作是真的恶心，整天低耦合低耦合，是真不知道高内聚吗，如果说要统一审查 SQL 之类的，那不应该额外写个 IDE 插件之类的搜集吗？另外有一点，我很反感那些以为写 SQL 很高大上，很有成就感的行为，毕竟代码是要讲究可维护性的。
356 天前 回复了 ChristopherWu 创建的主题 分享创造 对抗"懒人回答": 被裁后花了一年, 我做了款让你变得更聪明的 AI 搜索工具 |
个人思考：学习是个探索（不断完善一个图，最好以一个图的形式展开）的过程，对于错误的路径应该及时关闭，不必要的信息会干扰会造成负担需要及时移除，毕竟"当前上下文的容量"是有限的，因此当要探索(深入理解一些个概念时)，应该使用 hover ，弹窗的形式展示新的内容，并在确定不是想要的内容时方便快捷地丢弃，例如鼠标移出。
2024-06-18 11:42:10 +08:00 回复了 wxiao333 创建的主题 职场话题 看 B 站 UP 主 @老龚 40 岁了啥也不是 被裁有感 |
@BiChengfei 哈哈，人这么多，你猜猜为什么上层不卷，你让上层流动性高起来你看卷不卷。不要无视核心矛盾，叛徒该死但本质问题不解决叛徒不会消失的。
2023-05-03 18:07:34 +08:00 回复了 byte10 创建的主题 Java 有没有 vert.x 或者有关注 Java 虚拟线程的群 |
@lixintcwdsg 内存占用方面（毕竟阻塞 /等待，注册事件回调后方法就返回了，响应的调用栈（的栈帧链）就回收了，回调时再重新算）还是明显 eventloop 这种香的，就是不好调试，然而对于一些经过长时间运行测试，很稳定的逻辑，例如 Netty 自身的 I/O 处理的，没事，本身更多关注业务逻辑，调试也只会调试业务逻辑的（问题基本都处在这），所以 Netty 的线程模型应该不会变，上下文切换这块不得而知。
而处理业务逻辑部分，开启虚拟线程的边界，用虚拟线程 carry 更合适，不冲突的，与其说平替，不如说互补吧
而处理业务逻辑部分，开启虚拟线程的边界，用虚拟线程 carry 更合适，不冲突的，与其说平替，不如说互补吧
2023-05-03 17:53:03 +08:00 回复了 byte10 创建的主题 Java 有没有 vert.x 或者有关注 Java 虚拟线程的群 |
@dreamlike 上面第二段的切换值得的是阻塞的时候（目前是只包括基于 JUC 的同步器的以及网络 I/O 的吧）。类似 kt corotinue 等无栈（例如基于方法参数传递状态机的？）能不能做到这种 Hook 我也不知道，我想表达的是，JDK 应该不会支持，毕竟每次 resume 就跟新的一次方法调用一样调用链都丢了，调试困难。
2023-05-03 17:34:28 +08:00 回复了 byte10 创建的主题 Java 有没有 vert.x 或者有关注 Java 虚拟线程的群 |
@dreamlike 虚拟线程核心就是提供一个替代线程的模型吧（线程是“通用”操作系统的任务承载体，这个调度机制要支持很多特性包括一些统计，而这其中大部分都是不需要的就是太重了，除了带来不必要的元数据占用内存空间，还有这些数据的保存变更逻辑就是上下文切换，而且涉及影响其他进程还需要陷入内核模式执行），线程池解决占多余内存的问题，阻塞会导致并行度丢失于是需要引入并行度补偿机制，但在阻塞密集的时候又创建了太多 worker thread 又趋近于 thread per task 了，解决办法就是（在需要进行上下文切换的地方，就是阻塞 /等待，内在逻辑也是注册回调条件成熟唤醒）用更加轻量级的上下文切换替代线程的，就是虚拟线程的，或者额外搞一种支持注册回调并会 poll 唤醒的机制直接摊牌不阻塞了拆成有依赖关系的多个分支任务（上下文丢失除非又保存，当然可以做得比较灵活在调试时才开启，真实性能差距不得而知）。
JDK 中应该只会在确定当前任务的承载体是虚拟线程时在切换的时候才会进行虚拟线程的上下文切换（而不是线程的上下文切换）。问题来了，kt corotinue 中的代码，能有阻塞（真正意义上的，能调试的那种）的逻辑吗，如果有，发生的上下文切换，还是线程的上下文切换吧。
JDK 中应该只会在确定当前任务的承载体是虚拟线程时在切换的时候才会进行虚拟线程的上下文切换（而不是线程的上下文切换）。问题来了，kt corotinue 中的代码，能有阻塞（真正意义上的，能调试的那种）的逻辑吗，如果有，发生的上下文切换，还是线程的上下文切换吧。
Select Language