I'm super grateful to folks for this. It's one of my favorite websites now.
Ruby Video – On a mission to index all Ruby conferences
61–70 of 70 posts
Re: Ruby Video – On a mission to index all Ruby conferences
#62Is it just me, or is Ruby experiencing a renaissance of sorts? There has been a bunch of positive press, and the community seems more active and vibrant than ever?
What people used to like about Rails, those haven't changed and it is also much better than before. ( Would still want more on Auth ) Hotwire, with Turbo. It has been improved and used in production for quite some time. This also got boosted a lot with JS front end fatigue. Performance. Even by default Ruby 3.4 is quite a lot faster than 2.x era. But with YJIT it is in some cases nearly double and ~30-50% faster in R…
they are also spearheading the ruby-lsp and rails-lsp gems and vscode extension which are in heavy development and getting better by the day.
it’s a shame that github, gitlab, airbnb et al aren’t doing more for the ruby ecosystem that they have benefitted from.
Re: Ruby Video – On a mission to index all Ruby conferences
#63So first of all its a very cool project even tho i don't code ruby. But in case the author of the page is in here, please read the following: Some years ago i had a similar idea, just instead of ruby-cons i went for defcon videos. I build a page that indexed all defcon talks and even tried to categorize them in terms of topics and difficulty. Added a nice search, and put it out as "defcon.video". It didn't take googl…
Oh...
I am currently working on building a curated collection of YouTube channels, with custom search index. Thank you for sharing this, I guess I can't continue. It's a shame.
Re: Ruby Video – On a mission to index all Ruby conferences
#64Re: Ruby Video – On a mission to index all Ruby conferences
#65Earlier quoted context omitted.
Yet it took five seconds for the pyvideo list to filter once I clicked a letter “G” while the rubyvideo site was instant.
yes this is exactly the idea all page remains fast even if we need to list 5k speakers on that page
one thing you can do to make the speaker list more performant and seamless is to load the next list of speakers when the scroll gets to some value near the end of the list and also pull a few more speakers in each fetch.
Re: Ruby Video – On a mission to index all Ruby conferences
#66Earlier quoted context omitted.
Anyone know what are they using for Analytics? Edit: Search is nice as well. >>Really nice to see a deployed modern Rails site. Yes. And it is also a showcase what I want for 90-95% of the web. Useful as an example next time we have yet another MPA vs SPA or SSR vs CSR argument. It doesn't need to be a complex SPA. Although I must admit the response time isn't perfect even with Cloudflare.
analytics is built with ahoy https://github.com/ankane/ahoy . the project is open source if you need more details https://github.com/adrienpoly/rubyvideo Hosting is in Europe on Hetzner maybe it explains your response time. Where are you located? what are the response time you are getting ?
Right now in Hong Kong, getting about 240 - 260ms RTT.
It is probably good enough for 95% of people. I am what I call latency sensitive.
But I think the main culprit is surprisingly view transition isn't as good as I thought. Because the slight lag / jank I feel happens on Chrome. While I dont feel this on Firefox or Safari 17.6 which isn't supported yet.
Re: Ruby Video – On a mission to index all Ruby conferences
#67Earlier quoted context omitted.
Use `includes` and it's solved, you make it sound like a huge deeply rooted issue, it's not. Anyone can achieve n+1 issue with whatever tool they use, it's not ActiveRecord specific.
Only with ActiveRecord pattern you need such kind of hacks to prevent, it's why it's flaw.
Hibernate has `JOIN FETCH()`, Django has `select_related()`, Entity has `Include()` and so on ...
Re: Ruby Video – On a mission to index all Ruby conferences
#68Earlier quoted context omitted.
Only with ActiveRecord pattern you need such kind of hacks to prevent, it's why it's flaw.
`includes` is not a hack. Clearly you prefer implicit over explicit when it comes to SQL generation. That's your prerogative, but I strongly disagree. I don't want the ORM trying be clever on me because it is opaque and complex. I want it to use the function arguments to construct a query, and nothing else. Debugging long-running queries is already complex enough without "clever" code trying to abstract it all away f…
No u need includes because when u do a.b.c u forgot to includes. It is the api problem for letting u chaining the related objects without including it.
Re: Ruby Video – On a mission to index all Ruby conferences
#69Earlier quoted context omitted.
analytics is built with ahoy https://github.com/ankane/ahoy . the project is open source if you need more details https://github.com/adrienpoly/rubyvideo Hosting is in Europe on Hetzner maybe it explains your response time. Where are you located? what are the response time you are getting ?
Right now in Hong Kong, getting about 240 - 260ms RTT. It is probably good enough for 95% of people. I am what I call latency sensitive. But I think the main culprit is surprisingly view transition isn't as good as I thought. Because the slight lag / jank I feel happens on Chrome. While I dont feel this on Firefox or Safari 17.6 which isn't supported yet.
yes view transition when enabled are applied to all pages and create a blend effect by default which can maybe give this slowness effet?
I will check if we can prevent this default effect and only use page transition when needed
Re: Ruby Video – On a mission to index all Ruby conferences
#70Earlier quoted context omitted.
Since Rails 7.1 we've had https://www.rubydoc.info/github/rails/rails/ActiveRecord%2FR... which actaully does run queries in parallel. There's also Rails' russian doll caching, which can actaully results in pages with n+1 queries running quicker than ones with preloaded queries. https://rossta.net/blog/n-1-is-a-rails-feature.html
load_async is still concurrency, but not parallelism. The queries themselves can run parallel, but when materializing AR objects e.g., only one thread can run at a time. A greedy thread in process will still subject you to GVL waits
If that’s a problem for you right now I’d suggest giving JRuby a look as it has no GVL and true multithreading.
Hopefully as Ractors mature that problem will be solved for MRI too.