« first day (88 days earlier)      last day (38 days later) » 

2:23 AM
So, today I finished with my rough round of changes, it's on the cad branch, but I'm still working on it.
 
2:33 AM
Those return_status calls? Yeah, very important for CAD.
literally doesn't work without it
those need to return JSON
ref: remote: true on many things
 
2:45 AM
OK. I assumed as much, I thought I'd just discover all the things I did wrong when I tested. Problem is, something is wrong with the asset pipeline and none of the controller specific JS is getting loaded for me.
I'm also very not done with my branch. Lotsa stuff needs to move out of the big RR controller, and RR needs to get renamed to Requests and lots more things.
I will probably end up with something very similar to what you have, but with some tweaks.
But, there isn't much urgency is there?
 
@thesecretmaster you don't need js_assets
 
Oh, did I forget to remove that too?
Whoops.
 
Let's do this in stages. All the stuff I added doesn't touch RR, so we can add stuff in one PR and work on RR in parallel, submit it in another PR
 
Erm...
8 hours ago, by ArtOfCode
@thesecretmaster The old RR controller is obsolete. It can be deleted. If there's stuff in it that isn't replicated in the new stuff, it needs to be moved to another controller - either Dispatch::RequestsController or something else
 
Aye, but I haven't done that
it's still there
 
2:55 AM
You destroyed some important models.
IIRC
If you left everything, there's tons of duplication.
 
so we can make whatever tweaks to my code you want, on the dispatch branch, then do the RR changes in another branch
I nuked some models, yeah, left the RR controller
 
The RR controller interacts with the models.
 
Yes, but given that we have to refactor it anyway, that's fine
 
I don't want to merge your PR because there is still a ton of broken stuff in it. It's just incomplete. You haven't even put CAD into the nav.
 
that's not exactly hard
 
2:58 AM
Currently, for the most part any non-cad thing you try to do will throw an error.
 
what else is broken
@thesecretmaster define?
 
Anything that's not broadcast or translations.
E.g. queues, statuses, editing, etc.
 
...which is expected, because the models are gone
 
Yes. Which is a problem.
The PR should be complete before it's merged.
I just don't want to break master.
 
I've left the controllers in place so that we can copy the code to new controllers, but they're not intended to be used any more
along with adding CAD to the nav I'll remove those from it
 
3:00 AM
But they are still used.
 
how?
 
You really should remove everything that's old. Keeping it so we can re-add the functionality is what git is for.
 
okay, sure
 
But before it's merged, all the functionality that existed before should still exist. Adding CAD and removing queues, suggested edits, medical stuff, statuses, and all the other stuff is just not OK.
 
statuses are there
 
3:03 AM
Which is why I went back through all of the things you did and made them compatible with the previous code. It still needs tons of cleanup. But it will not require you to rewrite everything.
 
medical I removed for a reason - it didn't actually make sense having it separated from dispatchers
Dispatch needs access to medical info
 
Do you know how medical worked?
 
Suggested edits I can add
vaguely
Queues need a massive rework anyway, so I'm removing them in this PR and the next major job is that
 
Alright. To be clear, medical was not a subset of dispatch. It's group which had a separate flow and worked separately. Dispatch looked at the some of the results of medical work, but medical was seperate.
So making it a part of dispatch does not help things.
 
okay, so what do they need?
 
3:06 AM
I had a big list in slack... if I still had access to that I'd show you.
 
you're not in slack?
 
I left 2 weeks ago
 
oh
anyway, let me rephrase: what do they need that we already had in SCOT?
 
They needed that case notes field and they need a special medical status. Plus there was a thing for casefinders workflow I was working on...
Also, the data cleaning people need tools, e.g. deduplication
 
@thesecretmaster Case notes exist
 
3:09 AM
Here's my real question. Why do you want to rewrite everything?
 
Medical status I can add
Data cleaning is part of queues, see above
 
CAD fits nicely into things that already exist. Why a rewrite from the ground up.
Sure, you can rewrite all of these things that already exist, but why?
 
@thesecretmaster we went over this... I wanted to add CAD, and the frontend needed a big rework anyway, so I took the opportunity to do some app structuring as well
 
I'm fine with some. You've just said you're going to rewrite the whole app.
 
huh?
 
3:11 AM
What're you keeping?
 
Broadcast and translations
 
Which are not part of SCOT RR.
 
possibly bits and pieces of other things
correct, but I'm not rewriting the whole app
 
"possibly [keeping] bits and pieces of other things" != "some app structuring"
 
