Developer Logs

Sergei Kozyrenko
aiincube-engineering
3 min readOct 14, 2020

Many remote-first companies have been moving their meetings, stand ups, onboarding and kick-offs to be asynchronous. It’s not a silver bullet, but makes a lot of sense when your team is spread out across many timezones. Inspired by this, we’ve tried to combine async standup meetings with a local “Stackoverflow” and came up with what we call “Developer Logs”.

Developer Logs are basically brain dumps of the issues our developers encounter on a daily basis while building our Parknav parking predictor. Our dev team is small, and we all wear multiple hats — so it’s not uncommon for someone to become a full-stack dev for a couple of months even though they are primarily working on the backend. Or for a backend developer to build some machine learning models. And that’s when all kinds of interesting issues show up…

We also use these for general overview of what everyone is working on, so sometimes they replace our daily Zoom stand ups when everyone is too busy.

Reviewed all slack messages, read all mail, checked out code. Had a coffee. Everyone’s asleep. I braced myself for the day ;)

How to “clear” a pubsub topic?
Seek to current date time

gcloud pubsub subscriptions seek subscription-id-here — time=$(date +%Y-%m-%dT%H:%M:%S)

The offending garage has a minimum tariff but no maximum one. Seems like a valid pricing model: just 2€/hour forever
(instead of a typical pricing model like 2€/hour for 5 hours and then 10€/day). Fixed the code and added some tests.
There was a problem with the parsing of *IndicativeTariff* that I consider a bug. Added some more tests.

How to set up JMeter to use random locations?
User /randomLocations from calc-server to generate a csv with N lat,lon pairs
In JMeter, use CSV Data Config element and assign them to lat,lon variables
In HttpRequest, use ${lat} and ${lon} in places where they are needed.

We write these logs in Markdown and push them to a dedicated Git repo — something like Notion (or even private Stackoverflow) would’ve worked as well, but some of these logs end up with too much information on our infrastructure and code base. We also wanted to have access to them when we’re offline.

In general, having a repository that we can grep for common problems related specifically to our codebase has been invaluable. It lets us find the issues others have also solved, keep track of what everyone is working on, and also reminisce about the fun times some of us had ;)

Setting the aim now to the execution of the tests with Java 11.

PROBLEM. We get this exception trying to run map-provider tests. Probably we need to update geotools:

Caused by: java.lang.IllegalArgumentException: org.opengis.referencing.datum.DatumFactory is not an ImageIO SPI class
at 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>(FactoryRegistry.java:146)
at 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 more

We’ll have to upgrade geotools, which will move to a new version of JTS. Analyzed the dependencies with `gradle
dependencyInsight` and found that JTS is required by *hibernate-spatial:5.3.12.Final* and *gt-main:18.2*.
Hibernate-spatial version is selected by Spring Boot dependency management plugin and [Spring Boot 2.3.0 has been
released](https://github.com/spring-projects/spring-boot/releases/tag/v2.3.0.RELEASE) recently. Thus:

* I upgraded Spring Boot to 2.3.0
* I saw that hibernate-spatial uses jts-1.16
* Found that geotools 21.x uses that same JTS version. Next versions of geotools use jts-1.16.1 which probably won’t
break anything. Initially staying in geotools 21 to make jts versions match. Geotools 21.x is the first version
supporting Java 11, as stated here: [https://docs.geotools.org/latest/userguide/build/install/jdk.html]() so it’s ok.
* Removed explicit dependency version from *common* project.
* Replaced all occurrences of com.vividsolutions by org.locationtech.

--

--