1、可以看看这个回答,也写个最简化代码验证一下?
2、正文提到有报错,具体报错信息也贴上来吧?
无论你有多少个 python ,which python3
都只会有一个的(它显示的是当前环境变量下 python3 命令的实际路径,这个路径是按照 path 的顺序找的,首次匹配就返回,所以不可能有多个),这个校验方法并不正确。
具体找法可以参考:https://www.zhihu.com/question/270799956
然后这个问题大概率就是楼上所说的你有不止一个 python ,且不同执行环境用的并不是同一个。卸载掉其中一个,或者确保把环境变量都设置为指向同一个就好。
恭喜,预祝新婚快乐!求婚这个好有气氛呀~
额,前面说的这个思路可以么?可以的话,写脚本实现然后供 jenkins 调用是否可以?
这个属于项目强相关的逻辑,自行写脚本去实现是最合适的。
控制准确构建,核心是要识别到变更涉及的 service 是什么。
如上面槽神说的,既然区分了 service ,那这几个 service 大部分情况下应该是放在不同文件夹的,然后通过 module 或者 git submodule 之类的形式组合成这个大仓库。那么你通过 git diff 看下改动的代码文件路径包含哪些 service 的文件夹,然后就只运行这个 service 对应的 docker build 命令,是否可以?
这个文档没有说 token 哪里来,表示爱莫能助。建议问下开发,程序里这个 token 怎么来的,然后看怎么用程序模拟?
输出很多,自愧不如。点赞~
PS:一些好的文章也可以分享来社区呀,大家一起交流学习。
哇,原来有这么多大会的呀。
在最后一步将入参加密以后的 byte 类型经过 vars.putObject() 到 http 请求中错误。
具体啥报错?另外,你加密后的 byte 类型具体到底是啥类型,用 java 语言把类型名明确给出来?var.putObject() 并不是所有类型都支持的。如果是 byte[] 类型,这个属于基本数据类型,不属于对象,不一定支持。
关注社区公众号后,底部菜单的 MTSC 大会点击就可以看到最近几届大会视频的入口。
你说的这些,本身就是价值。有一部分也有开源自己的模型出来给大家用的吧。
但现阶段 AI 各个模型还是针对性非常强的,建议可以了解下现在 AI 的一些主流算法和应用领域。对于成熟领域(如车牌号识别、OCR 识别、音转文这类)确实不少成熟的基于 AI 实现的方案可用,甚至也有抽离成了简单的 API 便于集成到任意应用中。但对于新领域(比如楼主提到的在游戏测试领域的引用)并没有这样的直接可用的方案,还处于探索阶段。
不过之前 MTSC 大会游戏专场,网易有分享过一个基于 AI 做得自动按指引做任务的实践,楼主可以看看历年游戏专场的议题了解一下。
经历过的公司,一般基础组件类的(比如一些组件)会对单测有要求,因为你单测覆盖率都给不出来别人不敢用,而且这类无界面的组件不写单测更难测试。
而业务系统的比较少,因为比较难写(大部分业务系统因为历史原因欠债严重,核心逻辑很可能在一个一堆 if else 的上帝类里,写功能都难,单元测试就更难了),而且业务变化太快、有测试人员校验,从质量角度也没有非常强的必要写。
如果你们的敏捷=不写文档和开发完直接上线,这是敏捷的典型反面教材。这玩意不叫敏捷,叫乱来。。。
工作软件胜过全面的文档 != 只要软件不要文档
响应变化胜过遵循计划 != 只要响应不要计划
人家说这句话的场景是当时大部分用的都是最传统的瀑布流,文档要写得差不多有代码那么详细(你找个政府类项目的完整文档看看就知道了,需求说明、概要设计、详细设计,每份文档都是几十页甚至过百页的文档,像写论文一样),计划一排就是排好几周而且中间不能随便变,所以才说这两句呼吁大家不要舍本逐末。你上面说的这个明显就是矫枉过正了。
也可以看看这篇文章,里面提及了几个常见的敏捷理解误区:https://www.scrumcn.com/agile/scrum/4074.html
建议做长期的职业规划的时候,不要过多考虑 领导 这个因素。有好领导是个福分,但他不可能在你持续几十年的职业生涯里一直带着你,关键还是你想下你自己未来想往什么方向走、适合往什么方向走。
对你本身性格等各种情况不熟悉,不好给建议(只看行业动向不看个人能力的职业规划,我自己是比较抗拒的)。建议你可以和你以前的领导以朋友身份吃个饭聊聊,说说你的想法,听听他的建议,这样可能会得到更好意见。
看业务情况,一般 1-2 周一个迭代,最长的不超过 2 周。迭代过程基本也和楼主说的瀑布差不多,不过这个我理解是个软件开发流程都得这么走吧,顺序大部分情况下无法调整,因为相互依赖。
另外,不知道楼主这里提的敏捷,和这里提的传统瀑布有啥差别?
敏捷的具体落地不同公司有很多不同差异的,有的地方小型瀑布(就是需求拆到 1 周内能搞完的粒度)也会认为是敏捷。
不用懵,说明你开始一步一步接触细节和深水区了。这些是成为专家的必经之路,也是差距所在。
selenium 打开的 chrome 用的模式和手动打开有点差异的,有点接近于无痕模式,可以搜索引擎详细查一下。
至于左下角这个,一般是表示焦点所在按钮对应的 url ,js 事件跳转的一般也是会这么显示。你可以对比下看普通模式下如果用 tab 选中登录按钮,左下角的提示是不是也一样是这样?
这个不是议题,是主题,也就是 slogan 哦。我现在改为 slogan 避免大家误解了。
别这样。。。受不起。。。
赞一下考古的态度。人云亦云实在太多了,里面还夹杂着别有用心的引用和传播,有很多东西其实考古一下才能真正理解前因后果。
android 的话,通过打开 https://debugx5.qq.com 应该可以看到调试菜单。
ios 没试过,不清楚。
如果你自己没找到特别需要用到 mac 的地方,不需要买。买了只会觉得没有想象中好用而已。
我自己也是用 mac 主力,windows 打游戏啥的,以前也有做过类似修电脑、重装 windows 等东西,对 windows 命令行也用得比较多。我说说我用 mac 而非 windows 的几个核心原因,你可以看看你是否有类似的需要
PS:初入门暂时不建议 m1 ,兼容性坑还是有点大,比如 docker 虽然支持了 m1 ,且内置了 x86_64 指令的虚拟机,可以支持绝大部分镜像才有的 x86_64 指令集,但也有一些不兼容直接 core dump 启动失败。比如有些命令行软件,没法用苹果的自动转译,intel 的直接下载编译好的二进制包就能跑,m1 的还得自己编译而且处理各种编译报错。intel 就基本没这些问题。
额,你百度下怎么采集 android logcat 日志?这个日志收集并不复杂。
从耗时分布看,从发出请求给 WD Proxy 到收到返回值,基本都需要 20 秒左右,占据了绝大部分耗时:
...
2022-01-08 01:35:26:879 - [debug] [WD Proxy] Proxying [GET /element/00000000-0000-1371-ffff-ffff0000014f/attribute/enabled] to [GET http://127.0.0.1:8201/wd/hub/session/74b2d304-3843-4dba-98c2-fc0f9438be52/element/00000000-0000-1371-ffff-ffff0000014f/attribute/enabled] with no body
2022-01-08 01:35:46:924 - [debug] [WD Proxy] Got response with status 200: {"sessionId":"74b2d304-3843-4dba-98c2-fc0f9438be52","value":"true"}
...
这个耗时有点久,可以结合 logcat 日志看看到底这 20 秒在干嘛。
建议先看看你们的直播视频流的架构?
拉流是一对多(对应的是听众),一般生产环境会弄个 CDN 来提升性能和降低系统负荷。这种情况下你压拉流本质上就是压 CDN,意义不大(一般 CDN 都有单 ip 限流策略,你还没压到极限就被限流了)。
搜索 django_apscheduler 相关信息时找到的,可以参考下:https://juejin.cn/post/6844903885400702989。