I setup an eBay alert and picked up a used M2 Ultra that has delivered good ROI (at least, far better than 15k for comparable-for-my-use-case performance)

https://wiki.openstreetmap.org/wiki/List_of_OSM-based_servic...

It powers painless adding of maps to so many products, painless offline data analytics and joins (I built https://wildpocket.com/ by joining OSM to iNaturalist data).

Truly incredible and under appreciated by general public. I love street complete, it opens up OSM to so many beginners with the simple UX. I think there's an ongoing need for "beginner-friendly" OSM tools - I've prototyped https://mapmender.com/ to help map the "last mile" routes for emergency response that are inherently hard to keep updated. It's a WIP passion project, feedback welcome

This appears on their credit purchase page right now, but you have to email them to get credits (everyone starts with zero)

IME deep thinking hgas moved from upfront architecture to post-prototype analysis.

Pre-LLM: Think hard → design carefully → write deterministic code → minor debugging

With LLMs: Prototype fast → evaluate failures → think hard about prompts/task decomposition → iterate

When your system logic is probabilistic, you can't fully architect in advance—you need empirical feedback. So I spend most time analyzing failure cases: "this prompt generated X which failed because Y, how do I clarify requirements?" Often I use an LLM to help debug the LLM.

The shift: from "design away problems" to "evaluate into solutions."

- Did it cite the 30-day return policy? Y/N - Tone professional and empathetic? Y/N - Offered clear next steps? Y/N

Then: 0.5 * accuracy + 0.3 * tone + 0.2 * next_steps

Why: Reduces volatility of responses while still maintaining creativeness (temperature) needed for good intuition

It's not yet ready for release, but I should be ready for beta-test within 2 months. If you're interested I would be happy to add you to my list of "people to notify when I am ready to beta test"

Process: Start the meeting, turn on your camera (surprisingly important for us), and set a timer. Everyone quietly reads for ~20min. AFTER they finish reading, restart and engage via comments - positive/agreement comments are great, questions are useful, answering/responding to other's questions is encouraged. Post 20min, one speaker goes through the comments. Many (70% is common for us) will already have been resolved or will not require discussion. Long comment chains or lack of consensus on a comment chain is where we spend the discussion time. Common pitfall - Speaker DOES NOT present the document, that just wastes 20min and bores everyone to death. Small nuance - speaker (doc preparer) is already familiar with doc, so they watch the timer. They also check in e.g. at 15 give a 5min warning, at 20min check if anyone needs more time, etc.

Huge net positive for us: - No more "pre-read" (no one does it), we just say that a 45min meeting is when you BOTH get the information AND discuss is - Post the "20min" we are already 80% on the same page - Far far fewer "basic" questions that kill time - those were answered by the doc - Quiet reading gives people time to mentally switch/shift from their last 5 meetings and come up to speed. Less "anxious energy" when talking - Increase collaboration - "Type A" talkers cannot (as easily) dominate the comments. Leaves "airshare" for quieter team members to participate via comments. We've begun encouraging all to leave at least 4-5 comments

Negatives: - REQUIRES senior team member support, else 1 senior "ass" will break the rules and start talking - Writing the document is time consuming and not easy. This really becomes one persons "work" to gather the data from all stakeholders in a 1-1 fashion, organize it, summarize it

No because the official OSM tile layer is heavily subsidized by Fastly (€720k last I checked) and rendering by AWS (€40k)

Yes because technically it would use fewer resources thus easier on AWS+Fastly and also easier to self-host

In last risk assessment I read closely(1) OSM noted "If we lost [Fastly] sponsorship, we would likely cut off all third-party access to the standard tile layer and run a small number of Varnish servers."

As I understand it, primary drivers for vectors was not cost more improving internationalization, generally enabling client-side rendering decisions, and driving a modern toolchain that would net multiple follow-on benefits

I'm a bit behind, there is more recent info available at (2)

1.https://operations.osmfoundation.org/2024/01/25/owg_budget.o... 2. https://osmfoundation.org/wiki/Finances

<3 wonderful project. Brings back memories of excitedly writing HTML in my drawing notebook and daydreaming what the pages would look like

Same. No training to identify concern vs FUD in health news, but I'm erring on side of caution. We are limiting exposure to plastic drink bottles in general (sport drinks in plastic during/after children sporting events are common where I live)

In work persona, I suddenly have found ads are actually useful. Often find myself choosing to spend 30 seconds watching a YouTube ad because it is relevant to topics I need to be aware of as a CTO. It's clear my daily browsing history influences the ads I am seeing, and I see useful information. Been looking into SIEM tools lately, and via an ad I was just made aware of some data center appliances for security. I clicked to their website and browsed a while to learn what was available. When you have some real challenges to solve and the targeting is on point, ads can be a great news feed.

Clearly segmenting my browser history into one persona where I am actively looking for solutions vs my personal persona where I want to be left alone helped the feeds target me.

Still, surreal feeling to intentionally choose to watch an ad...

Not sure how much this holds true anymore, as now many big players have direct-to-customer streaming, but just sharing since it was a neat thought when I first read it

It is written vaguely and should be re-written to be precise, but as they are going for "end user" language here I can understand that it is hard to communicate to non-technical users that "embedded browser" and "browser" are different things given that they have similar UX and similar functionality.

A common use case of an embedded webview is an app that uses a website for some portion of a user flow, IME this is typically when there is a B2B2C business relationship. I think it can also happen for an OAuth2 integration but I'd expect there are some iOS native SDKs that are preferred. IME, many businesses use "web SDKs" instead of native libraries, and their integration guide will say something like "have your app open a webview to URL X, then user does Y as we have agreed, then we will close the webview" (occasionally, a few will use hooks in the webview to communicate result information to the native app).

As a process for getting stuff done, a standard buildpack will get you a better result than a manual Dockerfile for all but the most extreme end of advanced users. Even for those users, they are typically advanced in a single domain (e.g. image layering, but not security). While buildpacks are not available for all use cases, when available I can't see a reason to use a manual Dockerfile for prod packaging

For our team of 20+ people, we actively discourage Dockerfiles for production usage. There are just too many things to be an expert on; packers get us a pretty decent (not perfect) result. Once we add the packer to the build toolchain it becomes a single command to get an image that has most security considerations factored in, layer and cache optimization done far better than a human, etc. No need for 20+ people to be trained to be a packaging expert, no need to hire additional build engineers that become a global bottleneck, etc. I also love that our ops team could, if they needed, write their own buildpack to participate in the packaging process and we could slot it in without a huge amount of pain

We generally avoid mounting volumes at all costs. The challenge of mapping host uid:gid to container uid:gid (and keeping that mapping from breaking) proved painful and not worth the effort

When migrating from a non-containerized deployment process to a containerized one, there are a lot of new skills the employees have to learn. We've had 40+ employees, all who are basically full of work, and the mandate comes down to containerize, and all of these old school RPM/DEB folks suddenly need to start doing docker. No big deal, right? Except...half the stuff does not dockerize easily requires some slightly-more-than-beginner docker skills. People will struggle and be frustrated. Folks start with running one container manually, and quickly outgrow that to use compose. They almost always eventually use compose to run stuff in prod at some point, which works but eventually that one server is full. This the is the value of swarm - letting people expand to multi-server and get a taste of orchestration, without needing them to install new tools or learn new languages. Swarm adds just one or two small new concepts (stack and service) on top of everything they have already learned. It's a god send to tell a team they can just run swarm init, use their existing yaml files, and add a worker to the cluster. Most folks start to learn about placement constraints, deployment strategies, dynamic infrastructure like reverse proxy or service mesh, etc. After a bit of comfort and growth, a switch to k8s is manageable and the team is excited about learning it instead of overwhelmed. A lot (?all?) of the concepts in swarm are readily present in k8s, so the transition is much simpler