我们都知道 Gradle 会使用 Maven 的中央仓库。 在 Gradle 的配置文件中，通常有一个 mavenCentral()     如果我们想把 mavenCentral() 的仓库地址全局替换掉别的仓库地址的话。 我们可以在 C:\Users\yhu\.gradle 目录下创建一个 init.gradle 文件。 文件中的代码为： allprojects{ repositories { all { ArtifactRepository repo -> println repo.url.toString() if ((repo instanceof MavenArtifactRepository) && repo.url.toString().startsWith("https://repo1.maven.org/maven2")) { project.logger.warn "Repository ${repo.url} removed. Only $coporateRepoUrl is allowed" remove repo } } maven { url "https://repo.ossez.com/repository/maven-public/" } } }     上面代码的意思是，在 Gradle 进程启动之前进行初始化，在这个初始化的时候将会用自己的 Maven 仓库地址替换掉远程的 Maven 中央仓库地址。   https://www.ossez.com/t/gradle-mavencentral/14561

现在有这样一个需求，我们需要匿名用户访问 Nexus 的一个公共仓库。 设置 Roles 在满足这个需求之前，我们需要设置一个 Roles。 Role 的名字是可以随填写的。 这里关键的问题在你需要访问的仓库的 View 的权限需要设置 Read 和 Browse 这 2 个权限。 如上图，我们为 maven-public 设置了上面 2 个权限。 用户 用户部分，选择匿名访问用户。 在匿名访问用户中，应用我们刚才设置的 Role。 如上图，为匿名用户应用不同的 role 启匿名访问 在匿名用户访问部分，我们需要设置允许匿名访问。 当所有的设置都完成后，我们不需要重启服务。 可以直接通过不同的浏览器 Tab 直接访问你希望访问仓库。 确定能够实现不登录访问。 当你能够看到下面的界面的时候，表示我们的匿名访问设置成功了。 至此，针对某一个特定仓库的匿名访问设置已就完成了。   https://www.ossez.com/t/nexus/14558

我们可以使用 Java 程序来使用 OpenCV。 OpenCV 的使用需要动态库的加载才可以。     加载动态库 到 OpenCV 的官方网站上下载最新的发布版本。     Windows 下载的是一个可执行文件，没关系，这个可执行文件是一个自解压程序。 当你运行以后会提示你进行解压。 拷贝动态库到 Windows 中 进入解压后的 opencv\build\java\x64 文件夹，在这个文件夹中你会看见一个动态库文件。 例如，我们看到的动态库文件名字为： opencv_java470.dll 将这个动态库拷贝到 C:\Windows\System32 目录下。 运行测试程序。 程序代码如下，首先需要静态导入库。     然后再进行版本输出。 通过上面的代码运行，可以看到系统中运行的 OpenCV 版本。   https://www.ossez.com/t/java-opencv/14557

