Heh, I just wrote something very similar - bash, curl, and jq scripts that wrap local Ollama calls to produce a REPL/agent: https://github.com/cloudkj/llayer
Seems like the core idea is the same, but I took it farther down the Unix philosophy line of thinking and tried to make the individual components small and composable.
PG&E "Share My Data" self-access library (https://github.com/cloudkj/pgesmd_self_access) - been tinkering with various home automation and monitoring ideas, and was able to get an end-to-end prototype for ingesting and visualizing PG&E meter data using a combination of the (forked) aforementioned library, an old circa 2015 Raspberry Pi, and a handful of dollars spent on AWS services (certificate manager, load balancer) to get the full mTLS PG&E integration working. Probably deserves a blog post to document all the gory details.
Geo data mashups (https://github.com/cloudkj/snowpack) - small frontend utilities to overlay custom data on top of each other; was able to satisfy two recent personal use cases: (1) visualize snow depth across California ski destinations and (2) heat map of national park traffic by entrance. Previously posted at https://news.ycombinator.com/item?id=46649103
REST interface for Gymnasium reinforcement learning (fka OpenAI Gym) (https://github.com/cloudkj/gymnasium-http-api) - simple wrapper around the forked version of OpenAI Gym to allow for language-agnostic development of RL algorithms.
Just curious - how long have you been running the site and how sustainable of a model you feel it is? Sustainable in the sense that the affiliate or ad revenue it brings in is consistent enough to justify continued maintenance, improvement, etc.
I'm also interested in starting up something similar for a particular niche, and would like to hear first hand accounts of the return on investment for aggregators such as these.
I worked on a project with similar motivations; in my case, I had a list of criteria in mind, one of which was the number of syllables in a name. I couldn't find a good source for name syllabification, so built an n-gram language model trained on the CMUdict corpus.
Just saw some of the references to RTL-SDR in the thread comments and started down the rabbit hole, and it looks like a fascinating area for hobbyists.
Can you provide some links to temperature sensors you've tried that work well with an RTL-SDR receiver? I'm also interested in setting something up with a Raspberry Pi.
Side note: not sure if it's just a funny coincidence, but it seems like a good number of folks here have been running their sites for around fifteen years. Perhaps the timing just happens to match the typical career arc of software professionals, or maybe it was due to the popularity of blogging fifteen years ago.
Indeed. Fishing knot strength is always a hot topic of debate, particularly during the slower, off-season winter months when everyone's hunkering down and doing tackle maintenance. Here's a pretty good breakdown of the line breaking strength of various fishing knots across monofilament, fluorocarbon, and braided line: https://www.knotsforfishing.com/knot-strength-chart/
I personally prefer the Palomar Knot as it is probably the strongest knot that is also easy to tie. The Improved Clinch Knot and its brethren are also handy to know since there are so many variants that have high breaking strength; I typically teach the Improved Clinch Knot to folks new to fishing.
Coincidentally, I just wrote a simple JSON parser the other day as a toy exercise. A simplified snippet of parsing code (handling only arrays) relevant to the discussion here would be something like:
def parse(text):
stack = []
index = 0
result = None
while index < len(text):
char = text[index]
val = None
if char == '[':
stack.append([])
elif char == ']':
val = stack.pop()
index += 1
if val is not None:
if stack:
stack[-1].append(val)
else:
result = val
return result
Using the test utilities in the repo indicate that the parsing logic can handle arbitrarily nested arrays (e.g. up to the 5,000,000 max in the test script), bound by the limits of the heap.
It seems like the main criticism here is against recursive implementations. Or am I missing something?
Wow, that is a fun coincidence! Indeed, I was going for a catchy four-letter acronym in the same vein as popular stacks like LAMP or MEAN. Perhaps the fact that we both landed on the same components and permutation of components means that there's something there :)
I also started off in the same manner of implementation - bash scripts wrapping AWS CLI calls - then stumbled upon the more straightforward, template based approach.
I was actually wondering that myself: Is there interest in a hosted service? It'd be quite similar to (as many comments have suggested) Netlify and the one you linked to.
I was mostly going for a DIY solution since I wanted to "own" the bits being deployed while remaining as close to the infrastructure as possible. Providing a hosted service somewhat moves away from the DIY spirit; I suppose additional tools/UIs could be offered to simplify setup and deployment and still run everything directly on AWS, but at that point one might be inclined to just move to one of the other hosted solutions for the simplicity.
The AWS CloudFormation console has a "Designer" tool that allows drag-and-drop creation of template files, and also visualizes existing JSON or YAML template files with these diagrams.
That should indeed be the default behavior out of the box with the way the S3 buckets are configured. I have a couple Jekyll sites deployed this way, and a request to the parent directory does get served by the contents in `index.html`. Are you not seeing that behavior?
I'd definitely like to add more variants of the default stack. At the minimum, I'm sure there are folks that prefer `www` redirects to the apex domain, or removing the `www` subdomain altogether.
I think the complexity for this setup is about the same. Once the different AWS services are provisioned during the initial setup, subsequent deploys are quite straightforward. For example, I have a three-line Makefile target for Jekyll sites that looks something like this (using Docker with a local `aws-cli` image wrapping the CLI):
It costs at least $0.50/month but probably not much more than that for most small to medium sites.
The $0.50 is the monthly cost of the Route 53 hosted zone; the CloudFront and S3 costs typically amount to pennies, but of course it depends on traffic.
Author here; thanks for the feedback. The path to Scheme was a bit haphazard - I got into Clojure a few years ago after exposure to some nice Clojure-based tools at work, and then worked on implementing several classical machine learning techniques in Clojure for fun.
When I came up with the idea of chaining and piping neural network layers on the command line, I also came across CHICKEN Scheme which promised to be portable and well-suited for translating the Clojure-based implementation I had previously done. As you can probably imagine, the porting process was a lot more involved than I expected, but nevertheless I had a BLASt (pun intended) hacking on it.
That sounds like a fun and useful follow up. My initial thoughts would be to do some unsupervised topic modeling with LDA. Happy to consider other suggestions.
Thanks for the suggestion. I added a link for 2019, and the style for the active year is now bolded. I didn't want to deviate too much from the default color scheme of the theme I'm using, but that may change in the future.
Thanks for the suggestion. I went ahead and made the change to link the score to the original discussion. It will take a few moments for the CDNs to propagate the changes.
One caveat is that some stories have multiple submissions; I just linked to the one with the highest score for now, but will need to iterate a bit to better handle multiple submissions.
Seems like the core idea is the same, but I took it farther down the Unix philosophy line of thinking and tried to make the individual components small and composable.
Feel free to check it out and compare!