Ruby Video – On a mission to index all Ruby conferences
rubyvideo.dev
rubyvideo.dev
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 google long to message me and tell me i had to take it down because its actually forbidden to host an alternative search index if you are using the youtube API. You are not allowed to store the results of youtube API (longer than 24hours if i remember) and as stated before not allowed to offer an alternate search.
While you might argue: why didn't you just state that you don't use the api to grab the data and shutoff the token usage : well because google is not really known to be friendly and i expected them to just close down my whole developer account if i don't follow.
So - in case not all the videos are hand inserted (and even then they might come at you) google definatly will reach out to you and try to force you down. Back when it happend to me i didn't have the time and patience to fight them back so defcon.video was shutdown.
Best of luck tho
and if their algorithm is in a bad mood that day, they'll shut down your personal account(s) as well, and possibly adjacent accounts. Hope you don't rely on personal email or Google Photos or Android if that happens.
This nuke-somebodys-life-from-orbit capability of such a gigantic company is IMHO one of the best arguments for regulatory limits on company size/scope. That's obviously easier said than done and comes with a whole column of cons, but the power imbalance is so unbelievably great and the reach so deep that in some cases I'd rather be on the wrong side of the state than on the wrong side of Google.
I always wondered why people would just give all their personal information to google in terms of mail and files (convenience i know but still..).
But than you see the posts of "google just shutdown my account without any reasoning and i lost everything help!!" here on hackernews and you know exactly why you don't use google for anything but their services.
At this point I assume the only way Google will ever fix their ridiculous ban process is if someone passes a law that forces them to separate these comingled services from losing you access to your email, and essentially in some cases your personal business.
We are just embedding the video using vlite.js and the YouTube Video ID (which is just embedding an official iframe in the end). So there isn't really an account to "shut down", unless I'm missing something.
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.
The biggest pain point was the lack of Grade A documentation for the best way to use ActionCable and Turbo – information is spread out between Rails Guides, API docs, and then the Turbo / Stimulus documentation. The actual API docs do a poor job of explaining basic concepts like "streamables", and I kept wondering if I was doing things the "right"/idiomatic way.
Still, as always, ActiveRecord is my biggest draw for Rails, and the new first-class Sqlite integrations are a huge draw for me. I've yet to find an ORM that allows me to be anywhere near as productive.
The nice thing about first-class production sqlite support is that even if you do end up with n+1 queries, it's not as big a deal: https://www.sqlite.org/np1queryprob.html
Certainly I wouldn't care about it while prototyping. I can always go back and optimize queries with judicious `.joins()` or `.includes()` if it becomes a bottleneck.
But these sporadic elevated response times kept showing up on endpoints, where they’d be hundreds of milliseconds slower than normal, but by some extension of 100ms. Say, normally 5ms, now taking 105ms, or 505ms, or more.
Then I learned about ruby’s non parallel but concurrent model, where within a process only one thread can execute at a time. In most workloads you’ll hit IO quickly, and the threads will play nicely. But if you have a CPU crunching exercise, it’ll delay every other thread waiting to execute by 100ms before it preempts. Now consider you’re doing 10 1ms queries inter process with a greedy thread, and you’re waiting at minimum 1010ms.
Still love Ruby but the process model gave me a reason to hate N+1s.
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
Hopefully as Ractors mature that problem will be solved for MRI too.
Anyone can achieve n+1 issue with whatever tool they use, it's not ActiveRecord specific.
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.
Hosting is in Europe on Hetzner maybe it explains your response time. Where are you located?
what are the response time you are getting ?
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.
I will check if we can prevent this default effect and only use page transition when needed
Thank you so much to everyone in the Ruby community. I spoke at conferences around the world for 13 years, made a ton of friends, and officially retired from speaking at Rails World in Toronto back in September. Some of the best people I've ever met, and the community transformed my life and career.
https://testdouble.com/insights/the-selfish-programmer
Was lucky to be at the conference when you gave it and it's stuck in my head since. When I'm struggling for motivation or my side projects seem to be just too big I give it another watch.
That is sad to hear. Any reason why ?
To anyone who enjoys contorting the language to make it do weird things for fun, quines, and those sort of things, I really recommend Tomoya Ishida's talk at RubyKaigi 2024. It's in Japanese, but there are subtitles, and the slides speak for themselves. Some of the more whimsical uses of Ruby I've seen in a while. Keyword to peak your interest: animated quines.
1: notwithstanding storage degradation, but I trust myself more than this platform
But hey, maybe you get to speak at another Ruby conference in 2025!
I wish there were more sites like this, devoted to particular topics that proved to be valuable enough to be presented in a public talk. I currently use YouTube for this a lot (like most people, I guess). But sadly, count(views) is not always correlated to quality.
And on top of that Ruby itself has seen improvements from concurrency and parallelism to straight up speed gains, JITs, etc...
With Rails 8 they really knocked it out of the park. Now there are real compelling reasons to use Rails 8. The job system, the auth generator, the rich text inputs, the file uploads, shit -- they have so much just baked in and omakase'd to death. It's quite an achievement. And it's beautiful to use. You get a phoenix liveview "feel" without breaking out of Rails vibes. If that makes sense.
I'm using it for a pet project of mine and have a really smooth experience leaving Elixir dayjob and jumping into Rails.
Can I invite you to browse the repositories here https://github.com/ankane?tab=repositories ?
2024 is the year with the most Ruby talks in a single year, ever! This is the first time we beat the previous all-time record from 2015! Ruby is so back!
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 Rails.
Whatever performance issues there used to be? We will have 256 Core Server in next 12 months, or 512 CPU Core in Dual Socket Setup. CPU Core is getting cheaper and faster.
I always like to say Ruby is the only Top programming language that doesn't have a big tech backer behind it. And it only recently found one. Shopify could now single handedly sustain the whole Ruby Rails ecosystem. It also means the whole ecosystem gets a lot more resources than it used to. ( YJIT is from Shopify )
it’s a shame that github, gitlab, airbnb et al aren’t doing more for the ruby ecosystem that they have benefitted from.
* Open https://pyvideo.org/speakers.html and scroll down to the bottom.
* Open https://www.rubyvideo.dev/speakers and do the same thing.
The Python page loads instantly, while the Ruby page makes several requests before fully loading. Ironically, it seems to be utilizing a rails feature called "turbo streams".