mourner

> Ukraine threatens to invade DPR and LPR

That's what Russian propaganda says, but it has no basis in reality.

There was a big HN discussion about it a few months back https://news.ycombinator.com/item?id=25347310

Yes! Although this particular one was a year later, I got runner-up and a bunch of tech books as a prize :)

So many fond memories of being in this community around 2004–2006! I got a 1st place prize in a Textpattern theme design contest and won my first ever prize, and quite a big one for a Ukrainian student — an iPod (the original one, 60GB). Having my own digital music player was life changing at the time!

Great to hear Textpattern is still around. Loved it for its simplicity, easy customization and a friendly community.

One of my favorite tech presentations ever! So much uplifting enthusiasm, witty and whimsical humour and good taste in the songs, love it. Really happy that it belatedly got on the HN frontpage — it really deserves more views. Go Anjana & Natalia!

I have a ton of unfinished open source projects, but here's a recent small one I believe can take off:

https://github.com/mourner/tinyjam — a bare-bones, zero-configuration static site generator that deliberately has no features, an experiment in radical simplicity.

Essentially a tiny, elegant glue between EJS templates and Markdown with freeform structure (enabling incremental adoption) and convenient defaults, written in under 120 lines of JavaScript.

I also made a modern EJS implementation specifically for this: https://github.com/mourner/yeahjs And planning to implement a strict, minimal subset of YAML to switch over to: https://github.com/mourner/yeahml

Will be happy to hear any feedback :)

There may be no difference for you with this level of vitriol, but there's a difference for hundreds of people who have jobs, and for dozens of engineers like me who will keep contributing to open source significantly at work hours.

Speculating (remember that I'm just an engineer and not in charge of business decisions), but perhaps because Mapbox tried really hard to build a business on server-side services alone while gifting most of its innovations to the world, and after a decade of enormous effort, keeping the client of such enormous complexity fully open source appears to be unsustainable? Would you rather see Mapbox getting eaten by big tech corporations and ceasing to exist?

> We'll probably end up removing Mapbox from the deck.gl examples

If that's because of the licensing, would you remove Google Maps & ArcGIS examples as well?

Thanks! We're going to look into that soon https://github.com/mapbox/mapbox-gl-js/issues/9945

I wouldn't be working for Mapbox if it actually were a villainous company with an evil plan to "bait and switch" with open source, or undercut all these small competing businesses just out of spite, and it's easy to succumb to these simplistic conspiracies in the heat of the moment, but I do hope these sentiments will be short-lived.

7+ years to be exact. It's unfair to call Leaflet dead — it's still quite actively maintained, gets regular releases and has a huge community of both users and contributors, and Mapbox have always been supportive of me spending time on it during work hours.

What someone can see as less development activity is simply a sign of a mature product that doesn't need many new features and changes to remain useful — focusing on the core basic mapping needs has always been its goal, and it continues to adhere to it.

I'd say extremely unlikely — it wouldn't make sense both technically (stable, mature, small, razor-focused libraries that are already open source) and business-wise.

As far as I know as someone who worked here for 7+ years (take this as personal opinion), Mapbox wants to keep investing heavily in open source and open data sustainably and indefinitely, and this GL JS change is an unevitable prerequisite for that. This may not be easily apparent at this moment but it will be soon.

Thank you! I'd also like to list some of the building blocks of GL JS that remain open source and are heavily used in other open source projects:

- GeoJSON-VT (fast GeoJSON processing) https://github.com/mapbox/geojson-vt

- Earcut (triangulating polygons) https://github.com/mapbox/earcut

- Supercluster (point clustering) https://github.com/mapbox/supercluster

- vt-pbf (converting GeoJSON tiles to VT) https://github.com/mapbox/vt-pbf

- vector-tile (decoding vector tiles) https://github.com/mapbox/vector-tile-js

- pbf (fast reading/writing of protobuf) https://github.com/mapbox/pbf

- TinySDF (generating SDF from local CJK fonts) https://github.com/mapbox/tiny-sdf

- Potpack (generating sprite layouts) https://github.com/mapbox/potpack

- grid-index (spatial index for collisions/querying) https://github.com/mapbox/grid-index

- Pixelmatch (image comparison in render tests) https://github.com/mapbox/pixelmatch

- Polylabel (fitting labels into polygons) https://github.com/mapbox/polylabel

That's pretty unfair. Once you spend a little time to understand its concepts, it becomes second nature, and it's really a joy to use.

The fact you can reorder cells in any way you want (and import cells from other notebooks) is the whole point — this way you can build narratives with code, embedding important bits in the story while leaving out fluff like imports at the bottom. Maybe you just haven't seen notebooks that take good advantage of this, but I'll shamelessly plug mine as an example: https://observablehq.com/@mourner/martin-real-time-rtin-terr...

You do have access to nearly the whole NPM ecosystem. Most useful packages either provide a browser build in their package (which gets picked up automatically), or you can use https://bundle.run/ to produce a browser bundle for any Node package.

There’s exactly the same anecdote in the popular book “Atomic Habits” but instead of pottery, it’s a photography class.

You are either colossally misinformed on the issue of Kyiv vs Kiev and the way geographic name spellings are formed, or use this deliberately as an outlet for colonialist sentiments. I hope it's not the latter.

"Kiev" is not an English word. It's a transliteration of Russia's spelling of the city name, back from the times when Ukraine was a part of an oppressive dictatorship that killed millions of Ukrainians (Soviet Union). Ukraine is now an independent country with Ukrainian as its official language (and has been for three decades, and it fought for this right for centuries). Kyiv is a direct transliteration of the city name from Ukrainian. It has now been adopted by governments & major media across the globe. If you don't like, deal with it.

Yep! It can be solved for some specific cases though — e.g. I stumbled upon a few papers that calculate the optimal path for parallel parking using systems of differential equations [1][2]

[1] https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7463491

[2] http://www.tsi.lv/sites/default/files/editor/science/Researc...

Yep, mine has it too and it's super helpful! What I have more trouble with is feeling when the right front side is about to collide when the car sways in the other direction — there is some beeping proximity detector but it doesn't seem to work well against bollards.

Nice video! I only saw it a few hours ago when I was about to post my viz on /r/math :)

