503 karma · joined October 25, 2013
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
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"
While I applaud them for their understanding and use of technology, it is a strange feeling to see the FBI start to think like the NSA. Given the positive PR of this approach+result other teams will most assuredly try to replicate it
One article to get you started (nothing special about this one, it's just the first I saw from google): https://www.wsj.com/articles/what-housing-crisis-in-japan-ho...
Sure, we can incentivize providers for reaching certain percentage rollouts under the new definition, but history shows us we should not consider schemes to help finance those buildouts.
Internet is not currently a utility, so unless we make it a proper utility with proper regulation before handing over money, the federal government is historically not capable of resisting lobbying pressure aimed at remove the teeth from similar subsidized buildout agreements. In almost all cases the money has disappeared without significant real world improvements.
For example, using the money intended for buildout to instead pay lobbyers to re-change the definition of broadband, thereby actualizing some stated goal of "75% of service area covered by broadband", and then pocketing the difference between the actual buildout costs and the lobbying costs.
If we offer a financing without regulation, we may as well move the money straight into the exec bonus category and totally ignore improving infra
I can't stand it when support is crippled by "policy" - half the time I think they can't either.
Side-note: service at Tesla used to be golden. When they first started, they all knew they were pricy cars and everyone expected some growing pains leading to QC issues. It was great - they would loan you a top-model performance tesla while your car was in the shop (great up-sell!!!), they were doing far more of their "mobile service" (super handy, they drive to you and fix the car where you are), and you would get one agent that called you almost daily with an update.
As they have expanded more towards mass market they have gone the way of google - trying to automate humans out of the loop. It's basically a miracle to talk to a human at a service center now, everything is "schedule it in-app where you get 200 characters to explain your issue, we send over an estimate, you can't call to discuss it either approve or don't, drop your car, use our SMS platform for 100% of communications because email might "violate your privacy" (read: leave a data trail), handle the fact that different agents get your SMS at different times and some have no idea what the history is, handle that agents now "have to reply to all messages before they leave" and you're getting hurried "here's my panicked update" messages at 11:30 at night.
I personally feel they missed an opportunity to offer "luxury service lanes" for folks buying the luxury line when they went mass market.
I know I am - I've bookmarked your website. I run a small R&D shop specializing in one-of-a-kind projects that typically have very non-standard toolchains. We are good at what we do, but we are not good at frontend work and often need a frontend dev to help us internally market a successful project -- e.g. we can build the best system ever, but if no one can see or feel it, it's always an uphill conversation to explain the value add to someone in the client organization.
> This is a fork of the excellent gideonred/dockerdoomd using a slightly modified Doom, forked from https://github.com/gideonred/dockerdoom, which was forked from psdoom.
Here you go: http://psdoom.sourceforge.net/screenshots.html