Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 15:08
    jodosha labeled #1041
  • 15:08
    jodosha assigned #1041
  • 15:08
    jodosha milestoned #1041
  • 15:08
    jodosha opened #1041
  • 15:07

    jodosha on travis-integration-matrix

    Travis CI integration matrix (compare)

  • 15:02

    jodosha on point-to-hanami-view-1.x-master

    (compare)

  • 15:02

    jodosha on master

    Point to 1.x-master branch of h… (compare)

  • 15:02
    jodosha closed #1037
  • 15:02
    jodosha closed #1036
  • 15:01
    jodosha labeled #1036
  • 15:01
    jodosha milestoned #1036
  • 15:01
    jodosha assigned #1036
  • 15:01
    jodosha milestoned #1037
  • 15:01
    jodosha labeled #1037
  • 15:00
    jodosha assigned #1037
  • 14:54
    jodosha synchronize #1032
  • 14:54

    jodosha on hanami-router-2-alpha2

    API docs (compare)

  • 13:51
    jodosha commented #1032
  • 13:21
    timriley edited #1040
  • 13:21
    timriley opened #1040
Aleksander Długopolski
@adlugopolski
I’ll will later today yes - I will make another base app to make sure it’s not realted to anything else on the way. I’ve added a few gems to this app on the way.
Kai Kuchenbecker
@kaikuchn
Pretty sure it's shotgun. IIRC it's going away soon. Don't remember what the replacement will be though
Aleksander Długopolski
@adlugopolski
btw: How is 2.0.0 going? Should I try checkout the framework from 1.3.3 or move to 2.0 alpha?
And is there 2.7 support on the way? Maybe theres something thats needs help in this regard?
Kai Kuchenbecker
@kaikuchn
It's progressing nicely, I'm not really involved in the development effort so I'm unsure on the exact current state. In essence hanami 2.0 will be an umbrella for dry-gems. It will handle most of the plumbing necessary to write a web app using the dry ecosystem.
But it's all early stages still and many concepts need to be discussed. I.e., things are going to change a lot. So if you want to use Hanami in production for a critical component any time soon, stick with 1.3.3. If you just want to play around, you can checkout 2.0 but there's obviously a big lack on documentation right now.
At least that's my understanding :)
Aleksander Długopolski
@adlugopolski
Sounds resonable, thank you. I am planning to use in production, but its nothing critical, so I might as well just run into 2.0 instead.
Paweł Świątkowski
@katafrakt
Right now you can use https://github.com/hanami/reloader instead of shotgun; experimental, but works for me
Aleksander Długopolski
@adlugopolski
@katafrakt Thanks! I’ll try it. :-)
Aleksander Długopolski
@adlugopolski
@kaikuchn I tried to replicate the crash on new app and found out that both guard and shotgun have to be added to Gemfile in order for the fail to happen. But whats even more werid I have guard added with require: false.
Panayotis Matsinopoulos
@pmatsinopoulos

Hello Good People.

Can you please let me know why the following piece of code prints true?

require 'hanami'

class Signup
  include Hanami::Validations

  validations do
    required(:name)
  end
end

p Signup.new.validate.success? # true Why?

Thank you in advance.

Paweł Świątkowski
@katafrakt
@pmatsinopoulos you need required(:name).filled
Panayotis Matsinopoulos
@pmatsinopoulos
@katafrakt Thank you. But why is that? The required is supposed to be a schema level statement and it is supposed to tell whether a key is present in the incoming hash or not. At least according to dry schema. The filled is a rule level statement, which follows the schema level statements. And again, how can I write a validation rule in which I require a key to be present even if nil?
Kai Kuchenbecker
@kaikuchn
you could use maybe
Panayotis Matsinopoulos
@pmatsinopoulos

@kaikuchn maybe is not needed:

require 'hanami'

class Signup
  include Hanami::Validations

  validations do
    required(:name)
  end
end

p Signup.new(name: nil).validate.success? # true

which means name can be nil without maybe and, to me, it is correct, because the only thing that required implies is a structure-level rule whether the key exists or not, regardless of its value.

So, to me, I believe that the p Signup.new.validate.success?should print false, as long as you only have plain required(:name).

Like when we use dry-validation here:

require 'dry-validation'

class Signup < Dry::Validation::Contract
  params do
    required(:name)
  end
end

contract = Signup.new


p contract.call({}).success? # false
p contract.call({name: 'Peter'}).success? # true 
p contract.call({name: nil}).success? # true

Am I wrong to thing that Hanami internally is supposed to be using dry-validation|dry-schema?

