81–88 of 88 posts
I loved David's book Sustainable Rails[1], it's one of the books on Rails I always recommend. This is a really interesting take. I'd love see one of these small alternative frameworks full embrace Sorbet and use it for things like form validation. I guess that might defeat the gradual typing approach but it would definitely be interesting. 1. https://sustainable-rails.com/
I see it is currently based on Sinatra. Just wondering if you have considered looking into Roda?
(author here) It only uses Sinatra because I happened to know it and needed to bootstrap the low-level stuff. I don't know if it needs to be based on Sinatra in the long term - it should probably just use Rack.
Not sure you have come across https://github.com/Ramaze/innate (I am showing my age now :) . It is the core of the Ramaze framework. I really liked the philosophy of that project. Its a shame it never caught on though.
I loved David's book Sustainable Rails[1], it's one of the books on Rails I always recommend. This is a really interesting take. I'd love see one of these small alternative frameworks full embrace Sorbet and use it for things like form validation. I guess that might defeat the gradual typing approach but it would definitely be interesting. 1. https://sustainable-rails.com/
Sorbet is nice, but for data structure enforcement and data validation, I much prefer the dry-rb ecosystem.
I love some of the ideas but they seem a bit too heavy for my taste.
e.g. I think (project) standardised results are a fantastic idea but I don't need the weight of Dry::Monad for that.
I think I can get enough benefit from built in features like .then and throw..catch with tags for signaling without an extra dependency and the risk of the API breaking on upgrade.
Earlier quoted context omitted.
Well, yeah, then what's the point?
You can use a static analysis tool to check Ruby types ahead of time (still not a compiler) or provide information for tooling. Alternatively you use them at runtime to check the correctness of data, which I don't think you can usually do with say Typescript where the typing information is for the most part compiled away[1]. 1. I may be out of date on this but when I last looked at runtimes that could take Typescript…
I'll have to check out typeprof and sorbet.
Earlier quoted context omitted.
You seem confused about what he was saying. I’m sure you are familiar with unit testing philosophy with your experience. Calling a function and expecting a response does test the behavior of the application, just at a lower level than a request- or multi-request level spec. When he says rewriting a method he is referring to changing the logic of it; a refactor leaves the tests unchanged. That shouldn’t have needed to…
Tests should not generally need to be rewritten unless you’re changing the externally-visible behavior API of a function or library (either the literal API, its effects, or its semantics). If you’re changing the tests because you’ve changed the internal, non-externally-visible logic of your code, your tests are almost certainly providing you negative value. Being able to refactor and re-run your existing test suite t…