Source code and additional information is available on GitHub: https://github.com/dnlzro/horizon
Oh, don't mind me, I'll just be over here in the corner laughing ruefully as my bones crumble to dust: back when I started, if you wanted a page to refresh on its own, this was the only way.
Beautiful work! A splendid example of formal minimalism at its best.
First, the header must be added to the response, not the request.
Second, in many environments (managed hosting etc.) there is not an easy way (or indeed a way at all) of adding headers to responses.
Oldschool shared web hosting was a shockingly deprived environment by modern standards, which is why my Linode account turned old enough a few months ago to buy a drink in a bar: $20 a month in 2004 was amply worth gaining a degree of control over web server configuration which is broadly the default assumption now.
Since I was also administering some shared web hosting in my own right at the time - partially overlapping with my web design work targeting shared hosting, since some customers preferred to BYO - I don't blame admins for being difficult to work with; we all had good reason to be, with the afterthought security typically was everywhere in those days. But you begin perhaps to see why bypassing the whole rigamarole with a hint to the client was attractive.
I realize you're probably not accustomed to being called on your lousy behavior. I doubt you will need to become so. But just for once, here we are. You don't bother to find out what you're talking about before you speak and then you want your hand held on points that were already clarified, had you but bothered to catch up. I don't tolerate that in candidates, I won't tolerate it in colleagues, and I see no very pressing reason to tolerate it here.
And it doesn't allow overrides in dotfiles since that's not performant or secure.
It's getting better. Most serverless hosts (including Cloudflare, which this site uses) follow the (req: Request) => Response pattern, which by definition allows sending headers.
Well, the higher ups of course hated it, they were confused as to why the horizon would get hazy, yellowish, and so on. "Our competitors' skies are blue!" They didn't like "Use your eyes and look outside" as an answer.
Eventually, I was told to scrap it and just draw a blue rectangle :(
All that to say, nice job on the site!
1: https://courses.cs.duke.edu/cps124/fall01/resources/p91-preetham.pdf
You could've sold it with telling them Vincent Van Gogh's paintings had the location of stars accurately, you were inspired by those paintings to reproduce the sky color accurately.
I can understand people removing polish things like that if there are usability concerns, but those small things add up to a lot in an end product and are a joy to find and explore.
If you're the kind of developer who likes to "sand and finish the back side of the cabinet," either you need to find a very rare, special company, or do it at home as a hobby.
But yeah, if you only care about checking the feature boxes.. Go ahead, make shit software with miserable people, but be sure to prepare to go out of business.
It comes from tinkering.
I worked at large companies, and there are reasons beyond that. I've been on the both sides of this fence.
Senior engineers feel the pain of supporting all these features. You created a new streaming API prototype that provides a gradual response, progressively displaying details of the 3D model? Great. But it's 15000 lines of dense code without a lot of explanation. Who is going to support it once you leave the company? Is it secure? How does it work with kiosk-type browsers? Can you write a formal proposal so we can start the review process?
Oh, I see that you're already leaving the company :(
And that's also why startups are often so much more successful initially. They just don't care about the long-term support and YOLO a lot of functionality.
This is like if you were renovating your house and the drywall guy spends a huge amount of time building up round corners, but you just wanted regular square corners. Then on some drywall forum they're bitching about how "all clients are stupid" or something.
That’s an aesthetic call, not a “who can do the math” call.
“Good news, I accurately simulated the particulate load in the local atmosphere—so now you authentically can’t read the text on a given smoggy winter morning!”
(FWIW, grace for management decisions notwithstanding, I think what gp did is awesome, and would switch on full realism mode every time :)
It's not that simple. There's possibly better ways to deal with it, but for safety-critical stuff (like a navigation display in a vehicle), simple is much, much better. In many cases, there's actually laws and liability stuff involved.
I once spent six months, developing an "un-asked-for" WiFi control app for a digital camera, and had it nuked. It worked much better than the shipping app (which was enjoying a richly-deserved one-star rating in the app store).
The considerations had a lot to do with the corporate Process (note the capital "P"), which I sidelined. I thought I could do better, but the people with the hands on the brake, thought different. I didn't kiss the right rings. That's a very real consideration in any corporation.
As a manager, however, I did go to bat for employees that displayed initiative. In some cases, I was successful. In some cases, not so much.
We aren't painting sistine chapels, we are running the plumbing in the sistine chapels basement. The job doesn't exist to give you emotional fulfillment. A mason doesn't insist that a client who needs a warehouse must pay him to spend a week detailing corbelled brick cornices. He makes a CMU wall, in the cheapest and most efficient way that still gets the job done.
It's profoundly disrespectful when we build monuments to our own ego instead of just getting the work done and it speaks to a professional immaturity of the highest order. That was one of the hardest lessons I learned as a fresh engineer and I see so often others that are just learning it. Sometimes people never learn it.
Sure, but in plumbing - or any trade - there is a huge spectrum of quality of work. Tons of little details add up that confer the person’s skill level to anyone checking it out in the future.
> It's profoundly disrespectful when we build monuments to our own ego instead of just getting the work done and it speaks to a professional immaturity of the highest order.
When I insist that something must be done a certain way, it’s not for my ego, it’s because I know that a year from now, I will be called upon to fix it during an incident if I don’t do it right this time. I am so absolutely sick of hacky bandaids being thrown on the ever-increasing pile of tech debt. To me, it’s profoundly disrespectful when product tells engineering that yet again, they will not yield time to fix the backlog, and to ship New Feature X.
That doesn't apply to every single instance of those, but if the sky isn't the focus of your application, a realistic one is just a distraction.
This one always gets me in how dirty the sky must have been "back in the day" in order for people to see a yellow sun. I've never looked into what gas would be needed to make the sun look yellow, but it must have been hell to breathe.
The reality is that we have certain conventions that are immediately understandable, and that too much visual complexity results in confusion rather than clarity.
If the sky is hazy white when I expect it to be blue, I'm confused as to whether it's the sky or if the map is still loading. It's adding cognitive complexity for no reason. Stars similarly serve no functional purpose at night.
What you built sounds great for an actual planetary view like Google Earth. And it sounds fun to build. But it's an anti-feature for a navigation view. When you're navigating, simplicity and clarity are paramount. Not realism.
Also the phrase "know your audience". No sense in casting pearls before the swine.
In this case the higher ups may have been confused due to, say, looking at the app while indoors (and from the perspective of "let's judge this developer's work"), while the actual users would see it in a vehicle alongside the real sky (and from the perspective of "let's see how easy this is to match up with reality").
...it's the software frameworks. A new screen size. A different color depth. A bug when the graphics library is upgraded for antialiasing. Etc.
Also, devices already sold often get updates, so it's not even just about future devices.
That said there are niches where jobs let you do cool stuff all the time. Hard to find. Probably why gaming jobs are notoriously underpaid and overworked.
I wonder what it would take to account for weather?
what got me the most is opening chrome dev tools and seeing nothing there
https://www.google.com/search?sca_esv=58e7983bf9f21fcd&udm=2&2&q=night+horizon+pictures+dessert&sa=X
const { latitude = "0", longitude = "0" } = Astro.locals.runtime.cf || {};
I've made a library for my own use cases that does this (https://github.com/mcteamster/virgo), but it's also pretty straightforward to parse the city/state name out of the timezone and look it up somewhere.
<body style={{backgroundColor: bottom}}> </body>
(I used this, but it does leave a small "please purchase" banner at the top, until you pay: https://play.google.com/store/apps/details?id=com.nuko.livewebwallpaper)
It looks very similar!
I know that you deeply know map tech :-) but if I may make a suggestion - you might consider switching from Google Maps to Protomaps? https://github.com/protomaps/protomaps-leaflet
Cheers
But it looked very cool earlier today when it matched!
const { latitude = "0", longitude = "0" } = Astro.locals.runtime.cf || {};
https://developers.cloudflare.com/network/ip-geolocation/
"This Managed Transform adds HTTP request headers with location information for the visitor's IP address, such as city, country, continent, longitude, and latitude."
These bindings (or at least some of them) are also mocked when developing locally, in a non-Cloudflare-Workers environment.
[1] https://developers.cloudflare.com/workers/wrangler/api/#supported-bindings
[2] https://developers.cloudflare.com/workers/runtime-apis/request/#incomingrequestcfproperties
One issue with the current code is it doesn’t model clouds, haze, or smoke so the rendered sky can differ from what you see outside (numerous HN comments notice this). You can partially correct for this by using semi-realtime satellite imaging but hard to get super accurate which is what pushed us to develop our own sensor. There are various CCT sensors on the market already but they only measure directional+diffuse+reflected light which is typically ~7500k but the sky color goes up to 40,000k.
Here is a plot showing the color of the sky as it changes during the day from real sensor readings. Each one is 30s apart, so it change change quickly. https://www.innerscene.com/built_pages/cs_specsheet/cct/cct_measurement.jpg
A bit more info as well: https://www.innerscene.com/SpecHelp/CircadianSky/cct/cct.html
This is really cool. I’ll probably see if I can make it my new tab background in Chromium.
Edit: I think its this link: https://sky.dlazaro.ca/ OP - put it in the HN post and first on your github repo! Good work.
https://www.icloud.com/shortcuts/c8ba254a0272453cbe39357b144d0fa3
Just make sure that your last (or only) iDevice Home Screen is set to type “image”.
- First and most impactful: as the earth curves down and away from the observer's horizon, your line of sight goes through a thicker slice of the atmosphere.
Looking straight up you might have 100km of atmosphere until space (the distance is made up here, but I'm using the Kármán line as an arbitrary ruler), but looking out towards the horizon (assuming a perfectly spherical Earth), it's much, much more than that 100km, so the light will scatter off of (and/or be filtered by, depending on angle and time of day) more particles in the atmosphere, affecting the colour of the sky.
- The compounding factor here is if there are environmental factors that boost the particle count in the air, and especially particles that'd stay in lower layers of the atmosphere. Where I am, we've been dealing with wildfire smoke of varying strengths for a few weeks. Today's gentle enough, but it's bad enough that my gradient goes from rgb(115, 160, 207) at the top of the sky to rgb(227, 230, 227) at the horizon (which is shockingly accurate).