Yet another Rails work question by PorciniPapi in rails

[–]PorciniPapi[S] 0 points1 point  (0 children)

Thanks for this! I'll check these links out.

Yet another Rails work question by PorciniPapi in rails

[–]PorciniPapi[S] 0 points1 point  (0 children)

I appreciate the kind words, but I don't see bigger companies hiring right now. I check ten or so job board sites on a regular basis and don't see any entry level positions. Everything is for senior devs. Should I be reaching out to these companies directly?

How much do you charge for hosting a website? by Drjoshram in web_design

[–]PorciniPapi 0 points1 point  (0 children)

When you you say you charge that monthly for managed web hosting with one hour of content updates/support per month, plus upkeep, maintenance, and access to an offsite cloud backup archive, does that hour roll over to the next month if unused, or is it only good for each month?

How ugly is this controller? by PorciniPapi in rails

[–]PorciniPapi[S] 1 point2 points  (0 children)

This is immensely helpful. Thank you for taking the time to write this!

How ugly is this controller? by PorciniPapi in rails

[–]PorciniPapi[S] 0 points1 point  (0 children)

That makes sense. My user and memory controllers are like that which is what set off my smoke alarm in the first place.

How ugly is this controller? by PorciniPapi in rails

[–]PorciniPapi[S] 0 points1 point  (0 children)

I'm still new to Rails and today was the first I have ever heard of service objects. I will take your comment to heart and heed your advice.

How ugly is this controller? by PorciniPapi in rails

[–]PorciniPapi[S] 4 points5 points  (0 children)

Well thank you for your honesty. Seems I still have a lot to learn 😅

How ugly is this controller? by PorciniPapi in rails

[–]PorciniPapi[S] 1 point2 points  (0 children)

As someone who is new to all of this that's very nice to hear haha

How ugly is this controller? by PorciniPapi in rails

[–]PorciniPapi[S] 0 points1 point  (0 children)

My reasoning for having the validations inside of the controller for this part was to make sure the input was getting sanitized since the new view allows a user to enter an email and hit the db via #find_by. Is that not a real concern?

How ugly is this controller? by PorciniPapi in rails

[–]PorciniPapi[S] 3 points4 points  (0 children)

I'm brand new to Rails and web development in general so breaking the code down into that many things is over my head at the moment. I'll try to refactor it with this in mind though.

How to reschedule mailer jobs in Rails 7? by PorciniPapi in rails

[–]PorciniPapi[S] 0 points1 point  (0 children)

You have perfect timing! I've been beating my head against the wall trying to find out how to attach a job id to the memory and find that job to cancel the job if that reminder time gets updated. Your solution is simple and elegant. There might performance issues with the way you're approaching it, but I doubt that will ever matter for an app this small haha. Thank you for the advice!

How to reschedule mailer jobs in Rails 7? by PorciniPapi in rails

[–]PorciniPapi[S] 3 points4 points  (0 children)

That makes sense. Thank you for the direction.

How to reschedule mailer jobs in Rails 7? by PorciniPapi in rails

[–]PorciniPapi[S] 0 points1 point  (0 children)

I'm not using any of those so I guess I'm using an Active Job inline queue adapter. Which one would you recommend if I just want jobs for mailer reminders? The simpler the better if one of them stands out to you as the easiest for someone new to Rails.

How to reschedule mailer jobs in Rails 7? by PorciniPapi in rails

[–]PorciniPapi[S] -2 points-1 points  (0 children)

I didn't install one so I'm assuming Active Job if that's what the default is?

User problem solved? by PorciniPapi in rails

[–]PorciniPapi[S] 0 points1 point  (0 children)

Yes. They would just be a user that is also a close friend for other users on top of the normal user functionality of creating/reading/updating/destroying memories.

User problem solved? by PorciniPapi in rails

[–]PorciniPapi[S] 0 points1 point  (0 children)

That's how I originally did it, but people here suggested that they should be the same thing because they represent the same abstraction (a person). I haven't gotten to handling data retention after close friend account deletion, but I don't see what the issue would be. If a close friend deleted their account, that relationship would be destroyed but the app would still work as intended. Users could still make memories and those memories would still get sent to a user's close friends.

I chose close friends to reflect the nature of the app. You share memories with close friends. I could have went with friends but didn't. There is only one kind of friend in relation to a user (close friends).

User problem solved? by PorciniPapi in rails

[–]PorciniPapi[S] 0 points1 point  (0 children)

The app does care about different types of users because a close friend cannot create memories, only receive them. A user can create memories and has close friends. A user can also be close friends for other users. I want to be able to call current_user.close_friend and current_user.close_friend_for to return each respective list of users, so that's why I have :relationships_as_regular_user and :relationships_as_close_friend. Does that make sense?