David Dawson
@DangerDawson
My company have succesfully built and put into production a fairly large application using hanami, and we have been super happy with everything so far, although if there was one thing we would love to improve, and that is the hot-reloading times when developing. We are currently using the hanami-reloader gem hanami-reloader which send a signal to puma to reload when a change is detected, the problem is that the code base has reached a size where the time it takes to reboot the app is around 7-10 seconds. I am using dry-system to manage dependencies and also boot-snap to help with the reloading, but would love to know what people would suggest in reducing the reload times? e.g. is it worth investigating using zeitwerk or is there a better stategy to use?
Panayotis Matsinopoulos
@pmatsinopoulos

Good Morning Good People!

This is my first PR :-)

hanami/validations#196

Aleksander Długopolski
@adlugopolski
@DangerDawson I am not sure if Hanami have something like rake stats, but could you share some insight about the app size? Loc maybe, number of models? Just curious.
David Dawson
@DangerDawson
@adlugopolski entities: 124, controllers: 149, views: 240
Aleksander Długopolski
@adlugopolski
Thanks! :-)
Armin
@wuarmin

Hello! how looks your puma config? Could anybody please provide a working example? I have a hanami 1.3.3 app with multiple database-connections. the main database is connected via hanami-model. Other databases are connected directly with pg-gem.

I want to use puma in clustered mode with 1 to 4 workers and want to use app-preloading. What should my on_worker_boot block contain? Or should I use before_fork? Or do you recommend thread-pool?
WDYT about following:

workers 4
threads 1, 8

preload_app!

rackup      DefaultRackup
port        2300
environment 'production'

on_worker_boot do
  require_relative "config/environment"
  Hanami.boot
end

Thx

Armin
@wuarmin
What if I omit on_worker_boot?
Armin
@wuarmin
I created a SO-Question: https://stackoverflow.com/questions/61017325/how-to-configure-puma-for-a-hanami-application. Maybe somebody can help me. I'm a puma-beginner.
David Dawson
@DangerDawson
Hi @wuarmin that is close to what we use in our puma.config except we have the require_relative "config/environment” not in the on_worker_boot and require_relative config/boot outside of the block
We have been running a very large hanami app using elastic-beanstalk with our config for about 2 months now, and it all seems to be working well.
Armin
@wuarmin
Hey @DangerDawson! thanks for your response. Ok, but can you explain why we should boot the whole Hanami app in the child-processes? What is about the Hanami App running in the parent process? Does preload_app then make sense at all?
David Dawson
@DangerDawson
so in theory I suppose you could just reconnect Hanami::Model
Has some comments and example around this
David Dawson
@DangerDawson
I am not sure that Components.resolve('all’) needs to happen in the child-process and maybe can be done in the parent process
So all you then need to do in the child process is Hanami::Model.disconnect & Hanami::Model.load!
Armin
@wuarmin
Thanks these are great hints. Hanami.boot makes nothing else but reconnecting database. Interesting. Standalone Hanami::Model means i.e. using hanami model gem in rails application, doesn't it?
The info if Components.resolve('all’) is unnecessary at child processes would be very interesting. Maybe somebody know this :blush:
David Dawson
@DangerDawson
Just tried locally, and everything seems to work fine
Armin
@wuarmin
:thumbsup: Standalone Hanami::Model means i.e. using hanami model gem in another Rack app, doesn't it?
David Dawson
@DangerDawson
Yes
Armin
@wuarmin
@DangerDawson I ended with following config:
require_relative './environment'
workers 2

threads_count = 5
threads threads_count, threads_count

daemonize true

preload_app!

rackup      DefaultRackup
port        2300
environment 'production'

on_worker_boot do
  Hanami.boot
end
David Dawson
@DangerDawson
Pretty much what I have
Armin
@wuarmin
Yes, thank you for your help!
David Dawson
@DangerDawson
Not a problem, glad you got it working. Hope you enjoy using the framework as much as we do
Armin
@wuarmin
Yes I do. I coming along with Hanami since 0.6.0 and I'm looking forward to 2.0, but I'm hoping that there are good upgrade possibilities, because my Hanami 1.3.3 app is very extensive. What do you think about that? Are you attuned to do a rewrite if Hanami 2.0 is production ready?
David Dawson
@DangerDawson
My biggest pain point at the moment is the cost of reloading the codebase in development / test mode, so I am hoping thaat v2.0 may help solve that, although I need to fix this quite soon so I probably will not be able to wait. That said I am hopeful there will be a nice upgrade path and not much rewriting to be done.
Armin
@wuarmin
Which database are you using? Oracle? I observed huge starting-times if Hanami-model is connected to Oracle DB.
David Dawson
@DangerDawson
Postgres, the loading times are all to do with the fact we require all the project files on boot, and a lot of these contain macro’s which can take some time to initialise
Require: apps/web/validations: 0.9451031684875488
Armin
@wuarmin
Oh, are you working with Shotgun in development?
David Dawson
@DangerDawson
We are using a modified verion of the hanami/reloader
Which uses gaurd to tell puma to reload