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've been running it about 4 years now? It's very low maintenance (run process_new_comments.py every month and re-deploy). It also doesn't bring in much money: it's definitely a hobby rather than a business.
I don't do any marketing, most traffic comes from people mentioning it on reddit or from being included in "cool internet stuff" newsletters. I have some ideas for marketing, but I also hate marketing and do enough of it for my day job SaaS.
So I just run it because I really enjoy it! I used to have a newsletter but stopped that as it was too stressful having a regular deadline and dealing with email spam filters. Everything else about the site I enjoy: writing occasional blog posts, looking at culture through the lens of books, finding new books. I really like books: I used to own and run a bookstore, and a book price comparison website in the past.
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.
I love the palomar too! The only issue with it is that it makes tying pretied leaders tricky since you have to pull the whole terminal end through the loop. Not as versatile as some other knots.
I find it surprising how many people use clinch knots vs the uni in real life. It's certainly easier to tie clinch knots but I've never found the ease worth it, since the uni is so much stronger and can be used for more things. Once I got fast at uni the clinch knots went out the window.
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?
A better question to ask is: Is it a success of CS education since developers know when to make tradeoffs in software engineering and go for the most easily understandable code (recursive implementation used in most pseudo code) since deeply recursive cases are rare, or is it a failure that software engineers cannot figure out how to convert a recursive algorithm into an iterative implementation for greater memory efficiency?
It doesn't necessarily mean anything that deeply nested cases are rare. If you're making a general library, someone is going to throw user input at it, and some users will try to break your system. If it can avoid a crash in that case, it usually should.
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.
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.