1. I like the way sources are listed on the right panel, that makes them easily visible as i scroll through the answer.
2. The rendering of the answers using rich visual components is nice to look at. I personally hate information dense reports that ChatGPT spews, which isn't easy to consume quickly.
What I miss though is iterations on the answer, as in, how do I specifically zoom into one aspect of the answer, and then easily zoom out and continue.
Thank you! We actually support "zooming into" different parts of an answer. The chat conversation is now stored as a tree, so you can ask a followup, then revise the followup, and switch between the revisions below the answer when doing a third followup.
I could imagine that the cash cow part of a product gets all the attention in the beginning. Does that stay the same through the life cycle? Or do you see that it takes a back seat while feature development on top of that takes the center stage at alter stages of the product?
[edited to add this] I also see that it's sometimes easier to build something new, than to go on maintaining something.
Just curious to know if you see the following trend:
As a codebase matures, the amount of time spent of code maintenance increases and with bug fixes, it gets harder to spot them and the amount of code that is required to solve them is little.
Yes. We have at least one team dedicated to identifying bugs and maintaining technical quality. For example they statistically analyze our CI runs to identify regressions. They find some subtle bugs that would be difficult to identify through one's own experience.
This is a team that no one interested in their career progression should ever be on. This is usually a dead end and almost impossible to spin in behavioral interviews.
Well, not my experience at all and combining that with the link I posted, I suspect you are mistaking what I am referring to. What are you basing your statement on?
Let’s say I am interviewing two people with the same technical skills.
One says that they have spent the last couple of years fixing bugs and analyzing the CI builds. The other talks about leading major new initiatives or being responsible for a major new feature and I dig into it. Guess which one I’m going to hire?
In the terms of promo docs, which shows more “impact”, “scope” and “dealing with ambiguity”?
It sounds like you would hire the one building CRUD apps. Perhaps I was unclear in my original post, technical quality teams don’t analyze CI and fix bugs. The team in my org builds sophisticated tools to analyze CI runs and teams self service the bug fixes. When you are operating at large scale and delivering products, there is no limit to impact or scope; ambiguity is inherent.
> But I was equally surprised by how little this was being discussed, or (as far as I could tell) practiced in the real world. While there seemed to be endless threads on Twitter about server-side React (to get the UI generation closer to the data), no-one was talking about the opposite: moving the data to be closer to the UI, and onto the client!
This, I've wondered for a while. There is plenty of talk about server side rendering, which I don't think is useful for many apps out there. SSR is quite wasteful of the resources on the client side that can be made useful. And, I've seen many apps being developed with "use cliënt" littered all over, and that begs to wonder why do you even want SSR in your app.
Wasn't the reason for SSR to have more control over security and offload work from the client to the server? Let's not forget that the majority of the worlds population is using slow ass tech. We cant simply put huge workloads to the client.
I think the main drive for the modern version SSR was SEO. The workload part? the whole point of SPAs was to move compute - especially fancy UI compute down to the client so the server only had to move data... so we're just completing the circle again.
It is exactly what I am talking about. Rendering the component on the server, takes up resources, as opposed to just sending that data to the client, and the client rendering it.
In Nextjs, "use client" is used to force the rendering to take place in the client, because many components cannot me rendered in the server. For example maps. In this case, it's unnecessary to use an SSR framework.
There aren't many smart watches out there. I've loved what Garmin has done. I had always hoped something which would open up an ecosystem to build on. This looks promising on that front.
Initial conditions are modeled by Keplerian elements around the main parent body. These are 6 scalars that describe the size, shape, and orientation of the orbital ellipse as well as the body's position along it at a given time (epoch). I scraped these values from various places including research papers, JPL databases, Wikipedia pages, and university web pages.
From there everything is mapped into a consistent epoch (now) and the initial position/velocity are calculated using a Keplerian->Cartesian transformation (the math here is a more or less straightforward coordinate transformation). The physical simulation is then run by updating these 2 Cartesian vectors, applying gravitational acceleration over ∆t.
This works pretty well, all things considered, but there's a lot of room for improvement to account for solar wind, relativistic effects, planets not being perfect spheres, etc. The Keplerian elements are also just an approximation of the true orbit, and this approximation can show up at high zoom levels (it's why planets don't always line up perfectly with their ellipses when you zoom in). I'm also still figuring out how best to get the initial position/velocity for objects that aren't in simple elliptical orbits (co-orbitals like the Trojans, objects on escape trajectories like Voyager probes). There's a lot for me to learn, maybe later I will write a blog post!
I hope there is a better way to maintain open source projects without being overly cautious and suspicious of every PR someone makes. Maintaining open source projects is hard, and this is going to slow down development on many projects. And, rightly so, it's better to make a good code base, rather than one that is littered with backdoors.
I wonder what could make this situation better for the maintainers of open source projects?
Designing for safety helps a lot. Memory safe languages, reproducible builds, encoding safety properties in the type systems, and so on.
Sure, an attacker can subvert the types as well as the code, or use unsafe code, or try to tamper with infrastructure, but the more obvious it is that something is unsafe, the harder an attacker's job is.
The xz attacker introduced high-risk features over time and used them to justify weakening security controls and things that might have detected the problem. A culture of safety over the absolute best possible performance might help to make such attempts harder.
1. I like the way sources are listed on the right panel, that makes them easily visible as i scroll through the answer. 2. The rendering of the answers using rich visual components is nice to look at. I personally hate information dense reports that ChatGPT spews, which isn't easy to consume quickly.
What I miss though is iterations on the answer, as in, how do I specifically zoom into one aspect of the answer, and then easily zoom out and continue.