开发人员日志：为您的开发团队提供一个简单的知识库和同步工具

许多远程优先的公司已经将他们的会议、站立、入职和启动改为异步进行。这不是灵丹妙药，但当您的团队分散在多个时区时，这就很有意义了。受此启发，我们尝试将异步站立会议与本地“Stackoverflow”相结合，并提出了我们所称的“开发人员日志”。

开发人员日志基本上是我们的开发人员在构建Parknav停车预测器时每天遇到的问题的大脑转储。我们的开发团队规模很小，而且我们都身兼数职--因此，一些人在几个月内成为全套开发人员的情况并不少见，即使他们主要是在后端工作。或者让后端开发人员构建一些机器学习模型。这就是各种有趣的问题出现在…上的时候。

我们也用它们来大致了解每个人都在做什么，所以有时当每个人都太忙的时候，它们会取代我们日常的Zoom单口相声。

查看所有闲置消息，阅读所有邮件，签出代码。喝了杯咖啡。大家都睡着了。我为这一天做好了准备。)。

违规的汽车修理厂有最低电费，但没有最高电费。似乎是一个有效的定价模式：永远只需2欧元/小时(而不是典型的定价模式，如5小时2欧元/小时，然后10欧元/天)。修复了代码并添加了一些测试。*IndicativeTariff*的解析有一个问题，我认为这是一个错误。添加了更多测试。

如何设置JMeter使用随机位置？来自calc-server用户/随机位置要在JMeter中生成具有N个Long、Lon对的CSV，请使用CSV数据配置元素并将它们分配给HttpRequest中的Late、Lon变量，在需要它们的位置使用${lat}和${lon}。

我们将这些日志写在Markdown中，并将它们推送到专用的Git回收库--类似于Concept(甚至是私有Stackoverflow)的东西也可以工作，但是其中一些日志最终包含了太多关于我们的基础设施和代码库的信息。我们还想在离线时访问它们。

一般来说，拥有一个存储库，我们可以对与我们的代码库特别相关的常见问题进行grep，这是非常有价值的。它让我们发现其他人也解决了的问题，跟踪每个人都在做什么，还可以回忆我们中的一些人曾经度过的快乐时光。)

问题来了。我们在尝试运行地图提供程序测试时遇到此异常。我们可能需要更新地理工具：

原因：java.lang.IllegalArgumentException：org.opengis.ferencing.datum.Datum.DatumFactory不是java.desktop/javax.imageio.spi.ServiceRegistry.checkClassAllowed(ServiceRegistry.java:722)at java.desktop/javax.imageio.spi.ServiceRegistry.<；init>；(ServiceRegistry.java:117)at org.geotools.factory.FactoryRegistry.<；init>；(FactoryRegistry.java:155)at org.geotools.factory.FactoryRegistry.<；init>；的ImageIOSPI类。(FactoryRegistry.java：146at org.geotools.factory.FactoryCreator.<；init>；(FactoryCreator.java:82)at org.geotools.referencing.ReferencingFactoryFinder.getServiceRegistry(ReferencingFactoryFinder.java:115)at org.geotools.referencing.ReferencingFactoryFinder.getFactories(ReferencingFactoryFinder.java:180)at org.geotools.referencing.ReferencingFactoryFinder.getCRSAuthorityFactories(ReferencingFactoryFinder.java:455)at org.geotools.referencing.DefaultAuthorityFactory.getBackingFactory(DefaultAuthorityFactory.java:89)at org.geotools.referencing.DefaultAuthorityFactory.<；init>；)。(DefaultAuthorityFactory.java：69)at org.geotools.referencing.CRS.getAuthorityFactory(CRS.java:263)at org.geotools.referencing.CRS.decode(CRS.java:525)at org.geotools.referencing.CRS.decode(CRS.java:453)at com.parknav.common.geo.TransformHelper.<；init>；(TransformHelper.java:33)at com.parknav.common.geo.TransformHelper$LazyHolder.<；clinit>；(TransformHelper.java:216)…。再来39次。

我们将不得不升级GeoTools，它将迁移到新版本的JTS。分析`gradle relencyInsight`的依赖关系，发现*hibernate-space：5.3.12 Final*和*gt-main：18.2*需要JTS。Spring Boot依赖管理插件选择了Hibernate空间版，[Spring Boot2.3.0已经发布](https://github.com/spring-projects/spring-boot/releases/tag/v2.3.0.RELEASE))。因此：

*我将Spring Boot升级到2.3.0*我看到Hibernate-Spatial使用jts-1.16*发现Geotools 21.x使用相同的JTS版本。地理工具的下一个版本使用jts-1.16.1，它可能不会破坏任何东西。最初停留在地理工具21中以使JTS版本匹配。Geotools 21.x是第一个支持Java11的版本，如下所述：[https://docs.geotools.org/latest/userguide/build/install/jdk.html]()，所以没问题。*从*COMMON*项目中移除显式依赖版本。*使用org.locationtech替换了所有出现的com.vividSolutions。