jwoertink

jwoertink

Core member @luckyframework.

Member Since 13 years ago

Las Vegas, NV

Experience Points
165
follower
Lessons Completed
95
follow
Lessons Completed
192
stars
Best Reply Awards
157
repos

3435 contributions in the last year

Pinned
⚡ A Kemal application generator
⚡ Kemal API Version Extension
⚡ JRuby + jMonkeyEngine 3D fun
⚡ Ruby port of the Dopewars / Drugwars game
⚡ How to get started with WebRTC
⚡ A crystal shard for doing music related stuff
Activity
Jan
24
16 hours ago
push

jwoertink push luckyframework/lucky

jwoertink
jwoertink

make done compiling message more visible (#1606) (#1653)

commit sha: 48d8f7b30367dd405e2bf78e1a2d797235bc82c3

push time in 17 minutes ago
pull request

jwoertink pull request luckyframework/lucky

jwoertink
jwoertink

make done compiling message more visible (#1606)

fixes https://github.com/luckyframework/lucky/issues/1606

Colorize "Done" in "Done compiling" to make it more visible

Screen Shot 2022-01-23 at 14 38 22
Activity icon
issue

jwoertink issue luckyframework/lucky

jwoertink
jwoertink

Add "spinner" to watch task when compiling, or recompiling

Related: https://github.com/luckyframework/lucky/pull/1067 Related: https://github.com/luckyframework/lucky_cli/pull/481

When we start compiling tasks, we show a "spinner" in the console. It's neat, and adds a little flare while you're sitting there waiting.

Right now when we run the lucky watch task, between compiles, you'll either see "Compiling..." or "Recompiling..." but no spinner. Having the spinner would allow it to stand out a little more within the mess that is the Process manager output..

pull request

jwoertink merge to luckyframework/lucky

jwoertink
jwoertink

make done compiling message more visible (#1606)

fixes https://github.com/luckyframework/lucky/issues/1606

Colorize "Done" in "Done compiling" to make it more visible

Screen Shot 2022-01-23 at 14 38 22
jwoertink
jwoertink

Thanks for doing this!

Jan
22
2 days ago
push

jwoertink push luckyframework/website

jwoertink
jwoertink

Bump nanoid from 3.1.30 to 3.2.0 (#907)

Bumps nanoid from 3.1.30 to 3.2.0.


updated-dependencies:

  • dependency-name: nanoid dependency-type: indirect ...

Signed-off-by: dependabot[bot] [email protected]

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

commit sha: 7b664d585b7058e7506e709ae528fcf8fb8fff66

push time in 2 days ago
Activity icon
delete

jwoertink in luckyframework/website delete branch dependabot/npm_and_yarn/nanoid-3.2.0

deleted time in 2 days ago
pull request

jwoertink pull request luckyframework/website

jwoertink
jwoertink

Bump nanoid from 3.1.30 to 3.2.0

Bumps nanoid from 3.1.30 to 3.2.0.

Changelog

Sourced from nanoid's changelog.

Change Log

This project adheres to Semantic Versioning.

3.2

  • Added --size and --alphabet arguments to binary (by Vitaly Baev).

3.1.32

  • Reduced async exports size (by Artyom Arutyunyan).
  • Moved from Jest to uvu (by Vitaly Baev).

3.1.31

  • Fixed collision vulnerability on object in size (by Artyom Arutyunyan).
Commits

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the Security Alerts page.
Jan
21
3 days ago
Activity icon
issue

jwoertink issue comment graphql-crystal/graphql

jwoertink
jwoertink

Issues using Int64 in input objects

Any time I try to use Int64 in an input object, I get this error:

Which expanded to:

 > 34 |                 
 > 35 |                 when Int
 > 36 |                   arg_value.as(Int64)
                          ^
Error: can't cast Int32 to Int64

It works fine with Int32 though.

@[GraphQL::InputObject]
class MenuItemInput
  include GraphQL::InputObjectType

  @title : String
  @amount : Int64

  @[GraphQL::Field]
  def initialize(@title : String, @amount : Int64)
  end

  @[GraphQL::Field]
  def title : String
    @title
  end

  @[GraphQL::Field]
  def amount : Int64
    @amount
  end
end
jwoertink
jwoertink

Ah. In that case, maybe there can be a better error message to say Int64 is not supported, and maybe use a String?

Activity icon
issue

jwoertink issue graphql-crystal/graphql

jwoertink
jwoertink

Issues using Int64 in input objects

Any time I try to use Int64 in an input object, I get this error:

Which expanded to:

 > 34 |                 
 > 35 |                 when Int
 > 36 |                   arg_value.as(Int64)
                          ^
Error: can't cast Int32 to Int64

It works fine with Int32 though.

@[GraphQL::InputObject]
class MenuItemInput
  include GraphQL::InputObjectType

  @title : String
  @amount : Int64

  @[GraphQL::Field]
  def initialize(@title : String, @amount : Int64)
  end

  @[GraphQL::Field]
  def title : String
    @title
  end

  @[GraphQL::Field]
  def amount : Int64
    @amount
  end
end
pull request

jwoertink merge to mosquito-cr/mosquito

jwoertink
jwoertink

Rate limiter module for jobs

This is a re-implementation of the throttling logic introduced in v0.4.0 via #20, but implemented as a decorator module.

The throttling configuration syntax is concise:

class RateLimitedJob < Mosquito::QueuedJob
  include Mosquito::RateLimiter

  throttle limit: 1, per: 10.seconds

  params blah : Int32

  def perform
    # etc...
  end
end

Highlights:

  • Leverages before hook introduced in 7de390cf160756c16cbd360975786fb4fc698b66 (v0.11.1) so the interface is transparent, and doesn't have any performance penalty on jobs which don't need rate limiting.
  • Leverages metadata store introduced in ae67378f9b7c5acaee60fb7df36816e26ea09a8c. The rate limit configuration logic is no longer dangling off of Queue.
  • The rate limit key is now override-able, which means that multiple jobs can share the same rate limit counters. This hopefully will be useful for guarding against 3rd api usage guidelines.

Ancillary improvements:

  • Implements after hooks, by copying and pasting the before hook code and tests.
  • Extends metadata#increment to allow passing in an increment value.
  • Fixes a latent bug where false could not be set as the default value for a job parameter.
jwoertink
jwoertink

Overall I think the code looks great. The only tricky part for me was the context switching in the RateLimiter module when it goes from class methods to instance methods. I think that's just more nature of the beast.

I left a few suggestions, but I didn't really see anything major sticking out

open pull request

jwoertink wants to merge mosquito-cr/mosquito

jwoertink
jwoertink

Rate limiter module for jobs

This is a re-implementation of the throttling logic introduced in v0.4.0 via #20, but implemented as a decorator module.

The throttling configuration syntax is concise:

class RateLimitedJob < Mosquito::QueuedJob
  include Mosquito::RateLimiter

  throttle limit: 1, per: 10.seconds

  params blah : Int32

  def perform
    # etc...
  end
end

Highlights:

  • Leverages before hook introduced in 7de390cf160756c16cbd360975786fb4fc698b66 (v0.11.1) so the interface is transparent, and doesn't have any performance penalty on jobs which don't need rate limiting.
  • Leverages metadata store introduced in ae67378f9b7c5acaee60fb7df36816e26ea09a8c. The rate limit configuration logic is no longer dangling off of Queue.
  • The rate limit key is now override-able, which means that multiple jobs can share the same rate limit counters. This hopefully will be useful for guarding against 3rd api usage guidelines.

Ancillary improvements:

  • Implements after hooks, by copying and pasting the before hook code and tests.
  • Extends metadata#increment to allow passing in an increment value.
  • Fixes a latent bug where false could not be set as the default value for a job parameter.
jwoertink
jwoertink
  # TODO: https://github.com/mosquito-cr/mosquito/issues/66
  params()

Just a suggestion, but it'll at least explain why and not just look like random floating code.

open pull request

jwoertink wants to merge mosquito-cr/mosquito

jwoertink
jwoertink

Rate limiter module for jobs

This is a re-implementation of the throttling logic introduced in v0.4.0 via #20, but implemented as a decorator module.

The throttling configuration syntax is concise:

class RateLimitedJob < Mosquito::QueuedJob
  include Mosquito::RateLimiter

  throttle limit: 1, per: 10.seconds

  params blah : Int32

  def perform
    # etc...
  end
end

Highlights:

  • Leverages before hook introduced in 7de390cf160756c16cbd360975786fb4fc698b66 (v0.11.1) so the interface is transparent, and doesn't have any performance penalty on jobs which don't need rate limiting.
  • Leverages metadata store introduced in ae67378f9b7c5acaee60fb7df36816e26ea09a8c. The rate limit configuration logic is no longer dangling off of Queue.
  • The rate limit key is now override-able, which means that multiple jobs can share the same rate limit counters. This hopefully will be useful for guarding against 3rd api usage guidelines.

Ancillary improvements:

  • Implements after hooks, by copying and pasting the before hook code and tests.
  • Extends metadata#increment to allow passing in an increment value.
  • Fixes a latent bug where false could not be set as the default value for a job parameter.
jwoertink
jwoertink

What are your thoughts on requiring named args here? throttle(*, limit, per...)

open pull request

jwoertink wants to merge mosquito-cr/mosquito

jwoertink
jwoertink

Rate limiter module for jobs

This is a re-implementation of the throttling logic introduced in v0.4.0 via #20, but implemented as a decorator module.

The throttling configuration syntax is concise:

class RateLimitedJob < Mosquito::QueuedJob
  include Mosquito::RateLimiter

  throttle limit: 1, per: 10.seconds

  params blah : Int32

  def perform
    # etc...
  end
end

Highlights:

  • Leverages before hook introduced in 7de390cf160756c16cbd360975786fb4fc698b66 (v0.11.1) so the interface is transparent, and doesn't have any performance penalty on jobs which don't need rate limiting.
  • Leverages metadata store introduced in ae67378f9b7c5acaee60fb7df36816e26ea09a8c. The rate limit configuration logic is no longer dangling off of Queue.
  • The rate limit key is now override-able, which means that multiple jobs can share the same rate limit counters. This hopefully will be useful for guarding against 3rd api usage guidelines.

Ancillary improvements:

  • Implements after hooks, by copying and pasting the before hook code and tests.
  • Extends metadata#increment to allow passing in an increment value.
  • Fixes a latent bug where false could not be set as the default value for a job parameter.
jwoertink
jwoertink

should this call the method below?

pull request

jwoertink merge to mosquito-cr/mosquito

jwoertink
jwoertink

Rate limiter module for jobs

This is a re-implementation of the throttling logic introduced in v0.4.0 via #20, but implemented as a decorator module.

The throttling configuration syntax is concise:

class RateLimitedJob < Mosquito::QueuedJob
  include Mosquito::RateLimiter

  throttle limit: 1, per: 10.seconds

  params blah : Int32

  def perform
    # etc...
  end
end

Highlights:

  • Leverages before hook introduced in 7de390cf160756c16cbd360975786fb4fc698b66 (v0.11.1) so the interface is transparent, and doesn't have any performance penalty on jobs which don't need rate limiting.
  • Leverages metadata store introduced in ae67378f9b7c5acaee60fb7df36816e26ea09a8c. The rate limit configuration logic is no longer dangling off of Queue.
  • The rate limit key is now override-able, which means that multiple jobs can share the same rate limit counters. This hopefully will be useful for guarding against 3rd api usage guidelines.

Ancillary improvements:

  • Implements after hooks, by copying and pasting the before hook code and tests.
  • Extends metadata#increment to allow passing in an increment value.
  • Fixes a latent bug where false could not be set as the default value for a job parameter.
jwoertink
jwoertink

Overall I think the code looks great. The only tricky part for me was the context switching in the RateLimiter module when it goes from class methods to instance methods. I think that's just more nature of the beast.

I left a few suggestions, but I didn't really see anything major sticking out

Activity icon
issue

jwoertink issue luckyframework/avram

jwoertink
jwoertink

The `any?` query method generates the wrong cache key

https://github.com/luckyframework/avram/blob/ac281f490a85283eaf8b74fd23357dd70a6d7f22/src/avram/queryable.cr#L220-L227

If you call the .any? query method, then try to iterate on that query object, the cache_key would end up being the wrong key.

users = UserQuery.new

if users.any?
  users.results
end

In this example, then cache_key used in any? would be SELECT * FROM users, but the return value would be Bool. Then you call users.results which looks at the cache for key SELECT * FROM users and expects an Array(User), but gets back Bool, and causes a casting error.

Activity icon
issue

jwoertink issue comment crystal-lang/crystal

jwoertink
jwoertink

Add arithmetic expressions to the type grammar

Feature Request

StaticArray(T, S) has an interesting property where the size of the array is specified in the type grammar. I tried to follow this pattern in a 2 dimensional matrix struct (below), however it appears that this results in a syntax error.

struct Matrix(T, W, H)
  property values : StaticArray(T, W * H)

  def initialize(@values)
  end
end

I think allowing this type of expression in the type grammar would be a nice improvement to the language.

jwoertink
jwoertink

If this does get added, it would be good to also resolve https://github.com/crystal-lang/crystal/issues/4238. Since the type parameter has to be a literal, passing in a variable leads to an unexpected token error which can be a bit confusing.

Jan
20
4 days ago
Activity icon
issue

jwoertink issue comment luckyframework/lucky_task

jwoertink
jwoertink

Cannot use --name as an arg

It conflicts with the name macro and the code thinks it is not supplied.

Unhandled exception: name is required, but no value was passed.

Try this...

  -n SOME_VALUE
  --name=SOME_VALUE (Exception)
  from tasks/invite_user_task.cr:11:3 in 'name'
  from lib/lucky_task/src/lucky_task/runner.cr:8:24 in 'tasks'
  from tasks/db/seed/required_data.cr:9:1 in '__crystal_main'
  from /Users/matthew/.asdf/installs/crystal/1.3.0/src/crystal/main.cr:115:5 in 'main_user_code'
  from /Users/matthew/.asdf/installs/crystal/1.3.0/src/crystal/main.cr:101:7 in 'main'
  from /Users/matthew/.asdf/installs/crystal/1.3.0/src/crystal/main.cr:127:3 in 'main'
Jan
19
5 days ago
Activity icon
issue

jwoertink issue comment luckyframework/lucky

jwoertink
jwoertink

Add "spinner" to watch task when compiling, or recompiling

Related: https://github.com/luckyframework/lucky/pull/1067 Related: https://github.com/luckyframework/lucky_cli/pull/481

When we start compiling tasks, we show a "spinner" in the console. It's neat, and adds a little flare while you're sitting there waiting.

Right now when we run the lucky watch task, between compiles, you'll either see "Compiling..." or "Recompiling..." but no spinner. Having the spinner would allow it to stand out a little more within the mess that is the Process manager output..

jwoertink
jwoertink

Ah... well that's a bummer :joy: Thanks so much for giving it a shot! In that case, I think https://github.com/luckyframework/lucky/pull/1067#issuecomment-625411134 is the next best solution. It'll bring a bit more attention to what's going on when there's a lot of other activity.

Activity icon
issue

jwoertink issue comment luckyframework/lucky

jwoertink
jwoertink

Add "spinner" to watch task when compiling, or recompiling

Related: https://github.com/luckyframework/lucky/pull/1067 Related: https://github.com/luckyframework/lucky_cli/pull/481

When we start compiling tasks, we show a "spinner" in the console. It's neat, and adds a little flare while you're sitting there waiting.

Right now when we run the lucky watch task, between compiles, you'll either see "Compiling..." or "Recompiling..." but no spinner. Having the spinner would allow it to stand out a little more within the mess that is the Process manager output..

jwoertink
jwoertink

oh, the next release of Lucky won't use Overmind anymore (unless you specifically want it to). https://github.com/luckyframework/lucky_cli/pull/710 I don't mind the suggestion as an interim, but since we already use the spinner when building tasks and such, I'd love to keep the consistency. I'd like to try it out with Nox and see if it works first. If not, then we will definitely fallback to your suggestion :+1:

Jan
18
6 days ago
Activity icon
issue

jwoertink issue comment luckyframework/website

jwoertink
jwoertink

Extended docs for "Parsing JSON Requests"

I couldn't replicate the SerializedInvoice example of the docs on a project of mine.

I've extended the example with information provided on the Discord server.

jwoertink
jwoertink

@rubenjr0 no worries at all! We appreciate you updating this.

Jan
17
1 week ago
Activity icon
issue

jwoertink issue comment luckyframework/website

jwoertink
jwoertink

Extended docs for "Parsing JSON Requests"

I couldn't replicate the SerializedInvoice example of the docs on a project of mine.

I've extended the example with information provided on the Discord server.

jwoertink
jwoertink

Looks like there's still some trailing whitespace. You can run ./bin/ameba locally to check these @rubenjr0 Once those are resolved, this should be good to go

pull request

jwoertink pull request luckyframework/lucky

jwoertink
jwoertink

Allowing for rounding up on hours.

Fixes #1649

Purpose

Allowing for a more expected return when a time is closer to the higher hour mark.

Description

Just a small tweak to see if the time is closer to the next hour.

Checklist

  • - An issue already exists detailing the issue/or feature request that this PR fixes
  • - All specs are formatted with crystal tool format spec src
  • - Inline documentation has been added and/or updated
  • - Lucky builds on docker with ./script/setup
  • - All builds and specs pass on docker with ./script/test
Activity icon
issue

jwoertink issue luckyframework/lucky

jwoertink
jwoertink

time_ago_in_words always rounds down

puts time_ago_in_words(110.minutes.ago) #=> an hour

It currently returns on hours because this is technically only 1 hour, but it ignores the other 50minutes. I would expect this to return "almost 2 hours" instead.

https://github.com/luckyframework/lucky/blob/e1a6adf8552676884e67528293d3142032387b4b/src/lucky/page_helpers/time_helpers.cr#L25

We do already make a special concession for minutes past 45 where we say "about an hour" if it's been 46minutes or more

https://github.com/luckyframework/lucky/blob/e1a6adf8552676884e67528293d3142032387b4b/src/lucky/page_helpers/time_helpers.cr#L77-L79

We could probably do the same here that if it's past X hour and 45 minutes, then just round up.

push

jwoertink push luckyframework/lucky

jwoertink
jwoertink

Allowing for rounding up on hours. (#1651)

Ref #1649

commit sha: 3d11af72a35d916f10df0e85e082739b9bef87b7

push time in 6 days ago
pull request

jwoertink merge to luckyframework/lucky

jwoertink
jwoertink

Allowing for rounding up on hours.

Ref #1649

Purpose

Allowing for a more expected return when a time is closer to the higher hour mark.

Description

Just a small tweak to see if the time is closer to the next hour.

Checklist

  • - An issue already exists detailing the issue/or feature request that this PR fixes
  • - All specs are formatted with crystal tool format spec src
  • - Inline documentation has been added and/or updated
  • - Lucky builds on docker with ./script/setup
  • - All builds and specs pass on docker with ./script/test
Activity icon
issue

jwoertink issue comment luckyframework/lucky

jwoertink
jwoertink

time_ago_in_words always rounds down

puts time_ago_in_words(110.minutes.ago) #=> an hour

It currently returns on hours because this is technically only 1 hour, but it ignores the other 50minutes. I would expect this to return "almost 2 hours" instead.

https://github.com/luckyframework/lucky/blob/e1a6adf8552676884e67528293d3142032387b4b/src/lucky/page_helpers/time_helpers.cr#L25

We do already make a special concession for minutes past 45 where we say "about an hour" if it's been 46minutes or more

https://github.com/luckyframework/lucky/blob/e1a6adf8552676884e67528293d3142032387b4b/src/lucky/page_helpers/time_helpers.cr#L77-L79

We could probably do the same here that if it's past X hour and 45 minutes, then just round up.

jwoertink
jwoertink

oh, look at that! I didn't even know that existed. Good find @robacarp

Activity icon
issue

jwoertink issue comment luckyframework/avram

jwoertink
jwoertink

Add more helpful compiler errors if wrong data types are passed as where query arguments

For example, when passing a Time::Span to the gt method to build a query:

BlockQuery.new.time.gt(1.day)

# (should be: BlockQuery.new.time.gt(Time.utc - 1.day))

The error is not referencing the gt method:

In lib/avram/src/avram/type.cr:25:5

 25 | parse(value).as(SuccessfulCast).value
      ^----
Error: no overload matches 'Time::Lucky.parse' with type Time::Span
jwoertink
jwoertink

Time::Span should probably never be called. We might be able to just do an overload

def gt(value : Time::Span)
  {% raise "You probably meant to pass aTime" %}
end

Not sure if that would work or not, but I'd say we start there at least.

Activity icon
issue

jwoertink issue comment luckyframework/lucky

jwoertink
jwoertink

time_ago_in_words always rounds down

puts time_ago_in_words(110.minutes.ago) #=> an hour

It currently returns on hours because this is technically only 1 hour, but it ignores the other 50minutes. I would expect this to return "almost 2 hours" instead.

https://github.com/luckyframework/lucky/blob/e1a6adf8552676884e67528293d3142032387b4b/src/lucky/page_helpers/time_helpers.cr#L25

We do already make a special concession for minutes past 45 where we say "about an hour" if it's been 46minutes or more

https://github.com/luckyframework/lucky/blob/e1a6adf8552676884e67528293d3142032387b4b/src/lucky/page_helpers/time_helpers.cr#L77-L79

We could probably do the same here that if it's past X hour and 45 minutes, then just round up.

jwoertink
jwoertink

Also just to note how this works because I was a little surprised...

started = 110.minutes.ago
now = Time.utc

pp (now - started).minutes #=> 50

This doesn't give you the whole time in minutes. I think it basically sees the time as 1:50:00, and says "the minutes from this is 50".

Activity icon
issue

jwoertink issue luckyframework/lucky

jwoertink
jwoertink

time_ago_in_words always rounds down

puts time_ago_in_words(110.minutes.ago) #=> an hour

It currently returns on hours because this is technically only 1 hour, but it ignores the other 50minutes. I would expect this to return "almost 2 hours" instead.

https://github.com/luckyframework/lucky/blob/e1a6adf8552676884e67528293d3142032387b4b/src/lucky/page_helpers/time_helpers.cr#L25

We do already make a special concession for minutes past 45 where we say "about an hour" if it's been 46minutes or more

https://github.com/luckyframework/lucky/blob/e1a6adf8552676884e67528293d3142032387b4b/src/lucky/page_helpers/time_helpers.cr#L77-L79

We could probably do the same here that if it's past X hour and 45 minutes, then just round up.

started
started time in 1 week ago
Previous