I got rid of my Alexa devices after they would not shut up. "Alexa what is the weather for today?" "The weather for today will be ... By the way, did you know that you can set alarms? Just say ..."
I do not care about whatever stupid feature you want to build engagement around. Do what I asked you to do and then shut up.
And don't get me started on the Alexa Show that had the audacity to display ads.
I wrote a library[0] to let you concurrently update a sqlite db in s3 safely. It uses the little known sqlite sessions extension plus s3 compare-and-swap on a small metadata file to make this work reasonably efficiently and safely. I have been enjoying it for a bunch of small projects where I want a lambda function to have a db for state but I don't want to pay for a full database instance.
I have also used lambda at scale in professional environments. I would not use a lambda for a webserver at scale, but having an s3 object trigger processing via a lambda function is a really nice flow.
> If you're using AWS Lambda then you have to work to keep convincing yourself this is better than your own web servers. Keep convincing yourself that using AWS Lambda is not a horrible mistake.
lol ok. I have ~50 lambdas running in my personal aws account. Some of them are webservers running behind an api gateway or using a lambda function url to expose them to the internet. Some are running on a schedule, some are triggered from s3 events. The cost to run these for me is less than the cost of the cheapest vps (my total requests per month stay under the free tier limit). There is also zero maintenance I need to do for these functions (ok, this year I did have to find-replace al2 to al.2023 in my terraform config). I don't have to worry about making sure the os is patched for the latest vulnerabilities. And I don't have to worry about the specific hardware my code is running on at any time. Doing maintenance for old projects sucks. It is great to have servers I deployed years ago continue to chug along without me needing to think about it.
Now, all of my lambdas are written in Go and I suspect if I was using one of the manged runtime libraries I would find the language upgrades to be quite annoying. Go also helps quite a lot with cold start times.
Then again maybe I have just drank the koolaid. In my quest to use lambdas for as much as I can as cheaply as I can, I made a library[0] to use sqlite on top of s3 (not just readonly). It uses the sqlite session extension plus s3 compare-and-swap to allow you to write updates safely to s3, even if you have concurrent writers.
Most of what I write in my journal I don't want to need to remember (that is why I am writing it down). I also don't know what will be important or not important later, so I want it all to be searchable.
This "it has to be handwritten" stuff is nonsense. Do that if you enjoy it, but also you should acknowledge the downsides to it.
I started keeping a work journal a few years ago and it has changed how I work for the better. It is just a text file.
The main value of it is that I can search it! When I'm figuring something out for the first time, and I have a lot of trail and error, I write down what I did. And then I might not touch that thing again for 6 months. When I come back to it, it is unlikely that I will remember what I did exactly but because it is written down and searchable I can quickly recover my old state.
I like this so much I also started a personal work journal for my home lab. It really is useful for me. But its primary value is that I can search it.
To follow up on this a bit, something that I really want is a way to build and launch apps from an llm really easily. I am imagining and environment with a database, object storage, and a publicly reachable webserver. I think this could be that with OIDC auth to an s3 bucket and litestream.
I was previously thinking about doing the same thing on my homeserver with tailscale to expose the web interface publicly and tailscale oidc auth to an s3 bucket for object storage.
Playing around with this for a small amount of time, it is very neat but also there are a bunch of things that are unclear / undocumented (I assume the documentation is coming so I'm not faulting them for it not being there yet).
Some things that are unclear:
- How should I auth to github? sprite console doesn't use ssh (afaik) so I guess not agent forwarding?
- What on machine api's are available? Can I use the fly oidc provider[1]? There's a /.sprite/api.sock but curl'ing /v1/tokens/oidc gets a 404.
- How much is it going to cost me? I know there is pricing but its hard to figure out what actual usage would be like. Also I don't see any usage info in the webui right now.
I had an M2 air running asahi that I loved and had similar worries. I ended up buying a maxed out refurbished M2 which I expect will last me a few more years.