netghost

The silver lining is that no built in support is better than poor builtin support as it opens the doors to interesting add-ons filling that need.

That said, I would love if Firefox had an excellent RSS experience, but frankly it was always a confusing afterthought.

If this tool is useful to you, it's highly recommend reading the author's blog as well. It's a great resource for learning about postgres.

I suspect that a smaller builds could be generated. There's a lot of functionality like reading from a sqlite db or Excel file that you could probably drop to improve the package size depending on use case.

The name is optional, and probably just to help explain the code.

A blend of certain northwest pine needles can make for something that reminds me of white teas (they served it at my son's preschool).

I think this is an interesting idea, but I'm curious on what the score actually reflects. Does it mean your writing will be better, or just more like a given corpus?

There's some more interesting information on his blog around fibers, ruby, and perf as well. Great to see more approaches being tried here.

https://www.codeotaku.com/journal/2018-06/improving-ruby-fib...

So one thing I'm going to be looking into is whether this let's plugins handle / intercept the feed content now instead of Firefox's rather confusing preview.

All in all, I'd say this had just about zero impact on folks who actually use feeds.

It's also just duplicated work for the producer. I'd rather someone just visit my little blog and read my article on the context where I know the syntax highlighted coffee looks good, my dynamic examples render, etc.

There probably are done folks with great intents, but there's legitimate reasons to channel people to your site as well.

Try a browser plugin for reading feeds. The plugin aggregates your new links and you read it like anything else on the internet. It's a great way to play to RSS' strength while avoiding the myriad of ways folks bungle feeds.

I wrote an open source one for Firefox here: http://github.com/adamsanderson/brook

It's certainly not the only option though, so try a few things.

Firefox's native support going away doesn't really make a big difference, as far as I know you couldn't access it from a plugin anyways.

There are many parsers that are adequate, especially if you don't try to get too fancy. If you're curious, the source is available on github. https://github.com/adamsanderson/brook

Yeah that's feasible, I haven't experimented with it yet.

Personally, I find that I read very different things on my laptop than I do on my phone (technical articles vs. news) so I haven't had a huge motivation to investigate it, but it's an interesting avenue. The only possible stumbling block is that the size of sync'd data is relatively constrained, about 200k I think, which is probably enough to hold a user's feed list and track whether they've viewed/ignored various articles, but it would require some planning.

If you want to take it a step further, add some links feed readers that run as browser plugins. Unlike hosted services, they're not as likely to disappear, and they have a low barrier to entry since they don't require any sign up.

I've been working on one that runs in Firefox[1], but there are many others that look promising for Chrome as well.

[1] https://addons.mozilla.org/en-US/firefox/addon/brook-feed-re...

For what it's worth, I just recently released a simple feed reader that sits in Firefox's sidebar. It's meant to blend in as much as possible in the vein of the older Firefox plugin Sage. You can import OPML files from all your favorite sources (probably).

Extension is here: https://addons.mozilla.org/en-US/firefox/addon/brook-feed-re...

The full source is here: https://github.com/adamsanderson/brook

Even if you don't fancy using it, you may find the source handy if you want to build an extension yourself. Also if you're interested, I'd love feedback, suggestions and bug reports.

Oh! You're a software developer at the local zoo too?

Humming birds, I tell ya thank goodness for multiple inheritance! I was able to inherit from both birds and bees. It saved me a ton of work. There was the time I used the flying mixin on sharks though, that was such a mess to cleanup.

ActiveRecord is really good, but Sequel[1] is much more flexible. I think it starts from a better base, where as ActiveRecord wraps and mostly hides arel.

That said, they're both enormously productive.

1: https://github.com/jeremyevans/sequel

What kind of workload are you using it for? What's been your biggest win while using it?

Your best solution would probably be to use a recursive CTE if your DB supported it, but as a sibling post mentioned, it's probably not a good approach.

Sometimes inactive just means complete. I think SCXML was specified a while ago, I can't vouch for any particular library, but it's possible the library does what it set out to do.

A lot of libraries don't just share books. For instance some let you check out laptops, wifi devices, etc. There are also tool libraries, and even seed libraries.

You might be surprised by what's available at your local library these days.

Looks like a neat project. Maybe you could host a demo using github pages? Then folks could see it in action.

https://pages.github.com/

Oh those were pretty venture capital times as well.

If you like tinkering with computers, and happen to be in or visiting Seattle, the Living Computer Museum is really fun. Anyone can pound away on any of the computers they have set up.

Just have to say, this is ridiculously detailed, which is great. I'm not looking to build a text editor in C, but I learned a good amount just skimming the first few chapters.

Great site, great presentation, thanks for digging into it with so much detail.

Do you expose your GraphQL endpoint to customers, or just use it internally?

That's a really neat approach. I like how it allows you to trigger code on missing paths. That seems like a really simple way to model an API.

So relay assumes you have a graphql backend, which is a tall order for a lot of existing applications. If I was building something from scratch, I'd be tempted to try that approach though.

This looks like a really great library for simplifying API interactions.

I'm curious though if there's any way to indicate that a component depends on more than one end point. Would you just wrap it in multiple `connectRequest` wrappers?

There are different ways you can write queries that result in equivalent results. For instance you might try using inner joins, sub selects, lateral joins, etc.

I seem to remember that when it was first implemented there was a fairly small buffer for queued messages. That might have contributed to your problem. The docs say it's 8GB by default now, which is probably sufficient.