jimmylv.github.io
jimmylv.github.io copied to clipboard
JimmyLv
:bowtie: Agile Learning based on GitHub issues, KEEP Retrospection and Introspection! Thanks to @GitHub https://jimmylv.github.io/issues/
对于我来说，原来好几年前我就在使用双向链接了，即GitHub 的issues之间能够双向链接，并且每个卡片其实是有着完整的时间线的。 只是说现在的网络环境下可能会有点儿慢，跟 Roam 的差距就只在于outline的编辑体验啦。 Outline 的编辑体验，可见即可得，GitHub 还是做不到，那就依然 Roam Research 牛皮，果然用了就回不去了 😂 而且每次都是问题导向，把新的内容补充到某个 Issues 的 comments 里面
我的 Zettelkasten 卡片盒笔记法实践 https://blog.jimmylv.info/2020-06-03-zettelkasten-in-action/ 我的 Zettelkasten 卡片盒笔记法实践 via 吕立青的博客 https://blog.jimmylv.info June 03, 2020 at 08:00AM
We're so excited that you've decided to create a new project! Now that you're here, let's make sure you know how to get the most out of GitHub Projects. -...
再次感谢GitHub，其实我还想梳理一下GitHub额外的一些特性功能： - 比如说努力程度的体现 - 工程化的看板实践 - 移动端App的支持（网络有时有问题，强行退出时会有保存） 当然，还包括跟其他工作流之间的集成，从阅读的源头说起，就两个 - 得到 （知识服务商） - MarginNote （我的私人书架） 其实网络的限制会让我更有动力把问题在一个comment或issue里面说清楚。 _Originally posted by @JimmyLv in https://github.com/JimmyLv/jimmylv.github.io/issues/376#issuecomment-645298532_
## 项目纵向拆分 http://rhyme.niucodata.com/ ### ⓵ 定义目标和原则 ### ⓶ 展望结果（OKRs） ### ⓷ 头脑风暴（发散） ### ⓸ 组织整理（收敛） ### ⓹ 明确「下一步行动」
## 项目纵向拆分 ### ⓵ 定义目标和原则 终极目的 Q：为什么你要花时间来做这项任务，而不是其他随便什么任务？ A： ### ⓶ 展望结果（OKRs） 利益相关人清单 Q：当你交付最终结果的时候，会如何让世界变得更好？ A： ### ⓷ 思维导图：头脑风暴/集思广益（发散）+ ⓸ 组织整理（收敛） ### ⓹ 明确「下一步行动」 能够产生反馈结果的小任务： * [ ] TODO: ------ --- layout:...
## 项目纵向拆分 前端UI级别单元测试的一些痛点： 1. class name老变来变去的，依赖css selector的测试都得改 2. UI styling根本没法测，多个少个px过分了 3. 很多跨browser的hack，不同实现还得写不同测试cover？ 4. 响应式是个什么鬼？为什么天底下有这么多种不同分辨率的屏幕！？ 5. …… 又想起了大熊写的「重构已死」，讲的就是"重构本质乃是不改变软件可观察行为与功能"这个前提不再成立，因为软件本身就无时无刻随着需求的快速变化而改变，那何来不改变的软件行为呢？同理运用到测试上来说，需求老变化，每次都得改测试可烦了，PM/UX还没事儿跟你说这儿多个px，那儿少个icon之类的… 总之结论就是：TDD, 重构, 测试这些方法论运用在 后端业务需求，领域建模核心上来说很好使，这些东西也是从那时候开始发展而来…但是偏偏这个商业时代各种客户端UI层出不穷，需求变动也比以往大得多，很多APP都是周更新，那这些方法论也遇到了一些矛盾的地方 因此更讲究避免浪费吧，然后就来谈精益，🤣 所以我还是力挺TDD,而测试只是TDD的附属品。另外一个观点是：如果需求变动过大，我不如重新TDD实现一遍；而不是在原来的代码(&测试)基础之上进行重构。 > 需求变化，变化过快，这个真的会让测试带来的价值变少，甚至成为一种浪费吗？单元测试的输入，本身就是基于我们对设计和实现方案的假设，接口变了，需求变了，测试跟着变是当然的，只不过是假设的输入变了。说需求变了，因而测试价值减少了，因而原来就最好不写减少浪费，那变后的这些需求你又用什么来验证呢？还不是回到没测试裸奔手工验的状态。 > 我最近在开发，写好的单元测试，输入也是经常变，但原来的测试是不是就没有价值了？当然不是，测试挂掉的所有用例会帮我找出所有调用点。我不需要自己再去手动找，这个变的接口影响了哪些地方，我也不想找。把测试输入改成变后的需求，运行测试，挂掉的全部修好，然后再真实起应用跑，基本全是好的，就是不是，debug起来也很轻松。如果说抱怨测试经常要改输入改输出，那没有了测试接口需求变起来，验得岂不是更惨？ > 这段逻辑，主要说的是强逻辑强数据的代码段。ui方面，我觉得你说的痛点都存在，那种情况下，可能是自动化测试的成本，已经大过了手动验证或cdd的成本。「不改变的软件行为」，我觉得并不是指在一个月两个月内的软件行为都不变，而是你「重构前」和「重构后」的软件行为不能变 嗯...
折腾了一下午，现在来总结一下大致流程： - 前置 Google 环境的访问条件（公司 VPN 或蓝灯） - Google Cloud 搭建 Shadowsocks（跟着视频走就是了） + 注册账号（需要信用卡） + 创建 instance + 配置防火墙规则（tcp, udp） + 安装 Shadowsocks （脚本：https://github.com/teddysun/shadowsocks_install ，注意空格和 `&&` 符号） 路由器翻墙之前： - 在...
## 项目纵向拆分 ### ⓵ 定义目标和原则 终极目的 Q：为什么你要花时间来做这项任务，而不是其他随便什么任务？ A： ### ⓶ 展望结果（OKRs） 利益相关人清单 Q：当你交付最终结果的时候，会如何让世界变得更好？ A： ### ⓷ 思维导图：头脑风暴/集思广益（发散）+ ⓸ 组织整理（收敛） ### ⓹ 明确「下一步行动」 能够产生反馈结果的小任务： * [ ] TODO: