This was one of those tasks I was sure we were going to put off for way too long.
We still don't have a four-year badge designed, but I feel like this part of the code now could probably be refactored to account for an arbitrary number of years, and maybe take an environment variable to determine how many to iterate through.
Anyone who wants to refactor this so we don't need to add a new method every year is welcome to submit another PR at some point in the next 11 or so months. π
Native Android developer/Consultant for Appwise, I work on custom projects for clients.
PHP/JS (web) developer in my freetime. Trying to keep learning in an ever changing tech world.
Interesting, this would indeed be a good improvement to be more future proof. Only thing you still would need to do is prepare the designs for the upcoming years but you could make a couple at once so you will be good for a few years π
I am triggered by this challenge but am afraid that my knowledge in Ruby isn't good enough right now.
defself.award_x_year_badges(x)@n={1=>"one",2=>"two",3=>"three",4=>"four",5=>"five",6=>"six",7=>"seven",8=>"eight",9=>"nine",10=>"ten"}s=x==1?"":"s"message="Happy DEV birthday! Can you believe it's been #{@n[x]} year#{s} already?!"User.where("created_at < ? AND created_at > ?",(x).year.ago,(x*365+2).days.ago).find_eachdo|user|achievement=BadgeAchievement.create(user_id: user.id,badge_id: Badge.find_by_slug("#{@n[x]}-year-club").id,rewarding_context_message_markdown: message,)user.saveifachievement.valid?endendforxin1..10self.award_x_year_badges(x)end
Though I don't really know ruby either π
I'm not sure this line would work as expected
User.where("created_at < ? AND created_at > ?",(x).year.ago,(x*365+2).days.ago).find_eachdo|user|
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This was one of those tasks I was sure we were going to put off for way too long.
We still don't have a four-year badge designed, but I feel like this part of the code now could probably be refactored to account for an arbitrary number of years, and maybe take an environment variable to determine how many to iterate through.
Anyone who wants to refactor this so we don't need to add a new method every year is welcome to submit another PR at some point in the next 11 or so months. π
Interesting, this would indeed be a good improvement to be more future proof. Only thing you still would need to do is prepare the designs for the upcoming years but you could make a couple at once so you will be good for a few years π
I am triggered by this challenge but am afraid that my knowledge in Ruby isn't good enough right now.
I'd guess something like this
Though I don't really know ruby either π
I'm not sure this line would work as expected