@Ryanbigg

re:
> How developers sound to non-developers when you talk shop

Ohh yeah! the Rockwell retro encaburator, I featured that in my 2022⁺ #RubyConf talk while talking about #Monads in #ruby

Never again without a contract: dry-validation

https://www.rubyevents.org/talks/never-again-without-a-contract-dry-validation

where I also featured your work, Ryan :)

⁺ wow almost 3 year ago to the date.
#dryrb

Hanami 2.3 beta1 is out! This is the one that includes Rack 3 support 🚀

https://hanamirb.org/blog/2025/10/03/announcing-hanami-230beta1/

If you have any questions, join the #Hanami Discord server:  https://discord.gg/KFCxDmk3JQ

#Hanami #Dryrb

Hey, Dry::Struct users... is this "Hash to attributes" thing considered a feature? I find it messy...

I can see the advantages, but I can clearly also see the cons, especially in terms of predictability and debugging...

Took me literally hours to chase a missing object return before I got the hang of this. #ruby #dryrb

Read about ProtoInteractor, a simple business object I created to use with Hanami. It combines:

* The parameter parsing functionality of Hanami Actions.
* Do notation from Dry-Monads.
* Result objects, also from Dry-Monads.

Feedback and corrections (especially) are welcome! Please let me know what you think!

https://rossney.net/articles/protointeractor-a-simple-business-object-for-hanami/

#ruby #hanami #dry_rb #dryrb

I got the idea for command_kit-completion after seeing that dry-cli now has it's own completion generation code that used the 'completely' gem. So if you're a dry-cli user, go use that library for shell completions.
https://github.com/rngtng/dry-cli-completion#readme
#dryrb

It's a relevant observation because this past week, I've been going hard on an open source side project that I'm hoping to release into the wild in the near future.

It's a #ruby gem for dry-types and dry-struct from #dryrb that gives you the ability to export all of your types and structs to #typescript

This is especially useful when you've got a Typescript frontend receiving responses from a Ruby backend! Being able to share types between the two sides will help keep things consistent and reduce having to maintain duplicate definitions of types.

I've still got a couple of issues to work out but it's getting close.

The two biggest issues I'm working on:

1. Ruby-land dependency resolution - in particular, following references to types from one module to another, and so on, to make sure that types that are referenced by a TS-expored type also get exported, or at the very least, flagged to the user.

2. Typescript-land dependency resolution - any types that depend on other types should have their dependencies exported first. For example, if you have a User type and a Users type which is an array of User, there's a dependency there and User needs to be exported first.

Slowly chipping away on this. I'm eager to get this out for a beta release.

Using dry-validation and an HTML form, how would you handle a field which can be either a boolean or a comma separated list? It must ultimately map to the same symbol name.
#dry_validations #dryrb

@Sandbagger I'm glad you found that #ruby toy project interesting, the ogpreview was not meant for document #docker with #Rails, but mostly to demonstrate good practices such as Railway Oriented Programming in general and @dry_rb gems in particular.

Also, if you want to go a little bit deeper, you can check the repository for my talk in #RubyConf2022, where it was more about API input validations & in general and #modularity by accident:

https://github.com/esparta/rubyconf2022

#dryrb #DryValidation

Dry Transaction permite que você modele o fluxo de trabalho como uma série de operações independentes. A principal vantagem do Dry Transaction é que ele permite que você mantenha sua lógica de negócios livre de detalhes de implementação. ❤️
Vale apena conhecer. https://dry-rb.org/

#ruby #fp #dry #drymonads #dryrb

#speaking pro tip: Remember to actually drink water before your talk. Else you are going to be as dry as the Sahara when you are trying to talk about #dryrb and #hanami

However, if I change Args to use an explicit block, it works for some reason:

```
require 'dry/types'

module Types
include Dry::Types()
Args = Types::Array.of(Types::String).constructor do |value|
value.split
end
end

require 'dry/schema'

Params = Dry::Schema::Params() do
required(:args).filled(Types::Args)
end

Params.call("args" => "foo bar")
# => #<Dry::Schema::Result{:args=>["foo", "bar"]} errors={} path=[]>
```
#dryrb #dry_rb

Hmm, think I found an inconsistency in dry-types:

```
require 'dry/types'

module Types
include Dry::Types()
Args = Types::Array.of(Types::String).constructor(&:split)
end

require 'dry/schema'

Params = Dry::Schema::Params() do
required(:args).filled(Types::Args)
end

Params.call("args" => "foo bar")
# => #<Dry::Schema::Result{:args=>"foo"} errors={:args=>["must be an array"]} path=[]>
```

"foo bar" is being coerced to `str.split[0]`.
#dryrb #dry_rb

Is there a way to convert `Dry::Schema.Params` into an identical `Dry::Schema.JSON` schema? What if I want to coerce/validate both HTTP params that are then passed to a Sidekiq worker and deserialized as JSON params?
#dryrb #dry_rb

Why doesn't `Dry::Types::Range` have an `.of()` method for specifying that the Range must be of Integers or Strings?
#dryrb #dry_rb

Where should I store my dry-validation or dry-schema classes if I'm not using Hanami or Rails? Obviously if I was using dry-struct, I'd store them in `models/`. However, where should dry-validation contract classes go?
#dryrb #dry_rb

I wonder if dry-schema or dry-validation can coerce a String into an Array by splitting the String. I assume I can define a custom type that can do that?
#dryrb

I also wonder what is the best way to raise an exception or log errors returned by dry-validations from within a sidekiq worker? Say somehow malformed data gets passed to MyWorker.perform_async(...) but the MyWorker class validates the data using dry-schema or dry-validation.
#dryrb #sidekiq

I'm also curious how people are using dry-validation/dry-schema/dry-struct to handle sinatra params from forms or sidekiq job arguments. Do people use the dry-* libraries directly, or do they use one of the other plugin libraries such as sinatra-validation, sinatra-dry_params, or sidekiq-dry?
https://github.com/IzumiSy/sinatra-validation
https://github.com/tiev/sinatra-dry_param
https://github.com/zorbash/sidekiq-dry
#dryrb #sinatra #sidekiq #params

should dry-schema or dry-validation rules be defined as named classes, or inline in the sinatra routes using sinatra-validation? If defined as classes, what is the best practice for naming them or what directory should they be stored in?
https://github.com/IzumiSy/sinatra-validation#usage
#dryrb #sinatra

When should I use dry-schema vs. dry-validation?
#dryrb