dylrich

Location: Minneapolis, MN

Remote: Yes

Willing to relocate: I am willing to consider a few other places in the U.S. or Canada. I strongly prefer remote or local to Minneapolis

Technologies: Go, Python, JavaScript, PostgreSQL, Redis, Kafka, Elasticsearch, GIS

Website: https://dylrich.com

Email: dylan[at]neatmaps.com

Resume: Available on request

I am looking for a position primarily writing Go, but I am certainly willing to work with other languages -- Python, Rust, or Elixir would be great. I have extensive experience in geospatial, GIS and mapping technologies from frontend to backend. I currently handle productionizing data science outputs, including machine learning models and complex data aggregations, for a SaaS product in the logistics space. I'm also interested in deployment technologies and would consider a position on an operations/"DevOps" team.

Location: Minneapolis, MN

Remote: Yes

Willing to relocate: I am willing to consider a few other places in the U.S. or Canada - I strongly prefer remote

Technologies: Go, Python, JavaScript, PostgreSQL, Redis, Kafka, Elasticsearch, GIS

Website: https://dylrich.com

Email: dylan[at]neatmaps.com

Resume: Available on request

I am looking for a position primarily writing Go, but I am certainly willing to work with other languages -- Python, Rust, or Elixir would be great. I have extensive experience in geospatial, GIS and mapping technologies from frontend to backend. I currently handle productionizing data science products, including machine learning models and complex data aggregations, for a SaaS product.

"Gofmt's style is no one's favorite, yet gofmt is everyone's favorite"

Happy Black user over here!

Location: Minneapolis, MN

Remote: Yes

Willing to relocate: I am willing to consider a few other places in the U.S. or Canada - I strongly prefer remote

Technologies: Go, Python, JavaScript, PostgreSQL, GIS, Docker

Website: https://dylrich.com

Email: [email protected]

I am looking for a position primarily writing Go, but willing to work with other languages occasionally. I have extensive experience in geospatial, GIS and mapping technologies from frontend to backend. I currently handle productionizing data science products, including machine learning models and complex data aggregation products, for a SaaS product.

RDS now supports libprotobuf-c, so AsMVT will work (at least on some postgres versions)

If anyone from DO is around - Will libprotobuf-c be available on managed postgres? I ask because for the longest time AWS RDS didn't support cutting Mapbox Vector Tiles from PostGIS.

Postgres RDS is missing libprotobuf-c, which is a dependency for cutting MapBox Vector Tiles if you use PostGIS/Postgres that way. A small, legitimate exception to your statement.

https://forums.aws.amazon.com/thread.jspa?threadID=277371

I'm surprised about this as well. Even if they didn't want the overhead of running their own tile server, one of the best parts of the MVT format in my mind is that one-off tilesets like this layer can trivially be thrown into S3 and served extremely cheaply as well. That removes a ton of the effort they put into circumventing MapBox's limitations and is cheaper to host.

It's interesting seeing the process they went through to work around MapBox's hosting limitations, but the map doesn't feel terribly usable to me. The chart doesn't update on pan/zoom (at least for me in Firefox) and the raster area is a little funky, I wish it was using a standard interpolation that covered everywhere instead of selective areas.

Also, I am loading a ton of data on this page. Interactive maps are nice and I love them but it's totally not usable on a mobile network for a ton of people (ironically given the content of the map). Very curious why they are using React at all, seems like extra page bloat for just one interactive map + chart. Do they test usability on 3G networks? I did not have great load times when off wifi. I think this would be better on a stand-alone page so you can read the article without having your load time impacted by the extra JavaScript.

I'm interested in their reasons for not using an R-Tree or an R*-Tree for the index. I know they mentioned the debate in this post but I'm quite curious how they arrived at their decision. Have they done performance tests with both methods? Many other high performance applications use R-Tree based structures, and I've always been under the impression that R-Trees usually outperform Quadtree style indexes in PIP queries.

HipChat (At least for me on Windows) absolutely messes up any SQL I try to send to someone. It's unusable because HipChat apparently adds characters to the beginning of each line. At this point I just email the SQL, but I really shouldn't have to for quick and dirty queries.

Portable mode is huge for those of us who have worked in places with unnecessarily restrictive IT departments :)

I am also wondering how Linux runs on this. A Windows-only machine is out of the question for me, but the hardware looks pretty solid. I'll consider buying one if I can get Fedora to play well with it.

You make ~$90,000 a year and are barely getting by with no debt or children? Where do you live?

His arguments for it seemed reasonable - would love to hear your criticisms