Open ryanfchase opened 6 months ago
``` 1. Weekly Engineering agenda - we can briefly list all open tickets here, list PRs here, list goals here 2. Dev team announcements person: - designated member to announce PRs, open tickets, etc (weekly rotation) - assign this person at the weekly meeting 3. Our plan to get new members: - create an Open Role on Engineering CoP - to justify this, we should make sure we have available tickets, and good onboarding + documentation 4. Bug-hunt & Code Quality tickets - a live forever ticket that gets reassigned every week, challenge to break the code - person assigned can do a bug writeup - can be a good first issue - Can document proposed solutions to these bugs and prioritize them for later 5. Contact Form - Create a Github access token for 311 Data dev 6. New Ticket Goals - try and maintain a number of Good First Issues (e.g. 3-5) - The number of available tickets should roughly match number of active devs ```
Posting our meeting notes from Wednesday...
Notes on Readme
Notes on contributing.md
#311-data-engineering
, (not open new issue -- we dont have infrastructure for this)TODO
Review Assigned Tickets
Questions from new members:
RC, review with team
RC
I've moved these action items to the PM team agenda for tracking / updating PM issues
- [ ] 311-Data bot by next week (OR at Bonnie 1 on 1 interview)
- [ ] PMs come up with a human name (bot names might get flagged by github)
- [ ] Admin makes a hackforla email address
- [ ] PM team adds credentials to 1Password
- [ ] PM team creates github account
- [ ] Bonnie/Admin adds bot's github to HackForLA org
- [ ] PMs to add team permissions to this bot
- [ ] finish automation implementation, as outlined in this dev ticket
- [ ] Scheduling a meeting with Bonnie for the Story of 311 Data page
- [ ] use the Bonnie scheduling sheet to pick a time
- [ ] pick one PM to conduct the interview
{' '}
to
main
as part of the Files Changed?Leftover Action Items for @ryanfchase
![image](https://github.com/hackforla/311-data/assets/6414668/23a4eff2-df88-43bd-8679-ca6288381596)
- [ ] [Andrew](https://github.com/hackforla/311-data/issues/1334) - [ ] [Johnny](https://github.com/hackforla/311-data/issues/1780)
RC TODO:
Documentation Items
Meeting Notes from 8/31/24
Borrowing from Product Planning new tickets comment.
New tickets checklist for eng:
Blocking ticket for #1708:
Other tickets
Timezones listed as Pacific Time.
RC
dispatchUpdateUnselectedCouncils
?#311-data-engineering
?councils
prop (see L270 in Map.jsx)For next agenda
Need to discuss Vite build issue from VRMS (see if there is any overlap with our project)
In our meeting we covered...
transformRequest
? https://stackoverflow.com/questions/61221421/mapbox-gl-js-api-calls-controlhttps://api.mapbox.com/v4/mapbox.mapbox-streets-v8,mapbox.mapbox-terrain-v2,mapbox.mapbox-bathymetry-v2/13/1402/3271.vector.pbf?style=mapbox://styles/mapbox/light-v11@0&sku=101dzVAySrFTJ&access_token=<redacted>
Performance Profiling
After the meeting, continuing to look into profilers...
this.expression.evaluate
is a method used while mapbox is determining how to render styles and layout of its data. I noticed that while I was profiling, the boundary fills stopped rendering, as if mapbox forgot to do it / skipped it. One possibility is that mapbox attempted to execute an expression but some resource or object was missing. Perhaps we're seeing a memory leak (probably more precisely, a memory management problem)![image](https://github.com/user-attachments/assets/7450ec82-298e-4404-964b-629136d414fe)
![image](https://github.com/user-attachments/assets/d1fadf41-ecbd-4b4d-ab4d-f6d88fe7ebc1)
Memory Profiler: Looking at Memory Snapshots rendering 3 months of data w/ ALL service request types:
NOTE: I'm actually not sure if I'm interpreting these tables correctly. Will need to continue looking into them.
These are listed under `Object`, I assume that means these are just JS objects living in memory. All other entries in thist list were 2MB or less SR Requests being stored in React: ~45MB ![image](https://github.com/user-attachments/assets/5b618642-3f0e-4205-af52-ce44148854fd) SR Requests being stored in Mapbox: ~45MB ![image](https://github.com/user-attachments/assets/25819764-259b-4408-93db-a87f063b48bc) Top 6 Biggest `Object` data structures ![image](https://github.com/user-attachments/assets/b0570a1e-7188-4474-a6cd-f539f79fd019)
MapContainer: ~366MB, not sure if there's much to do here. Unsure of how to slim this, or if it needs to be slimmed. ![image](https://github.com/user-attachments/assets/fe5217a0-3bd9-4982-b369-330c8d025956)
I decided to try and see exactly how we were pulling 2023 data (since this isn't pulled on page-load). I noticed that it was actually only capable of pulling data from hugging face in 16.8MB sized chunks. See picture. This suggests that if we are to split up the data into manageable chunks, that 16.8MB is sort of the high end of resource size.
I noticed there was 4.2MB in the first chunk, proceeded by seven 16.8MB chunks, and then 8.3MB in the last chunk. That's about 130MB of data. And if you go to our Huggingface repo, you'll see that the 2023.parquet is 135MB large, so that's pretty close to what I expected.
![image](https://github.com/user-attachments/assets/a4340282-b0a9-40fc-b7e7-2569d9be2b6f)
Overview
Meeting agendas for the weekly 311 Data Engineering member meetings, useful links and other resources
Agenda Quick Links
2024-05-08
Resources/Instructions
Engineering Onboard/Offboard Issue
Template for weekly meeting's comment.