1,374 karma · joined April 12, 2017
Working at https://tyba.ai
Building https://yakread.com and https://biffweb.com
email: hello@obryant.dev
I too ran into the lack-of-a-web-framework problem, so I ended up building one[1]. When I started, I also thought there would be idealogical opposition and I'd have to convince people that frameworks can be good. But in fact there have been a lot of positive reactions (including funding!), and I honestly can't think of a single time when someone said something to the effect of "but frameworks are bad!" (maybe if you searched r/clojure you could find something).
Based on that, I think the reason there isn't a widely used Ruby-on-Rails equivalent is simply because no one's put in the work yet to make it happen (though I am trying to!). I think it's likely that a lot of the people in the Clojure community historically just haven't needed a Rails-like framework, either because they prefer piecing it together themselves or because they've been working in domains that don't involve spinning up new web apps very often.
I have no idea, it's an extremely complicated problem, especially considering trade-offs between privacy and competition.
> No advertising of certain controversial things (alcohol, tabacco,... I don't know who'd define what's ok)
That last bit is the kicker ;).
This belief is actually compatible with my argument, thanks to the "on average" qualifier! I've never said that "most advertising as it exists today is good," rather my point is "advertising in a fundamental sense doesn't have to be bad." I think there is a real need that can be served by advertising, and thus we should find good ways of serving that need which don't involve "manipulation, brainwashing and commodification of well told lies."
I responded to this sentiment in another comment, but I'll just quote from the HN guidelines here: "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."[1]
> How do I know which emails I can trust as having useful unbiased information (i.e. satisfying my needs), and which are potentially misleading junk adverts (i.e. satisfying the site operator's desire for profit)?
Because ads are clearly marked with a "sponsored" label.
> And what is to stop the signal to noise ratio becoming completely untenable over time in the desire to maximise profit?
Because if we send people newsletters they don't like, they'll be more likely to stop using the service.
> the conflict of interest between user needs and site operator's profit.
Interesting anecdote: I haven't measured this in a while, but at least when we first introduced ads, the sponsored newsletters tended to be rated more highly than the "organic" newsletters.
Sure, that could be influencing my reasoning, but it goes the other way too. It's easy to criticize ads as a business model when you don't have skin in the game (ducks). That's why I decided not to bring up either of those points: I'd rather write for people who are willing to focus on the argument instead of assuming bad faith.
As your edit admits, this is not at all what I said. To expand a bit--I think there's a big distinction between advertisement in a fundamental sense and how advertisement often is implemented today. I think that advertising can be done in a good way, and I'm concerned that too many people dismiss advertising altogether because of things like real-time bidding.
I don't know if this model would ever become more popular than FB/Twitter/etc, but I think it could become popular enough that anyone who wants to ditch social media can do so without feeling like they're missing out on something.
If you have data/industry experience in support of this, I am genuinely interested to hear about it, otherwise it seems like a case of my anecdote against your anecdote. It is not clear to me as a layperson that spam misclassification is indeed that big of a problem.
Maybe for you, but not for me.
Next up, we're going to dig into our retention data and try to figure out if it's 'good enough'/what to do about it if not etc. I'm a little concerned about this since our monthly churn is 8% which feels pretty high, though I haven't compared it to benchmarks for other newsletters yet.
- Music (defunct): https://news.ycombinator.com/item?id=20584508
- Cross-domain (defunct): https://news.ycombinator.com/item?id=23541840
- Essays (still running with ~100 DAU but not actively developed): https://news.ycombinator.com/item?id=24921127
- Newsletters: https://news.ycombinator.com/item?id=27664020
(But first some background: The way I saw it, you can split music recommendation into two tasks: (1) picking a song you already know that should be played right now, and (2) picking a new song you've never heard of before. (Music recommendation is unique in this way since in most other domains there isn't much value in re-recommending items). I think #1 is more important, and if you nail that, you can do a so-so job of #2 and still have a good system.)
Make a website that imports your Last.fm history. Organize the history into sessions (say, groups of listen events with a >= 30 minute gap in between). Feed those sessions into a collaborative filtering library like Surprise[1], as a CSV of `<session ID>, <song ID>, 1` (1 being a rating--in this case we only have positive ratings). Then make some UI that lets people create and export playlists. e.g. I pick a couple seed songs from my listening history, then the app uses Surprise to suggest more songs. Present a list of 10 songs at a time. Click a song to add it, and have a "skip all" button that gets a new list of songs. Save these interactions as ratings--e.g. if I skip a song, that's a -1 rating for this playlist. For some percentage of the suggestions (20% by default? Make it configurable), use Last.fm's or Spotify's API to pick a new song not in your history, based on the songs in the current playlist. Also sometimes include songs that were added to the playlist previously--if you skip them, they get removed from the playlist. Then you can spend a couple minutes every week refreshing your playlists. Export the playlists to Spotify/Apple Music/whatever.
As you get more users, you can do "regular" collaborative filtering (i.e. with different users) to recommend new songs instead of relying on external APIs. There are probably lots of other things you could do too--e.g. scrape wikipedia to figure out what artists have done collaborations or something. In general I think the right approach is to build a model for artist similarity rather than individual song similarity. At recommendation time, you pick an artist and then suggest their top songs (and sometimes pick an artist already in the user's history, and suggest songs they haven't heard yet--that's even easier).
This is the simplest thing I can think of that would solve my "I love music but I listen to the same old songs everyday because I'm busy and don't want to futz around with curating my music library" problem. You wouldn't have to waste time building a crappy custom music app, and users won't have to use said crappy custom music app (speaking from personal experience...). You wouldn't have to deal with music rights or integrating with Spotify/Apple Music since you're not actually playing any music.
If you want to go further with it, you could get traction first and then launch your own streaming service or something. (Reminds me a bit of Readwise starting with just highlights and then launching their own reader recently). I think it'd be neat to make an indie streaming service--kind of like Bandcamp but with an algorithm to help you find the good stuff. Let users upload and listen to their own MP3s so it can still work with popular music. Of course it'd be nicer for users in the short term if you just made deals with the big record labels, however this would help you not end up in Spotify's position of pivoting to podcasts so you can get out of paying record labels. And then maybe in a few decades all the good music won't be on the big labels anyway :).
Anyway if anyone is remotely interested in building something like this, I'll be your first user. I really need it. Otherwise I'll probably build it myself at some point in the next year or two as a side project.
I'm sort of surprised I haven't noticed this before when researching email providers.