chris12321
Americans often seem to have the view that lawmakers are bumbling buffoons who just make up laws on the spot with no thought given to loop holes or consequences. That might be how they do it over there, but it's not really how it works here.
The downsides are that I need to be connected to the VPN at home to use the domain and I currently don't have SSL set up on the domains, so browsers complain when I connect to them. The second problem I could fix, but I'm not sure if there's a solution for the first.
Sorry I meant to say "I've been thinking about building a Once style project" I've just got a couple of not very well fleshed out ideas at the moment.
In terms of licencing it's interesting, I suppose you could have the app phone home periodically, but since it's source available, someone could just remove that call. I guess the main idea is just that it's software for businesses and legitimate businesses generally aren't going to break licence agreements.
Customer.limit(1000).to_a
completes in about 10ms, whereas:
Customer.last(1000).pluck(:id, :name, :tenant_id, :owner_id, :created_at, :updated_at)
runs in around 7ms.
Active Record methods are defined at application boot time as part of the class, they're not rebuilt each time an instance is created. So in a typical web app, there's virtually no performance penalty for working with Active Record objects.
And when you do need raw data without object overhead, .pluck and similar methods are available. It’s just a matter of understanding your use case and choosing the right tool for the job.
Dynamically generated methods can provide amazing DX when used appropriately. A classic example from Rails is belongs_to, which dynamically defines methods based on the arguments provided:
class Post < ApplicationRecord belongs_to :user end
This generates methods like:
post.user - retrieves the associated user
post.user=(user) - sets the associated user
post.user_changed? - returns true if the user foreign key has changed.
I've been about building a Once-style project myself, how do you deal with tracking the licences, do you have the ability to revoke them if someone breaks the licence?
I know there are probably huge engineering problems preventing this from happening, so feel free to tell me why it's impossible.
1. Ruby 3.0 and YJIT have provided huge performance gains for the language with further improvements still left to be implemented.
2. Ruby releases new versions every year on Christmas day, so you're more likely to get new content around this time of year.
2. Large Rails shops like Github and Shopify have redoubled their commitment to Ruby/Rails and invested a lot of resources into improving the developer experience with ruby-lsp.
3. Prism, the new Ruby parser has been developed and merged into Ruby, from my understanding, it's a lot more user-friendly and fault-tolerant, allowing for the creation of more/better development tools.
4. Rails 7/8 released a ton of exciting new features such as Hotwire, Solid suite, auth generation and others. Promising a simpler way to make high-fidelity applications.
5. The Rails Foundation was created and has focused on improving documentation, organising Rails World and pushing the message of Rails being 'a one person framework' that can get you 'from hello world to IPO'.
6. A growing dissatisfaction with the needless complexity of the Javascript ecosystem and cloud providers, pushing people towards the simple but powerful solutions Rails provides.
All these individual contributions seem to have produced a snowball effect. As a long-time Rails developer, seeing there be a new Ruby and/or Rails post on the front page of HN nearly every day recently has been really exciting.
irb(main):001* class Array
irb(main):002* def hello
irb(main):003* puts "hello"
irb(main):004* end
irb(main):005> end
=> :hello
irb(main):006> [].hello
hello
This sort of monkey patching is used a lot in the ActiveSupport gem to give convenient methods such as: irb(main):001:0> 3.days.ago
=> Sat, 28 Dec 2024 13:10:24.562785251 GMT +00:00
Integer is extented with the `days` method making date maths very intuative.This gem freezes the core classes, essentially closing them, so doing the above raises an error:
irb(main):007> require 'refrigerator'
=> true
irb(main):008> Refrigerator.freeze_core
=> nil
irb(main):009* class Array
irb(main):010* def hello
irb(main):011* puts "hello"
irb(main):012* end
irb(main):013> end
(irb):10:in `<class:Array>': can't modify frozen class: Array (FrozenError)
Looking at the code in the gem, all it's doing is calling https://apidock.com/ruby/Object/freeze on all call modules. The frozen flag is an inbuilt part of the language and as far as I'm aware has a performance benefit. In fact the major verison of Ruby will have all string instances frozen by default.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
>>> x = "hello"
>>> def test():
... print(x)
...
>>> test()
hello
which seems very odd to me. In Ruby you get: irb(main):001> x = "hello"
=> "hello"
irb(main):002\* def test
irb(main):003\* puts x
irb(main):004> end
=> :test
irb(main):005> test
(irb):3:in `test': undefined local variable or method `x' for main:Object (NameError)
This makes much more sense to me, since x is defined outside of the scope of test, so why should test have access to it? If you're starting a new Rails app and live in the EU, the optimal strategy is pretty clear:
Get a 64-thread box on Hetzner for 250 euro a month, allocate 20% of it to the DB, 40% to web, 40% to bg, then just forget about scaling until you're making money hand over fist.
At a certain point, self-hosting is so much cheaper than PaaS that you can way overprovision your server and not worry about it until you're making serious money.