Good question! Since the model is reversible (you would have the same trajectory when pulling out of the parking lot when reversing the steps), you can see the effect there — seems like it would cross the rightmost edges but very slightly (like 10cm) in my case, but protrusion would be bigger with a car that has a bigger rear overhang (e.g. sedan rather than hatchback). You can try it out by tweaking the constants in the car specs section.

That's a great cue! Seems to work on the viz too (if you set x = 6.7m & y = 2.6m). BTW Mini Cooper look like the perfect car for parking conveniently in tight spots.

Yeah, the model is definitely contrived and I could try adding a lot more to it, but I still found it very useful just to understand how the path changes with the wheel turn.

Also, as a beginner, it's very hard to "feel" how much you're supposed to turn with variable rate — I guess this only comes with a ton of practice. In the driving school, the way we were taught all the parking maneuvers is to reverse straight until you catch some reference point, then immediately turn to the max for the sharpest turn.

Awesome! This paper uses the same model for calculating wheel angles (Ackermann steering geometry).

Observable makes it easy to fork notebooks and make modifications, so I'll be happy to see other parking arrangements!

I made the viz for my real-world situation — reverse angle parking is quite common where I live (Ukraine), and it's the type where we got our parking spot (took a long time since all the spots around my apartment complex are sold out). https://en.wikipedia.org/wiki/Back-in_angle_parking

There's just one lane here — the thick line at the top is a barrier (a line of bollards).

Thank you! A fellow programmer Jacob even printed that viz as a woven textile — floating point errors can be very pretty :) https://twitter.com/jashkenas/status/1191829600214507520

It's easy enough if you have enough space, but in this case the road is so narrow that I can't move forward much in the second maneuver. I'm sure I'll figure out the right angles with practice eventually, the reverse turning movement just feels very counter-intuitive when starting out (I just got my driver's license) — at least I can understand it better now.

If you find any errors in the math, please let me know! I think the diagram supports your description — even with the wheel turned to the max, you will never hit anything close to the back wheel when reversing (both wheel axes are marked), although the geometry will depend on the car specs like wheel base, overhang lengths and car width (the viz is for my car, Hyundai i30 2018). Also, I just looked up top-down views of reverse turning on YouTube and it seems to match. [1]

The problem in my case is that the road is so narrow that it's very easy to hit the barrier on the right when reversing while turning to the left — that was what prompted me to make the visualiation.

[1] https://youtu.be/c3AgaHGbE1Q

Note: I didn't create Mapbox GL, I'm just a part of the core team: https://github.com/mapbox/mapbox-gl-js/graphs/contributors

Don't have any particular OpenLayers examples in mind at the moment but it's very heavily used in government, enterprise and academics — sectors that often need advanced projections, use various obscure formats / protocols and prefer all the features to be packed in one product and maintained consistently by one team.

For Mapbox, here's a showcase https://www.mapbox.com/showcase. It especially shines in apps that need to render hundreds of thousands of features at once, maximum customization in how the map looks and feels, updating map appearance dynamically in real time, or some cool animations.

In terms of features, Leaflet has a huge plugin community and there's a plugin for pretty much any feature since it has been around for 8 years, although their quality varies (the core is top-notch though). Mapbox GL will need to catch up on that front certainly, but on the other hand, there are things that are simply not possible with raster-based mapping libraries — things like making any feature you see interactive, changing the map appearance in real time, rendering millions of features (with high perf viz features like clustering, heatmaps, advanced labeling etc.), and general smoothness of user experience (smooth zoom transitions, labels adjusting to rotation and pitch, etc.).