Holm :ruby: boosted

:ruby: thought for today:

Form field validation is very different to error cases in business logic.

validates :password, length: { minimum: 8 }
validates :email, uniqueness: true

These two validations appear to be the same kind of thing, but are actually very different in terms of performance, correctness (race conditions), dependencies, etc.

Rails does not differentiate, so we slap messages on `x.errors[:base]` as a bandaid solution, because there is no proper place to put them.

Holm :ruby: boosted

πŸ” Different people read code differently. Some people prefer a top-down approach, while others prefer a bottom-up approach.

Top-down readers prefer understanding the broader picture before diving into the details of what’s happening.

Bottom-up readers don’t really care about the big picture at first - they prefer reading all the details up front. They construct their mental model as they go through them.

Which type of code reader are you?

Holm :ruby: boosted

Turn children into orphans:


# => "πŸ‘§β€πŸ‘¦"

Holm :ruby: boosted
Holm :ruby: boosted

πŸ’¬ Try to avoid comments describing _what_ the code is doing. Instead, spend some time improving code readability by improving your variable and method names and by extracting complex expressions into clearly named methods. Try making your top-level code as easy to read as plain english.

This way you avoid having outdated comments in your code base, while keeping the code easy to understand.

Holm :ruby: boosted

Anyone got a good tutorial on using elm to front end a rails app? I'm bored and need something to tinker on.

Holm :ruby: boosted
Holm :ruby: boosted

@judofyr yeah, I'm in the process of converting all of our REST api to GraphQL

I love the flexibility and simplicity it is giving on the front-end. There are a bunch of things we had to figure out on the back-end (e.g. we dynamically generate the API from our models, we have rate limiting and concurrency limiting using redis, we integrated it with our permissions system, etc.)

Holm :ruby: boosted

has anyone used GraphQL with a Ruby backend? how was the experience?

see, this is how I assemble unfinished side projects

just stumbled upon an edge case in Apollo/GraphQL where the cache interacted in an unsuspecting/my-app-crashes-now way, and all I can think about it is how to design a GraphQL variant where this isn't a problem

here's the beginning of composable validations: github.com/judofyr/ippon/pull/. very rough code, but the tests should help understanding what's going on.

/cc @jgaskins @solnic @timriley @tom_dalling @james

and come on Stripe, please release your type checker! I'm very much looking forward to playing with it (:



this code leaves me with so many questions

we've (rightfully) realized that classes that inherit from complicated structures (like ActiveRecord::Base) creates highly coupled code.

however, moving them into modules and implementing the same complexities with Module#included doesn't really solve the problem.

the problem isn't "include Foo" vs "< Foo". the problem is polluting the class with methods that has all kind of internal data/functionalities.

I do think that dry-rb is doing many things right, but some of the parts seems a bit too DSL for my.

how is this "simply"? what's the difference between inside and outside `configure`? why do I need a completely different syntax when I want to share predicates?


and nothing is form specific either. you can validate a single string if you want:

(trim | required | integer).validate(" 123 ").value # => 123

and maybe you have multiple forms on one page? well, it trivially supports both nested:

form(user_info: form(…), account_info: form(…))

and merged:

form(…) & form(…)

Show more

A Mastodon instance for Rubyists & friends