OSM is a truly incredible resource. It's often lightyears ahead of proprietary maps in terms of feature accuracy. Often far behind in terms of points-of-interest.
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
Not sure I'm fully following your question, but maybe this helps:
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."
Hi - I'm working on something like this because I needed it too ;-)
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"
We adopted Amazon's 6-pager strategy for meetings. It has been incredible helpful. TLDR - one person writes a document explaining the proposed feature, max length 6 pages. That one person does 80% of the work (whatever your org wants e.g. timeline, target customers, planned KPIs and/or ROI).
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)
> ...these are small enough to enter the body’s cells and tissues
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)
My ad experience has changed dramatically after I leaned into multiple browser personas.
In personal persona, I hate ads with passion and do everything to get rid of them (browser extensions, premium membership, etc). I value my personal time and the ads are totally useless.
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...
Think I read somewhere that of one of their content production differentiators is their direct-to-consumer approach. Classically lots of content was produced for the "average" consumer. Netflix can use their subscriber data to create low-cost content for extremely niche consumers, who might love that extremely relevant production (think super edgy, super graphic, super cartoon, etc - the type of extremes not covered by the average).
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
Not a stretch at all, it is perfectly reasonable to consider an app and an website embedded by the app as two completely different things. First there is no guarantee the WebView will open to a website owned/operated by the same entity that owns/operates the app, so it is definitely "outside the app". From the user's privacy perspective, you also want to communicate that just because the website might be branded "Facebook" and be run by Facebook and maybe you trust FB with your messages, but if it's an embedded browser opened via a WebView then the app can technically snoop on the private message you are typing into the WebView
This is saying "if an app opens a webview, the app can monitor your browsing activity inside that webview."
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).
There is some strange allure for spending time crafting Dockerfiles. IMO it's over glorified - for most situations the juice is not worth the squeeze.
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
Sure. Our solution so far has been both simple and pragmatic - the main DB's do not live inside containers. It's a bit of manual ops, but it works for us. All the 'media' in the stacks I am dealing with is minor enough to serve over a custom API e.g. no massive image/audio/etc datasets where files need to be first class citizens.
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
Wanted to second that Docker Swarm has been an excellent "middle step" for two different teams I've worked on. IMO too many people disregard it right away, not realizing that it is a significant effort for the average dev to learn containerization+k8s at the same time, and it's impossible to do that on a large dev team without drastically slowing your dev cycles for a period.
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
WOuld not be surprised - he's reported piracy issues in past. FYI I've ordered all books by emailing directly to an email on the website. He replies with "send paypal to xx if you want digital only, send xxx if you want me to mail you a hardcopy". clunky relative to an amazon order but it gets the job done
Passion comment: I'll second that most of Jonathan Levin’s books are outstanding, some of my favorite technical guides.
Spent many years as senior dev for a custom Android ROM, yet Levin's book still introduced me to multiple other Android internals I had not yet looked into. Would happily pay 200-300 for his next Android book. Probably not the best books for a total beginner, but if you're already skilled and looking for the next level I would highly recommend.
My only real complaint is that JL seems to do a lot of the marketing/date-setting himself, and it shows. It can be really confusing to keep current on what book he is working on next, what topics will/will not be covered, how to even pay for the book can be a bit complicated (send paypal to this email), etc. It is fantastic that he adjusts and expands book contents as the market/technology changes (e.g. always chasing to get the newest stuff covered in the newest book), but the current end result is a stream of "update" messages on his website that are hard to follow. Would be wonderful if he had someone help him with that "public-facing" side and try to keep things organized/consistent/obvious and hide a bit of "how the sausage is made"
https://wiki.openstreetmap.org/wiki/List_of_OSM-based_servic...