我就知道个大概原理,没资格分享的。算法的具体细节我不懂的。机器学习是非常博大精深的一门领域。 我司做这方面算法的人最低学历都是硕士。这是一门需要很多年积累的学科。 我也就是懂个大概原理,知道人工智能的业务是什么样的,这样在测试人工智能产品的时候就不会抓瞎了。 所以某些人说自己多少多少天入门了深度学习什么的。都是外行人瞎扯淡,其实他连深度学习和神经网络是什么关系都不知道呢。
@seveniruby 我可以确定这就是个哗众取众的水货。 注册各种小号跑来自导自演。 不排除是有些别有用心的人报复
我有种预感,我又要被喷了 要是对社区带来负面影响我抱歉,我会看情况删帖的
他自己说的,我无法取证,因为他是匿名发文章
额额。抱歉,我看到原贴人这仨子的时候,还以为你就是作者呢
我看到了你再微博上发的东西, 说实话我也不赞同。 我一会发个帖子跟你说这事。 你再 google 应该知道 google 对自动化的态度。 实在想象不到一个 google 人会对自动化产生质疑。
我表示看的一脸懵逼,有谁能让我看看原贴
因为要带娃,有段时间没来社区了 。 你说的那个帖子我没看到,但是因为我关注了思寒,所以在消息通知里能看到思寒的回复。 大概意思是不是那个帖子的楼主是一个干了很多年,职位做的很高的一个人。他认为自动化测试是没有用。 手动的功能测试才是正途。 我理解的楼主的意思对么?
额。。是候选人把我们拒了
你说这个我想起来了。以前我刚到老东家的时候,CTO 就给我们开会,下 KPI,要把测试开发比从 1:3 降到 1:5. 现在确实都在强调 RD 的质量意识。 很多 QA 都倾向于转向纯的工具和平台开发人员。 我有时会碰见有些候选人把我们据了的原因是因为我们这里要一半业务,一半技术。 而他们想纯工具开发。
恩,有点明白了。 果然到哪里测试都是比较难晋升的。 我同事以前跟我说过到了 P7 开发和测试就没多少差别了。 看来是我想的有点乐观。能爬到 p7 都很难
额,刚才那个是我。 又忘了点显示名字了
我刚才问了一下几个阿里的朋友,也问了曾经在阿里工作过的同事。 发现认识的测试同行里还真没有 p7 的。 他们说在阿里测试想升 p7 特别难,p7 是个大坎。所以 p6 的薪资范围才那么大,有时候能看见有些 P6 的薪资比 P7 还高,但就是不给你升 P,压级压的厉害。 相反 RD 确实比较容易升 P。 RD 和 SRE 比较容易能做出成绩来。
额,多谢你的支持~~ 你让我更有动力坚持下去了~ 二维码已开,欢迎用钱砸死我
卸载了 就玩不了了
我一直用的 jenkins 上的插件。 简单实用
其实原理还是比较简单的。 不是靠 filter 和 reduce。 我们创建 RDD 的方式有两种,一种是从文件中读取数据,结果自然就是 RDD。 还有一个就是通过一个 list 在内存中生成 RDD。我们用的是第二种。先通过 xrange(不是 range,因为 range 是一次性在内存中生成。而我们的数据庞大。 所以用 xrange,它返回的是一个生成器)生成足够大的原始空表。例如你想造 1000 行。 那就是 sc. parallelize(xrange(1000))。这样你就有了 1000 行的 RDD 了。 然后再通过 map 方法处理每一行。把每一行的数据构造好就行了。 这是最简单的场景。 还有一些比较复杂的,例如你要造拼表的情况,比如要造两个表,附表靠外键跟主表拼接。 这种场景就需要事先造出一个 key 的 RDD 来,这个 RDD 只有一列,就是 key。 然后分别造出主表和附表的 RDD。 再通过让这个 Key 的 RDD 跟主副两表 join
首先说一下 USER 这个指令哈。USER 的意思是工作用户。 是说用哪个用户执行下面的命令。你的例子里面就是用 root 用户执行下面的命令,并且容器启动以后,entrypoint 和 CMD 都是用 root 去执行的。 用 docker exec 命令进入容器的里面也是 root 用户。 如果换了另一个用户,例如 work。 你再用 docker exec 命令进去容器的时候就会发现当前使用的用户是 work 了。类似的还有 WORKDIR 这个指令。意思是工作目录。
再说就是楼主说的镜像的共享的问题。楼主主要是通过 dockerfile 来达到镜像共享的问题。他人通过拿到你的 dockerfile 重新 build 一个镜像的方式来使用。其实我是十分不推荐这种做法的。 楼主可能觉得一个镜像比较大,传递起来比较麻烦耗时。 但是有些时候重新 build 一个镜像是更耗时的。尤其是这个镜像有好几层的时候。或者 dockerfile 里写了很多安装工具的 shell,例如安装一个 jdk 就比较耗时。我这里有一个编译的基本镜像。从 gcc 到 thrift 到 jdk 到 scala 应有尽有,build 这么个镜像没半个小时一个小时的是结束不了的。这时候反倒是拉现有的镜像比较快。 而且重新 build 一个镜像的话你是控制不了对方给这个镜像起什么名字,用什么 tag 的。非常的不好管理。 有时候会造成一个机器里同一个镜像有好多个名字和 tag 的情况。
所以我比较建议楼主在内网搭建一个镜像仓库。build 好一个镜像以后直接 push 上去。 别人想用的话直接拉下来就好了。 不用你主动的发包给他。你只要维护好镜像仓库上的镜像版本就好了。有点像你在内网搭建了一个 docker hub 的感觉。 在以后测试环境变多,docker 单节点扩展到多节点。 引入编排工具的时候,例如我用的 k8s。 在多个节点之间共享镜像用的也同样是镜像仓库。 这类的容器编排工具都会提供 image pull policy。通过你选择的策略去决定是否从镜像仓库中重新拉取最新的镜像。
乱码不是因为系统编码问题,是因为系统没有安装对应的字体。毕竟镜像是老外做的,没有中文的那些字体是比较正常的。你可以继承它的镜像做自己的定制,安装你想要的字体,例如我装的是微软的雅黑字体。如下是我做的:
另外不要一个节点只启动一个浏览器,那样很浪费资源。传递环境变量进去可以改变配置。如下:
另外你也可以用像 1 中的方法。自己定制一个镜像,把 chrome 的版本换了
依然在招哈
双方都没必要剑拔弩张的。到头来双方都是吃亏的
pytest 有数据驱动模块的。 不用写 for 循环。
我没测试过哈,只是我们运维推荐我用的
多谢提醒
听说微软在做 windows 的 docker。不过我没用过哈