vonadz

Sure, just like there's a correct IDE.

I think it isn't the consensus anymore because there isn't actually a "correct" solution. It's too subject to personal preference. For example, I prefer having HTML + CSS + JS all in the same file because then I know everything relevant to the component or page I'm working on is right there. I do concede that it can get extremely unwieldy if you don't separate out components though.

I decided to look into this, because the data is often a bit off, but not by this much. It turns out there was an error in the calculations. For some providers, we extrapolate the values based on historical data, and in this case, it was being done incorrectly. The values have been updated here: https://findenergy.com/providers/pacific-gas-and-electric-co...

It looks a lot closer to the numbers you've been quoting now (hitting 31 cents / kilowatt hour in March). Thanks for catching that.

I would also like to know about this.

I like making obscure data visible and easy to digest, so I'll add this to my backlog of potential projects.

Data comes from the EIA. They release company revenues ($), sales (kWh), and # of customers for residential. We calculate the rate as revenues / sales (and correcting for units). It's a bit more nuanced than that, like we sum up all of the revenues and sales for each company that is owned by or merged into the specific company (adjusting for % ownership as well). The numbers are definitely not perfect, and for many companies are a year behind (they only report to the EIA yearly), so that's why there might be a major different in prices (there has been a MAJOR increase in electricity prices in the past couple of months). There are some companies that we have exact rate data for, and those rates are visible on the page when that's the case.

We're currently working on including the lobbying costs of each provider on our website (https://findenergy.com), because we believe consumers should be aware of what providers are spending their money on.

We've also begun building a full industry map of who owns which power plants and the chain of parent companies / subsidiaries. Quite amazing how deep the rabbit hole goes on the thing that all of our modern lives rely on but many of us take for granted. For example here: https://findenergy.com/providers/first-energy/#overview you can see all of the companies tied to the company at the beginning of the article.

If any journalist or fellow dev is interested in this space, feel free to drop me and the team a note at alex@findenergy.com

In regards to plant data, https://findenergy.com/power-plants/ is pretty interesting source, although it's not in real time. We ended up using EPA recommendations for emission coefficients (https://www.epa.gov/sites/default/files/2015-07/documents/em...) but at one point we experimented with using a UN study that had emission factors listed for renewables and nuclear (I think they took into account the construction of plants), and nuclear was at something like 25 KG of CO2/MWh compared to most coal plants that are around 1000 KG of CO2/MWh.

Yeah so in this case I'm using the client code, which is safely stored in the worker.

"In that case you could create a backend endpoint that accepts a request and makes the call with the API key on behalf of the client/front-end"

This is what is happening, except instead of a backend endpoint hosted on my own VPS, I'm using a Cloudflare worker.

"The title of the article says OAuth, and hence assumed that you wanted an authenticated client to be able to make the call to the backend for subscribing."

An authenticated client is necessary in order to retrieve the email of the client.

You don't get them because I've done them all!

"not the client key for the OAuth service"

OAuth uses a client key and/or a client secret, for the application that is requesting access on behalf of the client.

That would be the logical solution, but "The javascript is dynamically created and hosted on S3. The keys, etc are safely on a server that runs to generate the file" sounds a lot like they have a server where they build a .js file that is capable of querying Slack, then store that file on S3 for the website to pull whenever someone registers. In that case, the client is pulling a .js file that probably has the Slack API key in it.

Not quite sure why my other comment got flagged, it was a genuine question. If they had, and they still suggested this, I would inquire how that would be possible. It appeared to me that they had just read the title of the article and suggested something related to it.

As far as I can tell, Cloudflare Access doesn't allow you to run arbitrary code in an environment that isn't exposed to the user, which is kind of the whole purpose of this setup. The sole purpose of the OAuth part of this operation is so that the user doesn't have to type in their email. Session persistence/selective access isn't relevant here, and that appears to be the only thing the Cloudflare Access really offers.