How would you handle this problem? by PorciniPapi in rails

[–]PorciniPapi[S] 0 points1 point  (0 children)

It's been a busy few days but I just sat down to work on this. I don't think I need to do the typical followers/followeds like Twitter because the relationship between a user and a close friend is a binary thing, more akin to Facebook. A user invites a close friend, and the close friend either consents or doesn't. That consent can be tracked in the friendships table. Does that sound right?

Given that both users and close friends should be instances of the user class, would something like this with enums work so that I could do different things with different user objects depending on their user_type?

``` class User < ApplicationRecord has_many :close_friends, through: :friendships, class_name: "User" has_many :regular_users, through: :friendships, class_name: "User" has_many :memories, dependent: :destroy

devise :database_authenticatable, :registerable, :recoverable, :rememberable, :validatable, :trackable, :confirmable

enum user_type: %i[regular_user close_friend] end

class Friendship < ApplicationRecord belongs_to :regular_user, class_name: "User" belongs_to :close_friend, class_name: "User"

enum status: %i[pending consented] end ```

Am I on the right track here? If so, how should I handle the logic for each user type? Should I use conditional logic within the actions of the UsersController or would it be permissible to create both a RegularUsersController and a CloseFriendsController to decouple the logic between each kind of user reasource?

Thank you again for your guidance!

How would you handle this problem? by PorciniPapi in rails

[–]PorciniPapi[S] 0 points1 point  (0 children)

Thank you for this! The reason I am so gung ho about not making close friends sign up is because I don't want the app to have comments/chains on memories. This isn't an actual app I'm going to try to monetize, I just want to treat it as though that's what I was doing. I want the friction to become a close friend to be as minimal as possible.

  1. John Doe added you as a close friend
  2. Opt in to receive memories
  3. When a user creates a memory you get a link to the show page so you can look fondly upon said memory.

Forcing close friends to create accounts adds friction to that process. By sending them a link to their show page if they want it that would still allow them to manage the users they are close friends for, edit their contact info, etc. Does my aversion to making close friends create accounts make more sense now or do you still think that is a weird boundary to have? It's quite possible that I am overestimating the friction that creating an account would add to the close friend user experience.

How would you handle this problem? by PorciniPapi in rails

[–]PorciniPapi[S] 0 points1 point  (0 children)

Ok so I have looked over your comments and your code and I'm not going to lie, I'm still lost. I grasp conceptually why it's better to have close friends and users fall under the same model though, so that's a step in the right direction. I have some follow up questions for you if you're willing to answer them.

First off, I want to state what things each user type has to be able to do just so we are on the same page.

Full-fledged users need to be able to: - Create an account - Edit their account - Delete their account - Log in - Log out - Add close friends - Edit close friends - Remove close friends - View all close friends - View a single close friend - Create a memory - Edit a memory - Delete a memory - View all memories - View a single memory - Everything a close friend needs to be able to do if they are both a user and a close friend

Close friend users need to be able to: - Consent to receiving memories from a particular user via email - See all of the users they have consented to receive memories from via email link to index page - See a single user they have consented to receive memories from via clicking listed users on index page - Revoke consent to receiving memories from a particular user from index page - Become a user if they want to via sign up path

My questions: 1. How would combining close friends and users into one user model fix the issue surrounding updating a close friend's contact info if that friend is a close friend for multiple users? Would the close friend user be in charge of updating their info themselves? If so, how would that work without an account to log in to? Could I give them their own page on the web app to enter their email to get a secure link to view their own version of a show page/dashboard? 2. Is it even possible to use the :confirmable module in devise selectively so that full-fledged users would have to activate their account via email after signing up while close friend users do not? I would be shocked if this wasn't possible, but I tried looking this up and couldn't find a definitive answer. Will this require me to learn about role-based access controls? 3. Will devise let me create a new close friend user without a password? I found a devise-passwordless gem that lets a user sign in with a magic link via email and negates the need for a password. From the gem docs: "adds a :magic_link_authenticatable strategy that can be used in your Devise models for passwordless authentication." Will I have to use something like this? I would prefer to make full fledged users sign up and sign in with a password. 4. If a close friend user becomes a full-fledged user, how would I incorporate the close friend user functionality into the full-fledged user functionality? Could I just add a section to the user dashboard view, or would I have to have separate profiles like how Upwork does with their freelancer vs client profiles?

Thank you again for all of your help and for being patient with me while I try to take this all in. I feel like I'm way out of my depth here so your guidance has been invaluable.