I just deployed a wasm built SQLite with FTS5 enabled and it’s insane what it is capable of. It’s basically elasticsearch entirely on the client. It’s not entirely as robust as ES but it’s like 80% of the way there, and I repeat, it runs on the client side on your phone or any other SQLite supported device
My experience mirrors yours wrt Datadog. It's incredible value at low scale, you get a full robust system with great devex for pennies. Once you hit that tipping point though, you are locked in pretty hardcore. Datadog snakes its way far into your codebase, with all the custom tracing and stuff like that. Migrating off of it is a very expensive endeavor, which is probably one of the reasons why they are such a money printing operation.
I think "medium scale" is probably more appropriate. For a $3M~$5M revenue SaaS you're still paying $50k+/year. That's not nothing for a small owner or PE backed SaaS company that is focused on profits/EBITDA.
Yeah, the secret sauce of the dd libs was/is addictive for sure! I think its perhaps better now you can just use oTel for custom traces and oTel contrib libs for auto instrumentation and send that to the dd agent? I have not yet tried it because i suspected labels and other things might be named differently than the DD auto instrumentation/contrib packages, but i don't think the gap is as big now?
An old colleague of mine went through the process of doing gridfinity. One of his main struggles was getting boxes that fit his power tools perfectly. He was looking for a way to easily get a shape of the tool into CAD. What’s the most straightforward and effective way to get a CAD representation of a solid these days? Of course there are expensive solutions but is there anything reasonably achievable in the DIY space?
Imho thats overoptimizing. To me the next larger square box is the best most flexible solution. I get the allure of perfect fit places for everything but to me its not worth the continuous effort. (I got several gridfinity drawers)
The common approach is to take a photo of an object from above together with a ruler or something of a known size for scale, then import that directly into the CAD software, scale according to the scaling object, and create a cutout along the object's outline. No need for calipers, 3d scans, or other complex measurement procedures. There are a lot of videos and guides on how to do that.
You could get a table mat with a measuring grid and take photographs of the object from different sides; three or more depending on how much asymmetric features the object has. Go as far away from the object as possible and use maximum zoom to get as close to isometric perspective as possible. If it’s not a very thick object, this method is millimeter accurate. With larger objects, the perspective will lead to slightly larger measurements at the object extremities: edges closest to the camera will be enlarged.
Then, in your CAD program, set up the photos as backgrounds for different perspective views.
Or, obviously, get a 3D scanner and live with the point cloud mesh approximations, it’s probably less of a hassle.
Or… just get a good set of calipers and a radius measuring tool.
Well if you want to get dirty and not deal with design, build a vacuum former. Shop vac, perf board, 2x4 or 1x2 frame and whatever rigid for a backer. Build the frames out of screen door frame pieces, and binder clips to close them. Polystyrene sheets are cheap af $.05 or less at any plastic supplier. Never been to a plastic supplier? I guarantee theres one relatively near by in whatever is your closest major city.
Use your oven to heat the plastic. Turn on the vac, pull out the plastic when it droops, slam down quick… perfect part. Lots of videos on youtube. Adam savage does a few on the process. Lots of nuance to the process to get really good pieces but for cheap, quick and good its hard to beat. Oh yeah the whole stormtrooper cosplay scene has done a lot of work on the setup, most definitely lots of improvements that I’m glossing over but like all rabbit holes its pretty deep.
I'm sure your colleague has done this already, but for anyone considering creating their own models, I would highly recommend checking whether somebody else already went through that process for you. A lot of things have been fitted into gridfinity. And even if not for gridfinity specifically, you can fairly easily adapt other existing models to a gridfinity based box.
There are 3d model search engines where I recommend just entering [item name] + gridfinity to find pre existing models. There is: yeggi.com and thangs.com (be aware that the latter recently changed to only display models from its own domain by default).
Photogrammetry is one. Generally results in messy geometry though and tolerances get finicky.
The CAD plugin in Blender is my favorite though. Need a caliper to get measurements and then I can build out my hooks/clamps/whatever. FreeCAD for when I just need sketches as I find the solid part workflow utterly confusing, whereas I'm very well versed in Blender.
> Photogrammetry is one. Generally results in messy geometry though and tolerances get finicky.
The trick is a hybrid approach, use photogrammetry to get a draft model into whatever environment you use (like Blender or whatever), then use that for creating the high-quality cutout manually, which will be very easy with a in-place 3D draft model right in the scene.
The funny thing is, this is actually against ToS (or at least was at some point, I'm not sure if it still is). Apple just blatantly lets companies walk all over it if they are big enough. Doordash and Uber are two huge examples beyond Amazon.
> Push Notifications must not be required for the app to function, and should not be used to send sensitive personal or confidential information. Push Notifications should not be used for promotions or direct marketing purposes unless customers have explicitly opted in to receive them via consent language displayed in your app’s UI, and you provide a method in your app for a user to opt out from receiving such messages. Abuse of these services may result in revocation of your privileges.
To be honest I would like to see Apple be more strict with this stuff in App Review. It's frustrating what some of the big apps get away with.
I’ve had Uber notifications disabled, but using it last week noticed that it now plays ads in the UI when showing where my car’s at - so I’m done with Uber and going back to taxis.
You're 100% right. It's still against the TOS. But enough money (For Apple) will make the fruit ignore a lot of things. Sadly, this has always been the way of corporations.
Nordic makes some good products. When I was doing hardware design for a product that uses a battery my options for power profiling were either not to do it or spend some eye watering amount of money. Then I discovered Nordic makes the PPKII, a cost effective, highly accurate profiler with quite good software. I detect good things in store for the company just based on the quality of stuff they have been putting out.
The TinyCurrent or uCurrent can be used for this as well when paired with a scope with scpi. However, the ranges aren't dynamic which is annoying if you're using something a WiFi part where you're going from uA to 200mA.
and godawful software. the SDK for their NRF52/3/4 is pure madness, i haven't even managed to set up the toolchain, documentation always out of date.
They used to have another toolchain for the older parts, but good luck setting it up now.
I spent so much time trying to get the SDK working for NRF52 that I genuinely just gave up and redesigned our whole product to use an ESP32 instead of the NRF plus other uC.
I think that is genuinely the reason espressif is eating everyone's lunch. All the old players in the IC business have such inexcusably bad SDKs that the acceptably designed and documented ESP-IDF framework just makes the most sense to use. Why would I spend six weeks fighting with Nordic SDKs with their weird system-wide installation when ESP-IDF can be set up in five minutes isolated to your user directory?
Seriously, it takes longer to find the correct Nordic SDK installer than it does to git clone, idf.py install, ./export.sh
And Nordic's weird documentation web portal is just egregiously bad. Espressif puts it in a static HTML page with a selector for the framework version. It's simple, elegant, and fast.
I did like using the NRF52 once it was finally behaving, but the ESP is just so easy.
I've found old SDK actually not that bad. Documentation is not great, but sources are available and it's just mostly C code with some hairy macros, but it's manageable. After few weeks I became quite proficient. I don't like their suggested approach "copy&paste example you like and tinker it", I never do that, so I had to untangle their Makefiles, I had to research their defines (app_config.h, what's a monstrosity), I had to write my own linker scripts, but in the end I have my application under control and it's all standard gcc toolchain, no fancy stuff.
> I don't like their suggested approach "copy&paste example you like and tinker it", I never do that, so I had to untangle their Makefiles, I had to research their defines (app_config.h, what's a monstrosity), I had to write my own linker scripts, but in the end I have my application under control and it's all standard gcc toolchain, no fancy stuff.
I'm sorry you've had a bad experience but I don't agree, I prefer it to the ST, TI and definitely the Microchip tooling. It's CLI first, like the Espressif and Pico tooling which is a big plus for some and not for others.
Also, no mandatory login walls for toolchains and datasheets gets them a lot of goodwill in my book.
Microchip tooling: download, double click, install, just works. Zero need for any framework, good bare metal support. a C project is an actual C project. Granted, if you use that MCC piece of shit you're in for a bad time, but going bare metal require zero effort, a single include file if you need to access peripherals, and you actually have documentation to do so.
ST tooling: sort of almost just works, more effort but you can still go bare metal with relative ease.
Current nordic: it's actually a zephir project, thousands of files to generate and compile. No options to go bare metal. (used to be possible with the older SDK, or so they tell me. Too bad i can't seem to be able to let a project compile with the old SDK, or set up the IDE for intellisense with the new SDK, but i haven't had enough time yet.)
Bonus: Espressif. At least their VSCode integration really just works. The peripherals are frustrating and severely bugged though and there can be supply chain issues, and that's the reason i'm looking at nordic for some BLE-enabled project, because the ESP32 parts won't cut it for this or that reason (usually the basic yet still bugged peripherals).
But i'm willing to put up with microchip's BLE modules again (i evaluated them several times over the years, always a disaster. But not the newer based on PIC32MZ, and the price have come down to be reasonable.) if the only option with nordic is the zephir monstruosity.
I completely agree. I spent lots of time trying to figure out their modern SDK, but in the end I abandoned it and just used their old SDK. Their examples and approach are terrible, but in the end I was able to make it work, after untangling the holy mess of macros they put there. Their old SDK is bearable, their new SDK... I still think I need to go there, but I don't have enough willpower to do that. So much moving parts. Custom build system, not just one, but actually three of them at once (cmake, ninja, west). The whole RTOS which I never needed. And not just simple one like FreeRTOS, but absolutely humongous one. Add their terrible software which they insist I must use to install their stuff. Just give me zip, I don't want to install nothing.
Let me write simple Makefile, give me thin layer over CMSIS called SDK and that's all I need. Don't make things harder than they should be, my project is simple, I don't need operating system for it.
i did not use Nordic-Zephyr, but i have run Zephyr on ESP32/STM32.
It's true that the learning curve is very step, but their idea is reasonable.
The execution is ... not that good at this moment imo. It's nearly impossible to debug device tree "macro hell", the preprocessor is not designed to debug that, and they abuse the hell out of it.
Also i'm wondering why you dont want "RTOS", in Zephyr setup, your entry point is still old boring "main" loop.
Installing a whole toolchain and SDK system-wide is such nonsense.
Espressif's toolchain and SDK are in a git repo that you add as a submodule, or in a directory anywhere you want.
If I want to use microchip or Nordic on a new machine I have to go through this whole process of installing and configuring everything. My ESP projects simply involve a git pull and I'm done.
Nordic was a special pain in the ass because I had to hunt for the exact correct version of the SDK which was hidden away because it's a few versions old. If I need to do the same for espressif, it's literally just a git switch away.
Espressif is in an entirely different league from ST, nordNordic, et al. They're not even playing the same game. Espressif wants anyone and everyone to use their stuff and ST seems to actively hate developers and only want to work with companies buying tens of thousands of units. Like, ST cripples their USB programming tool to only accept 'genuine' ST parts. It's frankly disrespectful.
I mean, you _can_ go bare metal with Nordic chips, but you'd definitely be swimming against the current. I'm not a fan of Zephyr, but it really wasn't that much trouble to put together a docker image that would let me spin up whatever version of the SDK I needed and then just build from the docker. Quite tolerable.
We have lower power bare metal systems, think AVR/STM stuff (in the 1Mhz to 50Mhz range with 128K or less of RAM) here FreeRTOS, no freeRTOS, custom driver code and some basic application code makes sense. For simple to very complex systems.
Then there's 1Ghz+ stuff with an MMU and 2GB+ RAM. Linux makes sense here.
Companies are now making chips 200Mhz+, 4MB RAM, with no MMU. This is precisely where Zephyr excels, you want a full networking stack? Switch that on. A file system, easy. Driver for some more complex thing? Maybe an SDIO radio? boomboom
nRF52820 is 256 KB Flash and 32 KB RAM chip. Actually it's around 150 KB flash, because you need space for 120KB softdevice blob (and some RAM too). And it's perfectly enough for many devices. They want developers to use Zephyr for this chip.
Segger Embedded Studio is a complete solution. One installer. You might need to pick an older version to go with an old SDK version, but its very straightforward.
Looks like it switches different ranges. ST makes something similar that has similar dynamic range without switching. They use analog circuitry (op amps and junk) to compensate for the resistor drop, so the path is uninterrupted. I've had systems where the auto-ranging on a bench meter is enough to cause it to reset. I can't find a schematic for the PPKII (haven't looked too hard though) but if it's actually switching the supply, that can cause issues to devices downstream. Especially if that switching causes a voltage drop change.
It switches the detection range, but not the actual power supply. You can ramp from <5 uA up to 500 mA and back all you want. I haven't noticed any glitching on the actual supply.
With the onset of cheap 16-bit, 18-bit or even 24-bit sigma delta ADCs, it isn't a very hard circuit to shove a 1 Ohm sense resistor, 2.048V reference and have sensing down to 31uA (16-bit), 8uA (18-bit) or less for 24-bit ADC.
SigmaDelta gets pricy if you want higher speeds though. But it's possible.
I have the ST one (X-NUCLEO-LPM01A), but its range is actually not enough for something like an ESP32, it goes into "overload" as the max current is 50mA for dynamic (100kHz bandwith) and 200mA for "static" measurements.
I'm working with NRF5 SDK. Most of its source is available (no idea if it's free software or not, but sources are there). The most glaring exception is softdevice - that's BLE implementation, it's huge binary blob, taking control over most CPU.
Their newer SDK based on Zephyr RTOS, I didn't work with it, but I think it's mostly open source as well.
It's all on Github (https://github.com/nordicsemiconductor), but it is not technically open source as it is a modified BSD that does not let you use the SDKs with other chipsets.
The BLE library at least is plain BSD-3-Clause. Most of the other ones are the same, a few don't have licenses applied though. Which repo has the modified BSD license?
This implies everyone gets multiple offers. When I had 2yrs of exp. I had one company that was confident about me, the rest were kind of trying to find reasons not to hire me (except exp)
For the first interview that you get an offer, what exactly do you tell them to keep them from moving on to someone else?
Most don't extend employment offers out for months in my experience, or at least they really try to get you to agree off the bat. I imagine someone job searching is getting an interview once a week or so. Several times, I've had delays of weeks to months after just submitting an application to get the interview. So how do you just have multiple offers to juggle at any one time?
You plan about 4-6 weeks and communicate early on that you are talking to several companies, and that you plan on evaluating offers on X date. Companies will shuffle things around to meet your date if you give them time. If they aren't flex you don't want to work for them anyway.
Great. Hire them, I will go work for someone who gives the same respect that they expect.
People like you are the ones who grumble that it's hard to find good employees, or have to deal with "bad hires". I've built up and staffed teams for a long time and I understand that the best employees sometimes need flexibility. Because the good ones are all going and working for people who want to treat them like adults and understand that the person doing the hiring is just as disposable as the people attempting to be hired.
If timelines don't line up, you just say they don't line up and go your separate ways. No harm no foul.
You are hiring a cog to fit in the machine then, nothing more.
And that's fine for some people who are just "passing through" with no concept of ownership of anything. A lot of people probably.
But you're also going to miss out on people that take extreme ownership of success and failure that have really dedicated themselves to various crafts over their life and career.
You will never, ever, ever get the performance and gains by hiring a cog compared to hiring a craftsman.
This isn't necessarily true. You can hand craft a highly independent and empowered team at a large company (pets not cattle), and still have hundreds of candidates to sift through. At JPL, we did this. We were very careful about hiring, but did have many, many qualified candidates to choose from.
But I will say, we were also careful to accommodate candidate schedules as much as possible, but yes, we did pass on folks who were asking for significantly more than others. It's a balancing game.
It's kind of like how when selling a house your optimal strategy is rarely to try to appeal to the most people. Instead, modifications which greatly increase perceived value in a smaller subset (so long as it isn't too small for your personal goals) will alienate most customers but still increase the sale value in the same timespan.
When you're applying for jobs, some companies aren't willing to play that game, and if you're playing it then that's not just fine; it's ideal. You don't waste your time on companies who won't play ball. Enough will that the strategy still works.
In terms of modifying the house it depends on your local market. The general observation is that something making the house "special" tends to drive the price up rather than down. E.g., radiant heating via floor circulation can be seen as risky and novel, but enough people care that it tends to be profitable. Similarly with "risky" amenities like a backyard walking path. The location determines what a normal house is, so specifics vary wildly, but targeting a large enough sub-market is almost always better than "targeting" a wider market.
Yeah honestly unless the developer can demonstrate that they don't allow ads through from who pay them to be allowed, pretty much no adblocker is going to be fully trustworthy. There will always be an incentive, if the adblocker is popular enough, for the dev to take money from an advertiser to bypass the block.
If I did have to trust any adblocker though, it would be gorhill's.
I just tell people to avoid writing loops in Terraform if it could be at all avoided. And if you iterate make sure it’s a keyed dictionary instead of array/list like data structure
It's yet another argument, like many arguments against Kubernetes, that essentially boils down to "Kubernetes is complicated!"
No, deployment of a distributed system itself is complicated, regardless of the platform you deploy it on. Kubernetes is only "complicated" because it can do all of the things you need to do to deploy software, in a standard way. You can simplify by not using Kube, but then you have to hand roll all of the capabilities that Kube just gives you for free. If you don't need a good hunk of those capabilities, you probably don't need Kube.
I think the reason why people (correctly) point out that Kubernetes is complicated is because most people do not need a distributed system. People reach for k8s because it's trendy, but in truth a lot of users would be better off with a VM that gets configured with Chef/etc and just runs your software the old fashioned way.
K8s starts to make sense when you want to provide a common platform for a multitude of application developers to work on. Once you can understand it was born from Google's Borg and what problems they were trying to solve with both, the complexity behind it makes a lot more sense.
Most people actually do need a distributed system.
They want their system to be reliable to hardware failures. So when the server inevitably goes down some day, they want their website to continue to work. Very few people wants their website to go down.
They want their system to scale. So when the sudden rise of popularity hits the load balancer, they want their website to continue to work.
In the past, the price to run a distributed system was too high, so most people accepted the downsides of running a simple system.
Nowadays the price to run a distributed system is so low, that it makes little sense to avoid it anymore, for almost any website, if you can afford more than $50/month.
Very well put. I add to that: with an E2E solution, you need to learn things before you deploy your system (still not that you do everything properly), but without that, it's possible to deploy the system, then learn things can go wrong when they actually happen. Now if you ask someone who has a half baked distributed system, they still don't know all the failure modes of their system. I've seen this in mission-critical systems.
But in a company that had properly reliable infrastructure, any system that moved to the new infra based on K8s needed much less maintenance, had much more standardized DevOps (which allowed people from other teams to chime in when needed), and had much fewer mistakes. There was no disagreement that K8s stramlined everything.
I really want NixOS to succeed in becoming easy to configure, operate and onboard. I would like to avoid any other configuration management tool in my life again. In this way, you can have simple vm's and k8s for distributed use cases. Both that can be declared in code.
Exactly, there are a lot of comparisons that aren't apples to apples. If you're comparing kubernetes to a fixed size pool of resources running a fixed set of applications each with their own fixed resources, who cares? That's not how most deployments today.
One could make the argument that deployments today that necessitate K8s are too complex, I think there's a more convincing argument there, but my previous company was extremely risk averse in architecture (no resumé driven development) and eventually moved on to K8s, and systems at my current company often end up being way simpler than anyone would expect, but at scale, the coordination without a K8s equivalent would be too much work.
When choosing distributed systems platforms to work with, k8s vs. rolling your own orchestration isn’t the decision anyone is making. It’s k8s vs cloud vendors that want your money in exchange for the headaches.
Honestly running your own control plane is not that much harder than using something like EKS or GKE. The real complexity that the grandparent was talking about is all the tweaking and configuration you have to do outside of the control plane. Eg the infrastructure and deployments you’re building on top of Kubernetes and all of the associated configuration around that. In other words, whether you use EKS or hand roll your own kube you still have to solve node auto scaling. Load balancing. Metrics/observability. DNS and networking. Ingress. Etc etc etc.
reply