unrelated
 
3:13 AM
Lemme rephrase. You're rewriting all of RR.
 
Since I'm making major changes anyway, I'm also moving things around and putting things into namespaces. That's the structuring. As part of that, I may reuse parts of the code we've already written.
 
You're not making major changes. You're adding a CAD funcionality.
Did I rewrite all of RR when I created queuing?
 
I am making major changes. Adding CAD, and rewriting the front end of RR.
 
You're rewriting the front and back end and losing quite a bit. What's the problem with adding CAD then refactoring?
 
What's the problem with doing both at once?
 
3:18 AM
It then becomes code that you can read and I cannot. What you've done makes absolutely no sense to me. Which, in itself, is not an issue with the app. But I do not think you want that?
 
You'll need to re-familiarise, yeah
 
I have spent 2 days trying to understand what you're doing and where you're going with this. It still makes no sense. If 2 days is not enough, I don't know what you expect.
 
I've already explained both of those. If there's code you don't understand, lemme know, that's easy enough to explain. But we've already done "what am I doing" many times - adding CAD, redoing the front-end of RR for better UX.
 
You didn't redo the front end. You added CAD front end and copy-pasted front end from RR into Dispatch::Requests. And you've totally rewritten the backend in a way that is more confusing and has fewer features. All of that is my opinion. I simply am telling you that I do not understand what you're actually doing. I understand what you're trying to do, but the way I thought you'd do it is very different from how you've done it.
I understand in principal what you're trying to do. I don't understand why you think that a full rewrite of all RR related functions is going to help anything.
 
@thesecretmaster uh. I think the only front end I copied directly was the tables on RR show view. Maps initialization code, too. I've done new stuff for the rest of it.
Fewer features, yes, we've done that too, I'll add most of them back in. Queues I'm going to leave for now because they also need work.
Define "more confusing"?
 
3:26 AM
"Takes > 2 days to understand"
 
Yeah, but why? What about the new code don't you understand?
 
I understand the syntax. That is ruby/rails. I don't understand the overarching logic or organization or structure.
Why not do what I am trying to do on my branch: Add CAD without destroying everything else.
 
It's not that different from the previous stuff - it's just moved from root to Dispatch namespace
if you don't understand it, ask me questions about it that you want answered, and I will explain
 
@ArtOfCode A) That makes no sense to me B) OK, I see that you've done that and understand that you've done that, but the stuff in the controllers makes no sense.
Why are case notes, status, priority, and request in Dispatch?
 
Because Request is.
 
3:30 AM
and request
 
Why that's there - because that made most sense to me at the time. It could move. If it moves, then the others move with it
 
To me, that makes no sense. You've chucked the old RR table and replaced it with a new table. Why?
Also, that's a big logic question, but I have more questions ignoring that.
 
> because that made most sense to me at the time
@thesecretmaster question away
 
@ArtOfCode Does that still make sense to you at this time?
 
Not as much as it did
I'm happy for those to move.
 
3:33 AM
Can I explain my idea to you?
 
sure
I need to go sleep, but I'll pick it up in the morning
 
Starting from master: You add CAD functions (because you know the requirements best) in one branch while I work on refactoring RR in another and when you finish that you can restructure queues and then when I finish I can work on adding medical flow stuff and we can carry on in parallel.
Instead of you rewriting everything and me not being able to understand everything for another month.
I do not want to scrap the work you've done. I actually think CAD is awesome and I excited to see how you do it so I can help work on improving it once you've built the foundations. That's why I started trying to move your work into a place where it integrated with the existing code instead of overwriting it (in my branch).
I also totally agree that refactoring needs to happen. I think it should be something we work on together, in multiple steps, carefully.
Anyways, I also need to go to sleep.
 
 
9 hours later…
12:40 PM
@thesecretmaster this kinda is scrapping a large part of it, but eh, fine.
 
 
2 hours later…
2:48 PM
@ArtOfCode Most of it is still there, I think? What's getting scrapped?
 
@thesecretmaster CAD is only half the work I've done. You're asking me to drop the other half, and just do CAD. But, since that's the only plan we're ever going to agree on, fine.
 
I think that waaay more than half of what you did is CAD stuff. I don't want to force you to do a thing you don't want to do. But I also think you want me to keep being able to work on it.
 
Yeah. So we do that.
 
OK. I also don't want to be telling you what to do or scrapping work that you've done. So if we can work out a solution that doesn't involve scrapping as much of your work, that'd be better.
 

« first day (88 days earlier)      last day (38 days later) »