I think you misunderstood what I said. The API key I don't want to expose is the one that is required to register the user with the newsletter service, not the client key for the OAuth service.

Promulgators... nice. Saving that in the lexicon for future use.

There is no logout because the login isn't really a login. All this is doing is using the user's permission to submit their email (registered on the OAuth service) to subscribe to the newsletter. Nothing in the browser is changing that could compromise your details.

For my static site, it substantially decreased loading times compared to when I just host from a VPS.

I feel like I've single-handedly trained their AI to identify buses, boats, and planes at this point.

Thanks :) paint is the graphic editor I'm most proficient in!

If their point was can you mitigate vendor lock-in, they should have said that instead of asking about self-hosting. Saying you have vendor lock-in because you can't self-host something is very strange in the context of this article.

I didn't make a point of vendor lock-in because migrating this process flow to a self-hosted HTTP server would take about 5 minutes. On top of that, this flow is going to be very similar for any vendor offering javascript functions.

Perhaps it is my fault for not including a section discussing this, but I assumed that the audience for this would primarily be people understand basic javascript and could deduce the portability of the code by looking at it.

In regards to your quote, this is free and if I wanted to switch, I could just copy and paste the javascript into node with some minor tweaks.

A big motivator for this was definitely just to try out Cloudflare workers and see how they are. I've set up countless servers for APIs. In terms of time, I'd say Cloudflare workers is a bit faster when you get over the initial learning curve. Obviously you could write a deploy script for a server and have it set up everything automatically, and I have done that in the past, but sometimes it's fun to try new things right?

I never intended for this to come across as a technological accomplishment. I even end the article with "That’s pretty much it. It’s fairly simple with no real catches". I'm merely presenting what I thought would be useful information for some people. Personally I think maintaining a server is more work than maintaining this, but to each their own.

Yeah I don't find this at all surprising. Ultimately it's always a balance of what's worse to maintain, the reality (server) or the abstraction (workers).

Self hosting would pretty much defeat the whole purpose of workers. The point is that you don't need to self host.

I'm having a hard time understanding how a file hosted on S3 can send a request to Slack without exposing your API key. Can you elaborate on that?

EDIT: guessing by the delay in response, someone just told all of HN they exposed their API key?

Thanks! I'd like to explore adding debugging and warning alerts in the future. Right now it's kind of hard to tell if anything is broken, short of going through the registration process myself. If you're pulling javascript hosted somewhere else to your site, doesn't that expose your slack API key?

Yes I saw that. Comment was comparing the CO2 emissions of the largest fossil fuel plant with a nuclear plant that releases 2000 KG of SF 6. If estimate the impact of SF 6 in terms of CO2 as 23,900 times the CO2 weight, than 2000 KG of SF 6 would be 2000 * 23900 = 47.8 million equivalent KG of CO2. Largest plant fossil fuel plant had emissions of 18 billion KG of CO2.

That's still peanuts compared to coal. Largest plant had 18 billion kgs of CO2 released last year. 2000 * 23,900 = 47.8 million kg of CO2 equivalent. Obviously the prior calculation also depends on plant size, etc.

One of the big issues with nuclear plants is that they aren't very flexible in terms of their energy production. Their production is super steady, so what happens when there's a huge peak in electricity demand at 6 pm when everyone gets home? Fossil fuels are great for their relatively short start up time. Maybe renewables + batteries could somehow fill this niche?

My estimate was a pessimistic one. I would be SHOCKED if they are available this decade, looking at the fact that not a single one has positive net generation (this is just net thermal heat generation, AKA amount of heat put into the system and amount of heat out of the system). On top of that, current fission plants take over a decade to setup.

I'd also posit that a return on investment in a company like this isn't only going to happen if it achieves its goal. Looking at how research intensive/cutting edge the end goal is, they could stumble across 100 different new innovations in the process that could sprout into their own business ideas.

PS. Am I the only one who thinks this page sucks? https://www.helionenergy.com/our-technology/