某些开屏广告不知道是不是觉得把跳过放右下角太容易点击了, 直接给我整左上角去了

见一个删一个

这两年挺多要 WM 不要 DE 论调的, 之前尝试过 i3wm, 确实惊艳, 就是没法像 xfce 或者 Cinnamon 那样开箱即用方便, KDE 这几年用户量确实大涨, 从设计到插件都特别优秀

所以要我选, manjaro+xfce 上班用... 根本没时间自己折腾配置, 有时间说明工作不饱和

有些需求感觉发到这里来讨论讨论, 很快就有资深产品提供替代品或者否定伪需求了, 那种几乎没人想到的需求还是极少数

我也想到的是隐藏默认滚动条然后自己监听事件伪造一个滚动条... 反正可见区域展示多少可以在 JS 里控制, 全部内容也能缓存起来, 就是感觉挺傻的

没太明白这是什么需求, 是 Windows?

现在主力基本 manjaro 了, Windows 上基本只打游戏, 偶尔需要 Linux 环境, 其实 multipass 挺香的...

Hyper-V 跟我好几个安卓虚拟机(Vbox) 冲突, 至于 WSL 当年用过一年多, 后来实在不喜欢就被我净化服务批处理一块给清理掉了.

楼上不定期打儿子, 哭的撕心裂肺的, 打着打着当妈的也哭喊的撕心裂肺的, 不知道经历了什么, 偶尔会有其他邻居去劝

因为租的自如, 如果遇到估计直接找管家, 省的我出面, 上次管家给我找到隔了 4 层楼的一家帮忙把他们空调管子给剪了避免一直滴水到我这前面一个大铁板上. 如果自己租的, 考虑下直接上门, 物业, 居委, 110 什么的吧, 量力而行, 别拖

最近同样部署 chrome 自动化工具, 用的自己写的 zipapps, 如果不嫌麻烦可以继续看, 我这边是 Jenkins 打包机 Linux 打包以后在 Hadoop 那边直接执行的

看你情景必须把依赖和源代码打包起来一起发布, 可以尝试一下. 有几个前提:
1. Python3.7+
2. Windows 打包的只能 Windows 用, Linux 打包的只能 Linux 用, 有些库不是跨平台的要编译, 打包机 Python 版本也得和运行环境一致, 类似 selectolax 或者 psutil 这样有 .so 的就没法同时给 3.7 3.8 一起用
3. 执行的时候估计会解压出一个文件夹在旁边

步骤:
1. 打包机上安装 python3.7 -m pip install zipapps -U --user
2. python3.7 -m zipapps -c -a path_to_your_package -m package_name.__main__:main -o app.pyz -u="*" -r requirement.txt
3. 客户端那边运行 python3.7 app.pyz

打包以后文件挺大的, 毕竟带了所有依赖, 如果想依赖和代码分开打包也可以, 也可以不指定 entry_point (也就是那个-m 参数), 打包后当虚拟环境使

还是得分人吧, 有的起点高, 有的底子牢, 有的大聪明, 有的运气好. 三分运气加七分实力, 剩下九十分全看脸.

有点好奇这种需求有正式的书面协议以及验收标准么, 头回见面试这么直接的, 如果只是电话聊聊, 只能说尽量别相信任何电话非书面的保证

某些日企或者体制内的童鞋就是这待遇, 输入法都不让装, 不连外网, 抽屉里七八个优盘... 应该不是很少见吧

挂代理貌似都远程解析, 本地解析的例子目前没见到过

这两天被公司 VPN 的代理折腾的 DNS 都乱套了, 很多 aws 域名只能指望挂个隧道才绕进去

试了下, 是实时预览, 平时如果 JSON 做配置文件略微改改还可以, 如果大量改还是用习惯了 VSCODE 的多行编辑, 巨量改直接用 Python 了... 习惯的力量太大了, 之前用过 JSON Viewer 和 FE-Helper

挺多地方其实可以借鉴一下 JSON-HANDLE 扩展, 特别多的功能基本离不开了:

图片预览, 折叠记忆, JSON-Path, Tab 打开, 右键选中, 单行压缩, base64 decode.

就身边"朋友" 的经验, 确实结婚前后两种世界. 选清静无为的生活什么的, 小孩子才要选, 成年人压根没得选

@learningman
@namelosw

前半句是之前看到 "人生不可动态规划" 直接反向引用调戏 HR, 后半句确实理解偏了, 太久没关注 DP 了(以前偶尔刷题遇到), 只有点递归和记录子问题最优解的印象, 刚才又搜搜引擎复习了一遍...

@emSaVya
如果人生在走下坡路, 前一步总是最优... 现在越活越丧气

#10 楼经典...

我的人生规划就是动态规划, 走一步看一步

我都是刷新下，第二次就好了，第一次基本没成功过。

@ClericPy 我这边业务不是太复杂, 有时候单元测试有时候简单的功能测试, 太细致的单元测试就连 TDD 那本书作者都不建议 ( https://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests , 也就是著名的那句 "I get paid for code that works, not for tests")

有的同事天天加班到十一点, 进度天天催, 根本没时间写完整测试, 连文档都不愿意看, 最后布一套测试环境跑通核心功能验收就上线了. 毕竟对绝大多数公司来说, 开发人力根本严重不足, 方法论什么的行不通

总结起来就是, 上线前一定要有测试, 但是不要迷信 100% coverage.