点火线圈的英文名称为：Ignition Coils 随着汽油发动机向高转速、高压缩比、大功率、低油耗和低排放的方向发展，传统的点火装置已经不适应使用要求。点火装置的核心部件是点火线圈和开关装置，提高点火线圈的能量，火花塞就能产生足够能量的火花，这是点火装置适应现代发动机运行的基本条件。 当初级线圈接通电源时，随着电流的增长四周产生一个很强的磁场，铁芯储存了磁场能(当开关装置使初级线圈电路j断开时，初级线圈的磁场迅速衰减，次级线圈就会感应出很高的电压。初级线圈的磁场消失速度越快，电流断开瞬间的电流越大，两个线圈的匝比越大，则次级线圈感应出来的电压越高。 点火线圈依照磁路分为开磁式及闭磁式两种。传统的点火线圈是用开磁式，其铁芯用0.3毫米左右的硅钢片叠成，铁芯上绕有次级与初级线圈。 下图中显示的就是割草机的点火线圈。     如果你的割草机长期放置在室外的话，割草的点火线圈的硅钢可能会生锈。 这会导致线圈没有办法正常工作，所以我们需要把这个点火线圈更换后就可以让割草机正常工作了。 这个线圈的工作原理就是通过磁性来产生高压电脉冲来点燃汽油。   https://www.isharkfly.com/t/topic/487

PyPI 是可以在本地计算机上进行配置来访问远程的仓库地址的。 检查配置文件 检查配置文件使用的命令为： pip config -v list 通过上面的配置文件，我们可以知道 Python 的 PyPI 的配置文件信息。     上面图片显示的是配置文件的扫描路径。 修改 pip.ini 配置信息 为了能够让 pip 能够获得不同的仓库。 我们修改了路径 ‘C:\Users\yhu\AppData\Roaming\pip\pip.ini’ 的这个文件。 修改了配置信息。 配置文件很简单，只有 index 和 index-url 因为我们的仓库是私有仓库，所以我们还需要在 URL 前面配置授权信息。 这个和 Git 的配置是相同的。 测试连接 如你在使用 pip install 进行安装的时候，如果能够看到下载的地址为你的私有仓库地址的话，则说明配置已经成功了。     如果上面的图，我们看到的下载地址为我们使用的私有下载地址。 在公司内部，通常都会使用私有仓库，这是因为私有仓库的安全性更好：使用私有仓库可以控制访问权限，避免敏感信息泄露，提高镜像的安全性 。 能够离线使用，在没有公共网络或者限制网络访问的场景下，使用私有仓库可以满足本地部署、离线使用的需求。 加速部署：私有仓库可以保存常用的镜像，可以加速项目的部署速度，特别是当需要多次部署相同的环境时。 公司内部网络通常是局域网，所以使用私有仓库能在编译的时候加快依赖下载。 但，这个优势现在已经不突出了，因为就算是私有仓库，很多公司也会部署在公共网络上，通过 VPN 来进行访问。   https://www.ossez.com/t/pypi/14553

Nexus 可作为一个代理来使用。 针对一些网络环境不好的公司，可以通过配置 Nexus 来作为远程的代理。 Group 概念 Nexus 有一个 Group 的概念，我们可以认为一个 Nexus 仓库的 Group 就是很多不同的仓库的集合。 从下面的配置中我们可以看到，我们配置了一个 Nexus PyPI 的 Group。     这个 Group 下面我们只代理了一个仓库。 但是我们实际访问会使用这个 Group 仓库的地址。 仓库地址 当我们点进去这个 Group 后，我们会看到我们配置的仓库地址。 在这个仓库地址下，我们只镜像了一个仓库。     如有多仓库的话，可以在下面配置不同的仓库。 代理仓库 pypi-central 我们定义的是一个代理远程的仓库地址。 配置的信息如下：     从上面的图我们可以看到远程的仓库地址信息。 至此，有关 Nexus 作为 Python 的远程仓库配置就完成了。 如你本地配置没有问题的话，当你进行第一次下载后，将会看到上面的内容。     这样远程 Python 的库的内容就被我们下载到本地仓库中了。   https://www.ossez.com/t/nexus-python/14552

2023年是第一次从日本转机回国。 其实当时的选择还有很多，整体价格上也差不了多少，但选择了一个自认为是不错的选择，从 EWR-NRT-HKG 这条线路。 显然这条线路不是最优的选择。 最终目的地 因为我们的最终目的地是上海，所以到了香港以后还要在深圳多待一个晚上，从深圳湾入关的。 自认为问题不大，在长途飞机上，行李多搬一次就会要一次老命。 如果拖家带口，真的不建议这样选择。 成田机场（NRT） 成田机场（NRT）有个非常大的问题，就是这个机场不是 24 小时机场，所以没有办法在机场过夜。     在出票的时候，如果出的是第二天的票，那你需要申请签证的，针对美国公民，因为有免签，通常问题不大。 如果是中国公民，这里就会存在很多的不确定性了。 让人感觉有点郁闷的就是成田机场的空调，实在是不舍得开空调。 空调的温度控制得比较高，只要你动一下就会出汗，完全谈不上舒适可言。 在国际中转区内，可以选择的东西不多，吃的和免税商品店的选择也不多，感觉就是意思意思。 大家都有，我没有不合适，完全谈不上惊艳。 香港机场 香港机场中规中矩，也许是我们时间太短，没有看到很多让人感觉非常靓丽的地方。 唯一想说的还是这个空调，完全让人着急和郁闷。     因为香港飞内地的飞机，在晚上 12 点后基本上就没有了，我们没有办法在机场再等 8 个小时再回，所以选择了一个从深圳过关的方法。 入关深圳 深圳湾的通关最后时间是午夜，如果午夜之前你还没有通关的话，你需要选择其他的口岸才行。     因携带的东西非常多，每一个行李都要过机检查，这个过程非常耗时，并且行李需要自己搬，这个简直就是噩梦 总结 EWR-NRT-HKG 然后从深圳入关的这条线路实在是没有办法的选择。 哪怕是有那么多一点点的选择都不需要选择这个方案，非常的折腾和折磨人。 日本成田机场和香港的机场空调都不好，所有空调的温度都比较高，随便动一下都会出汗，在拖家带口的时候再碰到这种情况，可想而知的心情都多糟。 对比了我们从韩国转机的步骤，感觉从韩国走更好。   https://www.isharkfly.com/t/topic/480

在 Windows 升级后，print screen 的这个快捷键自动分配给了 snipping tool 这个工具。 个人还是喜欢使用 Snagit，所以需要修改 snipping tool 这个快捷键。 进入 snipping tool 然后选中设置。     选中快捷键设置。 这个快捷键的设置使用 Windows 的设置。     在打开的界面中，选中禁用 snipping tool 使用截屏这个选项即可。     然后你就发现你的 print screen 快捷键没有被占用了。   https://www.ossez.com/t/snipping-tool-print-screen/14543

这次只是电话面试的一个第一次接触。 公司背景 公司属于一个类似数据分析公司，公司规模算是比较小的公司。 主要做的产品是收集用户在网站上的行为，获得对应的用户数据，然后对用户的数据和行为进行一些算法上面的处理。 将处理的结果生成为报表提供给客户公司使用。 这样，客户公司可以根据提供的数据和报表能够更有针对性的投放广告。 职位需求 这个职位属于技术领导类似的。技术领导这个职位主要对团队进行一些负责，对团队中的人员进行开发组织。 同时这个职位还需要有比较好的沟通能力，能够了解 PM 的需求，同时对团队中的人员进行相关的跟踪和调配。 在开发技术上，这个职位可能不需要非常强的开发能力，但是也需要有比较强的开发基础和背景，这样才能更好的完成开发任务。 电话面试过程 在电话面试的过程中，主要是 HR 先对公司的产品和要做的东西进行了一些说明。 因为公司的业务和数据比较单一，因此对公司的业务类型和需要做什么还是比较容易理解的，不会出现太多理解上的偏差。 公司基于的云平台是 Google 提供的云平台，使用的技术栈为 Java 技术栈。 随后，HR 对我的情况进行了一些了解，比如说当前的职位是什么，有没有什么项目管理的经验等。 针对 HR 的问题，我都一一做了回复，针对项目管理上面的经验来看，和我现在的工作职位还是比较接近的，所以和比较容易的回答了 HR 的一些问题。 同时，利用当前使用的一些例子来用例子来进行说明，希望能够让 HR 更好的理解我的工作职责和技术水平。 因为，这次面试只是电话面试，所以很多东西只是通过电话来了解下，主要是了解下沟通能力和双方的好感程度。 通常，第一次的电话面试是不会涉及到过多的技术细节。 HR，同时还告诉我说，整个招聘流程有 3 轮面试。 在第一轮电话面试完成后，如果项目组觉得还可以，就会让 VP 单独和我面试下，时间是 1 个小时。 当 VP 面试完后，会有下一轮主要是各个 Team Lead 之间的一个沟通和面试。 最后才是组员同事的面试和沟通。 整个过程完成后，如果觉得没有设么问题，就会进行背景调查，他们还希望对我曾经工作过的同事进行 Reference。 当然，如果到最后一步了，这些都不是问题。 总结 个人总结这次面试更加像是一种热身。 因为有比较长的时间没有参加各种面试了，所以感觉自己组织的还不是非常理想。 但是好在第一步只是个人行为方面的沟通。 这几天又因为感冒了，嗓子也不是非常好，说话声音都是沙哑的。 总结下需要提高的是，如果是面试技术经理岗位的话，沟通能力非常重要，同时对各种理解和自己的规划也非常重要。 可能是因为公司会通过你对你的自己规划来了解你的期望和公司的要求是否一致，相对来说技术方面可能要求并不是那么高。   https://www.ossez.com/t/topic/14513

在中小公司进行规模化裁员的时候一直想考虑下哪些职位更容易受到影响？ 前几天和朋友聊了裁员这个事情后感觉有点启发。 当然，如果你的项目被整个一锅端了，那就没有什么好说的了。 这里想表达的是，如果是项目还在，但是公司需要收缩，重组，并把很多项目小组合并，哪些岗位更容易受到影响一些。 同时，大公司和中小公司的裁员方式也不一样，这个主要是讨论下中小公司。 中层和小组长级别 开始觉得这个岗位还是相对比较稳定。 后来和朋友聊天后才知道，这个岗位比初级程序员还不稳定。 主要原因是： 公司给的工资足够高。 如果项目组进行合并的时候，这个岗位不好安排，如果采取降职合并，通常也干不了多久。中小公司可能的态度就是干脆裁掉。 进行重组，被裁撤的项目组可能因为合并会导致更多纠纷，公司怕麻烦，并且希望不希望支付太多工资水平。 在中小公司，项目组长或者中层反而是最不安全的。 在公司高层不是说不会裁员，通常他们更有能力获得相应的信息，能够更加容易的做好准备找好下家和准备好备选方案。 公司中层，通常和上面关系不那么紧密，获得信息的渠道和下面也差不多，但是又是职位最不好安排的一个职位。 高级开发工程师和架构师 高级开发工程师的危险系数稍微小一点点。 但是，因为高级开发工程师的薪资水平也比较高，公司为了更加高效的裁员，通常高级工程师会按照一定比率的进行裁员。 在保障最低运营水平的情况下，对工资水平比较高的高级开发工程师开刀。 同样的道理，所谓的架构师在很多时候也会被拿来作为开刀的对象。 初中级开发工程师 这个岗位对裁员的影响反而更小。 主要原因还是这类工程师的薪资水平较低，公司能够有效的控制成本。 具体做事还是需要有人做的不是。通常公司会选择一些老实点的，比较听话的，工资水平不高的人暂时保留。 这次我们公司的裁员明显感觉有这个套路，裁员的方向都在高级和中层。 低级点的基本上都保留了。 其他人员 其他人员会随着项目的保留和公司预期来不按套路裁撤。 比如说项目中的 Scrum Master （敏捷专家或者敏捷大师）通常也会是重灾区。 测试项目组成员，如果过多的话，也会被裁掉大部分。 总结 整体来说，如果公司进行大规模收缩的话，谁都不安全。 而且公司的裁员通常不是一轮裁员，会按照多轮裁员的方式持续进行下去。 在第一波裁员被保留下来以后，不代表在后面的裁员会继续保留。 如果公司已经开始进行了大规模裁员的情况下，更主要的是说明公司在经营上面出现了比较严重的问题，才想到通过裁员来削减支出。 也许，在保留好现有职位，积极寻找更好的机会才是上策。   https://www.ossez.com/t/topic/14512