https://porchweather.com/ - free app for notifying you when the weather is right for opening your windows. The idea is to save you a few bucks on using air conditioning as well as simply enjoying some fresh air.
Tracks temp, humidity, wind speed, and precip chance and you set the parameters.
Notifications are currently email and web push. SMS is too expensive to run as a free service. I think the next direction is probably an app, as web push support in iOS is not great.
I've been working on a website that tells you when it's time to open or close the windows. You register with a location, your preferred method of notification, and the rules for what you consider open-windows weather to be.
Range of temperature is the big one for rules, but you can also require humidity, wind speed. Eventually would be nice to add air quality if there's a sensor nearby.
You don't need any local devices - sensors, motors, etc. You just get an email/text/web push of your choice when the weather is nice and some fresh air is freely available.
I've had a home assistant routine for this running for myself for years, but the 80% version requires nothing more than weather data. Human in the loop automation (I physically open/close the windows).
I've been working on and off for many years on https://ssa.tools/ - a site that helps folks figure out their social security benefits for retirement planning. I recently added and continue to iterate on a new feature for specifically helping you understand the tradeoffs of choosing different filing dates at https://ssa.tools/strategy - it was interesting trying to optimize the performance enough to let the user drag sliders and get 'instant' response time, especially in typescript.
Well voyager depended on a solar system alignment that only happens every 175 years(?) so it'd be a while before we get that same advantage again. The longer it takes the further of a head start voyager gets?
What would change if you wanted to do something like this but for an EV? You already have a large battery, you can make decisions like "I need to be full for my road trip tomorrow, so fill from the grid", but you can just trickle charge from some fixed solar panels throughout the day most of the time. I think amperage can even be negotiated via the standard EV charge cable.
Rooftop solar doesn't require additional land to be purchased, reduces the need for more transmission lines, and reduces transmission losses. I don't know how big these all are but it seems plausible they make it a better deal than industrial solar.
Batteries on the other hand feel like they take less space and thus could be colocated near consumption without having to be on consumer property. Warehouse size within the city. Transmission costs would be minimal.
> It's not a standard if it only works with one specific implementation.
IMO, that's sort of what a standard is, but the words is not strictly defined.
I think you are trying to argue that it's not open. The source is on github, and does accept contributions, but effectively Google controls who can commit to it. Depending on your definition of open, that's a valid argument.
You can load those libraries from other locations, but Google search results won't be able to cache it because of the privacy concerns I mentioned in my top level comment. It's not "valid", but the only consequence of the invalidity is no caching, and that consequence is unavoidable given the privacy constraint. It still shows up in search results.
The Google javascript library URL serves with no cookies, is publicly cacheable, and is an identical file to what you can build from source on github.
I worked on AMP and AMP email for a while at Google, but these are just my thoughts. HN always pulled out the pitchforks on this topic, I'm not surprised to see the same again. I disagree with a number of things this article claims:
> Build an AMP site, and you’d get preferential placement in search results ... The implicit stick, though, was that without an AMP page, your site wouldn’t rank as highly as it may have previously. And
There was an AMP news carousel that would appear at the top news results. The web result order however didn't prefer AMP. Depending on how you looked at it, this was preferential or it wasn't. The "wasn't" perspective is that this carousel was much like showing image or video results - it was a different format and there was a result spot reserved for some docs of that format if the query warranted it.
Interestingly, when Google first started rolling out carousels for images or videos in normal results, website owners protested as well as it was competition for visibility. I don't hear that argument as much any more.
Regardless, the AMP carousel has been gone for a while AFAIK.
> “We are here to make the web great again,” said Google’s vice president of news, Richard Gingras in 2015, only months after Donald Trump brought that phrase into the vernacular
Yeah, that aged poorly.
> [AMP] brought back the dynamics of the mobile versus the desktop web, for one. Instead of the same web for everyone, you now had one page on mobile, another page on desktop
That was a website owner choice. AMP pages could be responsive and work just fine on desktop. Many sites did exactly that, though you often never realized they were AMP pages. The goal of the project was always to optimize mobile performance, but it worked well for desktop too. Search provided a mechanism where you could choose to pair an amp and non-amp page, only showing AMP for mobile. I suspect sites did this because non-amp allowed all of the bespoke javascript they wanted on desktop, including things that were kinda terrible for user experience but improved ROI. Super heavy javascript, ads that were difficult to dismiss, all sorts of jank.
> And, more critically, it lessened your control over your site. ... ad tech and other scripts on your site might be incapable of running on your AMP site
AMP is a subset of HTML plus some javascript libraries. The subset thing means you had a limited API. That was the point though, the limited API was restricted to the set of things that could be forced to be performant. That is "control" in some sense, but it wasn't control in the common sense of limiting content or ad networks or whatnot. Virtually every ad network had a library for running on AMP.
> AMP required allowing any AMP CDN to cache your pages.
You can and always could create amp pages that are not served by AMP CDNs. The tradeoff is that search results couldn't preload the page for the user, as there is a hard privacy constraint that the user can't initiate network traffic to the publisher until they indicate intent with a click. So without the CDN, it wasn't quite as fast, but it was still typically pretty fast.
> As Ray Tomlinson, who implemented and sent the first email from ARPANET in 1971 said about adding formatting to email: “That’s too complicated: we just want to send messages to people.”
This is a valid perspective on what email is or should be. I don't feel strongly that it's the only perspective, but it's certainly valid. The argument however is really against HTML email, not AMP email in particular. I think most of the rest of the arguments apply pretty equally to both.
If you look at HTML email in webmail clients, clients all work on the principle of sanitization. Take arbitrary HTML, modify it to remove anything dangerous, and then render the rest. "anything dangerous" requires removing all javascript, most or all CSS, large swaths of the HTML tag space, rewrite all image URLs, etc.
This would result in pretty garbled results except senders have adapted to only send the subset of HTML that won't be garbled. However, it's not easy to do. Take a look at https://templates.mailchimp.com/resources/email-client-css-s... which shows what each email client accepts. It's much much worse than browser incompatibility, though you also have to handle browser differences too.
In a sense, this limited HTML API is similar conceptually to AMP. AMP just was able to add back some of the interactive functionality stripped away. And AMP had the possibility of becoming a open-source standard compatibility API for webmail clients. One that was open source, had maintained validators that could be tested against, etc.
I think it had the chance to really make HTML email better. Of course, if your perspective is that HTML email is fundamentally bad, then that's not really a win.
> You’d need to authenticate your domain with DKIM, DMARC, and SPF—good ideas, regardless. You’d also need to send a sample email to both Google and Yahoo!, and register your domain with each of them. Then, if you were lucky, within 5 days you’d be approved to start sending AMP emails.
I think the plan was always originally to expand this to a general availability format. However, AMP email launched in 2019 and Google largely shifted away from AMP shortly thereafter, so the project never got enough momentum to get to that state, sadly IMHO.
Except you can't. Every browser on iOS uses Safari's rendering engine. Chrome/Firefox on iOS are effectively reskinned Safari. This is an apple requirement. The rendering engine being the important part here when talking about standards and such.
A large and growing fraction of this lumber is used for wood pellet production to be burned in the EU as "green" energy.
Sure, these trees are technically renewable over decades to centuries but this doesn't matter all that much when we need to rapidly reach net zero in only about 25 years.