just make getHistoryList return a promise?

https://codesandbox.io/s/async-fog-nicfs?fontsize=14

Yeah I like that better - treat _historyListPromise as a singleton basically.

I didn't realize you could do async resolve function inside a Promise (yo dawg) but I guess it works.

Nice 6th post in 6 years btw!

so about 1.5 yrs ago, myself and another guy started a weekly presentation for our program. our program is big, like 8-10 teams with 4-6 devs per team depending on whatever.

we were all starting with Angular so the intention was that this was a good way to disseminate information about Angular, Typescript, Javascript, Jasmine (unit tests), Protractor etc. And it was.

We recorded the videos and I would like to think that with such reference material much of the burden was lifted from code reviewers and the quality to begin with was raised.

But it seems we have come close to run out of content.

Realize that I have been fairly stringent about what goes on. I have recently been consistently turning down info type presentations either in terms simply presenting the business value/app feature demo type stuff or giving announcements in terms of the internal processes, ie "fill out this document and go thru these steps to fix a HIGH" bug.

What I envision and want to adhere to is actual technical content for the developers. This is how to set up a unit test with Angular. This is how to test this type of HTML with TestBed. This how to set up an Integration Test with Protractor. This is how to fix this tricky bug that seems to continually show up. This is how Angular lifecyle hooks work. That kind of stuff. Also, all GIT stuff as it was new to the program.

So that was really long winded but what I am looking for is content ideas. Suffice to say that we are pretty advanced at Angular/Typescript/GIT and may be tapped out. That is fine, we have had presentations on setting up and running a GO/VUE app or how to use JAMSTack, GATSBY and NETLIFY to serve up a static REACT app. (btw, both of those presentations ere awesome so I think maybe I want to lead the meeting away from Angular at this point.)

Attendance is still really good with at least half of the devs on the program showing up for each meeting and watching in person. Not sure how many watch later as we record and upload. Some presentations are fully attended still.

Anyway, yes I am mining for content and looking for any ideas from yall. I also recommend setting something up like this for your company, esp if you have a large program that is embarking on using a new tech stack.

Have you talked about typescript decorators and creative usage thereof? I love typescript decorators :P

Say you want to enter the number of kilowatt-hours someone uses each month in a db. You will use this to insert, look it up for display, and calculate their average use per day. Would you have columns:

kwh_id, property_id, kwh, month

or columns:

kwh_id, property_id, jan, feb, mar, apr, may, jun, jul....?

I feel like the first is more elegant, but the second will result in better performance (but I don't really know about that).

Definitely #1.

If it is sql based dont even try to worry about optimizing at the schema level

First one makes sense, second is nasty

Disclaimer: i work with databases quite heavily but dont really work with data

month_id so you're more normalized !

Gross.

Ok, thanks.

(naming note: I'm actually going with energy_month as the table name and energy_month_id as the primary key)

That seems like a weird schema but i strongly believe in doing whatever makes sense to you. Especially if youre the only one using it.

I’d likely sort primary key by property since they are unique. But I dont know your use case well. I sense you’re trying to look at data by the month not by the property.

When I was working with utility usage we had two types of data, we had billing data and we had meter reads and it was a pain in the ass to get them to match.

If you are trying to keep track of billing data make sure you know what billing month the reading is for; assuming these are monthly reads. It becomes a challenge to know what billing period usage from May 15 - June 15 is for unless you know it when you put it in the table.

How precise are you trying to be? Do you have read start and stop times or just Jan-1 to Jan-31 1325 kWh? Is the Jan 1 read starting at midnight or noon or some other time? Do you care?

I guess without more info on your source data and use cases answering your questions is challenging.

There's a separate property table that has the primary key property_id. It is like:

property_id, street_address, city, state, zip, user_id

and then user is like

user_id, first_name, last_name

A user can have more than one property.

This is a good point. Bills are irregular. LADWP bills every two months. For my purposes (getting the energy usage to determine how much solar would be required to offset the bill) it doesn't really matter - especially doesn't matter if the months start on the 1st, but I don't want the user to be confused.

So then you’d have to do a join to do basically anything basic like find killowatt hours by property id. Joins are way more expensive than a simple key:value operation. But thats if performance matters on the microsecond level - with cases that arent commercial and large in scale its probably not enough to worry about at all. Do whatever makes sense in your head

Yeah, I just want this easy to develop. I'm probably going to make $1000+ per user, so if the tables ever get so big this stuff is taking a long time I guess I'll hire someone to fix it or better yet sell it. But, it's not like $millions or nothing. It could very well just be something that brings in an extra $20k/year or something.

Just do vanilla sql for now. You're going to have to remodel the schema anyways if this is a big successful and you're required to scale. Eventually moving to key value lookup model, where you optimize the schema for the query. That becomes even more important for this kind of app, since eventually you will want to do stuff like find relevant properties by location.

Does anyone have a good reference for CORS - that clearly explains which headers should be set in the OPTIONS request and which should be set in the actual (GET, POST, etc) request?

Everything I can find is just a tiny piece of the puzzle. Basically I am trying to figure out if I need to add this header to OPTIONS and GET, or just GET:

Access-Control-Allow-Credentials:true

Google is proving useless.

I believe it depends on the nature of the requests you generate. This article should explain that, specifically the difference between "simple" and "preflighted" requests

have you looked into using a framework with built in migration tooling / database schema versioning microbet?

Yeah I understand the simple vs. pre-flighted (OPTIONS) requests on a basic level.

My question is - is Access-Control-Allow-Credentials:true response header required on the OPTIONS request, the GET request, or both?

For example, I know this response header is required only on the preflight OPTIONS request: Access-Control-Allow-Methods: "'GET,OPTIONS'".

The same goes for Access-Control-Allow-Headers.

But this response header is required on both the OPTIONS and GET request: Access-Control-Allow-Origin:https://mysite.com ('*' doesn't work with credentials)

So which is it for Access-Control-Allow-Credentials? For some reason that's never really spelled out anywhere.

Here's what the article says:

It's not 100% clear but seems to say that the browser can choose to skip the OPTIONS request - in which case you need to supply the header with the GET request.

But in my case Chrome is making the OPTIONS request, where it is getting back Access-Control-Allow-Credentials:true in the response header. But then when it makes the GET request it's complaining that Access-Control-Allow-Credentials=''. (It's not blank, I'm not sending it at all as a the response header.)

Anyway I added Access-Control-Allow-Credentials:true to the GET response headers, and now Chrome seems happy. But I could have sworn Chrome was happy last week w/o it.

I hate this kind of ambiguity. It almost always means something weird is going on.

What I would have expected is that on a simple request you would need to add it to GET only, and on a complex request you would need to add it to OPTIONS only, but it sounds like that's not what Chrome is doing.

I guess it also seems simple enough to just send it on both.

Here's the part where I have to think about how daylight savings time means an hour less difference between PDT and GMT, or an hour more.

I will spend way too long, flip flop a bunch of times, then eventually get it wrong.

And don't you dare come at me with spring ahead. Push the clock ahead. Great. What does that mean? More time difference between us and England right? Or Less?

So it's 5pm right now, which means it normally would be 6pm. So in the winter there is less time difference between us and England in Winter. Right? But how is that possible if it's later in England and we just moved the clocks to make it even earlier here for DST? Or did we make it later here?

GAHHHHHHHHHHHHH

Yep totally lost.

I don't think so, unless I've used some framework that does that without knowing it.

Making up the database tables is probably my favorite programming task. I don't think I want a framework doing that.

edit: I have done something with SQLAlchemy - maybe that does those things.

This thread is starting to get major lag imo.